IT Security Consultant

Im Juli gibts eine kleine Abkühlung von den Hitzetagen 😊 Jedoch nicht von kritischen Schwachstellen.

## Was ist der Patch Tuesday? ##

Der Begriff bezeichnet den zweiten Dienstag im Monat, an dem Microsoft wichtige Patches für seine Systeme veröffentlicht. Durch den festen Rhythmus wird die Arbeit von Systemadministratoren und Nutzern erleichtert, da somit ein klarer Planungszeitpunkt zum Einspielen von Updates gegeben ist.

Der Patch Tuesday bringt im Juli 2025 unter anderem wichtige Sicherheitsupdates von Microsoft und schließt damit mehrere Sicherheitslücken.

Besonders hervorzuheben ist eine kritische Schwachstelle im SQL-Server von Microsoft. Die Schwachstelle [CVE-2025-47981](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-47981) bekommt einen Score von 9.8. Ein Buffer-Overflow erlaubt einem nicht authentifizierten Angreifer Remote Code auszuführen.

Außerdem wurden generelle Patches für Windows 10 und Windows 11 herausgebracht sowie für die gängigen Server-Typen, siehe [hier](https://msrc.microsoft.com/update-guide/releaseNote/2025-Jul).

SAP hat diesen Monat eine kritische Schwachstelle veröffentlicht im SAP Supplier Relationship Management (Live Auction Cockpit). Die Schwachstelle [CVE-2025-30012](https://www.cve.org/CVERecord?id=CVE-2025-30012) wird mit einer glatten 10 von 10 bewertet.
Mehr Informationen über die veröffentlichten Schwachstellen sind [hier](https://support.sap.com/en/my-support/knowledge-base/security-notes-news/july-2025.html) zu finden.

Weitere Hersteller, die Sicherheitsupdates herausgebracht haben, sind nachfolgend aufgelistet:

[Cisco](https://sec.cloudapps.cisco.com/security/center/publicationListing.x): Sicherheitsupdate für mehrere Schwachstelle in unterschiedlichen Produkten

[Ivanti](https://www.ivanti.com/blog/july-security-update-2025): Sicherheitsupdates für mehrere Produkte

[Fortinet](https://www.fortiguard.com/psirt): Sicherheitsupdates für mehrere Produkte

Kurze Zusammenfassung der Sicherheitsupdates aus dem Patch Tuesday Juli 2025

Patch Tuesday Juli 2025

Wissens-Hub | codecentric AG

codecentric Blog

Vor kurzem hatten die Sicherheitsexperten der codecentric den Auftrag, bei einem Unternehmen mit mehreren hundert Mitarbeitern die Sicherheit der IT-Infrastruktur zu testen. Die Auftraggeber wähnten sich in Sicherheit: Die Systeme liefen auf der damals neusten Version von Windows 11 bzw. Windows Server 2022 und ein kommerzielles Antivirusprodukt war im Einsatz.

Und dennoch: Nach zwei Tagen waren die codecentric-Sicherheitsexperten Domänenadministratoren mit Vollzugriff auf alle Systeme, ohne dass der Kunde dies bemerkt hatte. Ein Angreifer hätte aus dieser Position Geschäftsdaten exfiltrieren und alle Systeme verschlüsseln oder löschen können. Wie konnte das passieren?

## Zusammenfassung des Angriffs

Der Angriff wurde im Rahmen eines sogenannten "Assumed-Breach"-Szenarios durchgeführt, d.h. uns wurde ein normales Benutzerkonto ohne besondere Berechtigung zur Verfügung gestellt, wie es ein Angreifer z.B. durch einen Phishing-Angriff erlangen könnte.

Zuerst führen wir dann eine Enumeration der Domäne durch, d.h. wir schauen auf welche Informationen und Daten unserer Benutzer zugreifen kann. Dabei wurde ein geteilter Filestorage gefunden, durch den, aufgrund falscher Konfiguration, **auf persönliche Dateien anderer Benutzer zugegriffen** werden konnte. In diesen Dateien konnten viele Passwörter gefunden werden, unter anderem auch ein altes Backup des Passwortmanagers des IT-Admins. Aus diesen Passwörtern wurde eine Liste erstellt, welche schließlich automatisiert gegen die verfügbaren Systeme ausprobiert wurden.

**Dadurch konnte auf eines der Systeme zugegriffen werden, auf welchen ein Domänenadministrator angemeldet war.** Das Ziel war nun den Speicher des Prozesses auszulesen, in dem die Zugangsdaten des Domänenadministrators temporär gespeichert wurden. Die Ausführung von Schadcode wurde allerdings durch Windows Defender und das Antivirusprodukt verhindert. Aber **mittels eines selbst entwickelten Bypass des AMSI (Antimalware Scan Interface) konnte auch dieser Verteidigungsmechanismus umgangen werden**. Daraufhin konnten die Zugangsdaten des Domänenadministrators ausgelesen und schließlich zum Login auf dem Domänen-Controller verwendet werden.

## Lessons-learned und Maßnahmen

Der oben geschilderte Angriff ist eine gute Demonstration dafür, dass eine Verteidigung von IT-Infrastruktur auf einer Ebene nicht ausreicht. So ist z.B. ein Virenschutz maximal ein temporäres Hindernis für erfahrene Angreifer. Es ist vielmehr ein vielschichtiger Ansatz notwendig, bei dem verschiedene Produkte und Verfahren auf mehreren Ebenen zum Einsatz kommen. Dieses Konzept ist auch als [Defense in Depth](https://www.cloudflare.com/de-de/learning/security/glossary/what-is-defense-in-depth/) bekannt.

Hier sind einige Maßnahmen, die den oben geschilderten Angriff erschwert hätten:

- Härtung der Active-Directory Domäne, sodass z.B. ein normaler Benutzer nur die nötigsten Informationen abfragen darf
- Einführen eines geeigneten Passwortmanagements, beispielsweise über [LAPS](https://learn.microsoft.com/de-de/windows-server/identity/laps/laps-overview), sodass Passwörter lokaler Administrator nicht auf mehreren Systemen verwendet werden
- Benutzung von [Credential Guard](https://learn.microsoft.com/de-de/windows/security/identity-protection/credential-guard/), sodass Zugangsdaten nicht so einfach aus dem LSASS Prozess ausgelesen werden können

Die Maßnahme, die allerdings in diesem Fall den größten Einfluss auf die Erfolgschancen eines Angreifers gehabt hätte, wäre die Benutzung von Werkzeugen zum Logging, Monitoring und Alerting, auch als "[Security Information and Event Management](https://de.wikipedia.org/wiki/Security_Information_and_Event_Management)" (SIEM) bekannt. Die Idee ist es, Logdaten der verschiedensten Systeme zentral zu sammeln, sie auf potentielle Angriffe zu analysieren und bei Erkennung Alarm auszulösen.

Diese Maßnahme schafft eine Sichtbarkeit in die Vorgänge auf Clientsystemen und im Netzwerk und **erlaubt es auf einen Angriff zu reagieren, bevor es zu spät ist**. **Sie macht das Leben der Angreifer deutlich schwieriger**, weil diese auf einmal vorsichtig sein müssen, um keine Warnungen oder Alarme auszulösen. Sie können nun nicht mehr beliebig Dinge ausprobieren, bis eine Sicherheitsmaßnahme umgangen ist. Der oben geschilderte Angriffe hätte so schnell bemerkt werden können.

## Technische Details des Angriffs

### Schritt 1: Enumerieren der Domäne

Mit dem zur Verfügung gestellten, normal privilegierten Benutzerkonto wurden verschiedene Werkzeuge benutzt, um mehr Information über die Domäne zu sammeln:

- [SharpHound + Bloodhound](https://github.com/SpecterOps/BloodHound)
- [adPEAS](https://github.com/61106960/adPEAS)
- Verschieden PowerShell Befehle

Mittels dieser Werkzeuge konnte eine detaillierte Übersicht über Benutzer, Computer, Gruppen und potentielle Privilegien erlangt werden.

Potentielle Gegenmaßnahmen:

- [AD-Benutzern Lesezugriff auf bestimmte Objekte verweigern](https://learn.microsoft.com/en-us/answers/questions/929688/best-practice-to-prevent-active-directory-enumerat)
- Logging & Alerting (SharpHound ist leicht zu erkennen)
- Zugriff auf PowerShell in Citrix erschweren (hierzu sei zu erwähnen, dass ein vollständiges Unterbinden von Kommandozeilen-Aufrufen in der Regel nicht umsetzbar ist)

### Schritt 2: Enumerieren der geteilten Verzeichnisse

Der zur Verfügung gestellte Benutzer hatte Zugriff auf sehr viele geteilte Verzeichnisse. In diesen Verzeichnissen wurde explizit nach Dateien gesucht, die potentiell Zugangsdaten beinhalten. Hierbei konnte unter anderem ein Klartext-Backup des Passwortmanagers des IT-Admins sowie Zugangsdaten eines Benutzers mit RDP-Rechten gefunden werden.

Potentielle Gegenmaßnahmen:

- Zugriff auf geteilte Verzeichnisse einschränken
- Keine privaten Nutzerdaten wie Desktop oder Dokument teilen. Die jeweiligen Nutzerverzeichnisse sollten nur für die jeweiligen Nutzer selbst zugreifbar sein.
- Nutzer sensibilisieren, sodass keine Passwortlisten oder Passwortmanager-Backups im Klartext abgelegt werden → Passwortmanagement
- Logging & Alerting (Automatisierte Durchsuchung ist leicht zu erkennen)

### Schritt 3: Lokaler Administrator auf dem Admin-Jumphost

Dank der Enumerierung der Domäne war bekannt, dass ein Computer existiert, auf dem Domänen-Administratoren gültige und aktive Sitzungen haben. Mittels der gefundenen Zugangsdaten war eine Authentifizierung über das Remote-Desktop-Protokoll auf diesem Computer möglich. Ziel war nun, die dort verfügbaren Berechtigungen zu erweitern, um mit lokalen Administrator-Privilegien die Zugangsdaten der angemeldeten Domänen-Administratoren auslesen.

Hierzu wurde eine Liste mit allen bekannten, lokalen Administrator-Benutzernamen und eine weitere Liste mit allen bereits identifizierten Passwörtern erstellt. Über das Tool [crackmapexec](https://github.com/byt3bl33d3r/CrackMapExec) wurden anschließend alle Kombinationen dieser Benutzernamen und Passwörter automatisiert gegen alle Computer in der Domäne ausprobiert. Dies wurde bewusst ausschließlich gegen lokale Nutzer und nicht gegen Domänenbenutzer durchgeführt, um eine Sperrung von Domänenbenutzern und somit eine Einschränkung der Verfügbarkeit zu vermeiden. Über dieses Verfahren wurden unter anderem gültige Anmeldedaten für einen Jumphost-Server der Administratoren identifiziert. Somit war hier eine Anmeldung mit einem lokalen Systemadministrator möglich.

Gegenmaßnahmen:

- Einführen eines geeigneten Passwortmanagements, beispielsweise über [LAPS](https://learn.microsoft.com/de-de/windows-server/identity/laps/laps-overview)
- Implementieren von geeigneten Gruppenrichtlinien, um das Anmelden von Domänen-Administratoren auf Drittsystemen zu unterbinden ([Schützen von Domänenadministratorgruppen](https://learn.microsoft.com/de-de/windows-server/identity/ad-ds/plan/security-best-practices/appendix-f--securing-domain-admins-groups-in-active-directory))
- Remotedesktopberechtigungen für normale Benutzer auf ein benötigtes Minimum beschränken

### Schritt 4: LSASS Prozess auslesen

Die gehashten Zugangsdaten von aktiven Benutzern werden in Windows im sog. [LSASS-Prozess](https://learn.microsoft.com/en-us/windows-server/security/windows-authentication/credentials-processes-in-windows-authentication) gespeichert. Ein lokaler Administrator hat die Berechtigung, diese Daten auszulesen. Allerdings wurde dies in diesem Fall durch den aktivierten Virenschutz unterbunden. Mittels eines sog. [AMSI-Bypasses](https://pentestlaboratories.com/2021/05/17/amsi-bypass-methods/) konnte der Virenschutz allerdings umgangen werden und der Prozessspeicher mithilfe des [Out-Minidump](https://github.com/PowerShellMafia/PowerSploit/blob/master/Exfiltration/Out-Minidump.ps1) Skripts trotzdem ausgelesen werden. Dieser Dump wurde anschließend auf die eingesetzten Angreifer-Systeme transferiert. Um die darin enthaltenen Hashes auszulesen, wurde das Tool [Mimikatz](https://github.com/gentilkiwi/mimikatz) auf den Angreifer-Systemen genutzt.

Gegenmaßnahmen:

- Benutzung von [Credential Guard](https://learn.microsoft.com/de-de/windows/security/identity-protection/credential-guard/). Allerdings gibt es da auch [Bypasses](https://research.ifcr.dk/pass-the-challenge-defeating-windows-defender-credential-guard-31a892eee22)
- Aktive Sitzungen und Anmeldungen mit Domänenadministratoren außerhalb von Domain-Controllern vermeiden. Generell sollten Domänenadministrator-Konten lediglich zum Administrieren der Domäne selbst genutzt werden.
- Umsetzen eines geeigneten [Privileged Access Models](https://learn.microsoft.com/de-de/security/privileged-access-workstations/privileged-access-access-model) für Administratoren

### Schritt 5: Kerberos Ticket generieren

Mithilfe des ausgelesen Hashs konnte eine sogenannte Pass-The-Key Attacke ausgeführt werden. Dazu wurde das [***getTGT.py***](http://gettgt.py/) Skript von Impacket eingesetzt, um mit dem Hash ein Kerberos Ticket zu bekommen.

Mit diesem Ticket wurden die Berechtigungen eines Domänenadministrators und somit die maximal möglichen Privilegien im Netzwerk erlangt.

Gegenmaßnahmen:

- RC4 Key Typ in Kerberos deaktivieren
- Logging & Alerting

### Schritt 6: Post Exploitation

Mit diesen Berechtigungen waren nun beliebige Aktionen im Domänenumfeld des Netzwerks durchführbar. Mittels ***impacket-secretsdump*** führten wir eine sog. DCSync Attacke durch, die die gehashten Zugangsdaten aller Domänenbenutzer sowie ein Klartext-Passwort des Domänenadministrators lieferte.

Ebenfalls wurde ein eigener Domänen-Administrator mit allen Privilegien angelegt. Von dieser Position wäre ein Angreifer mit bösartigen Absichten beispielsweise in der Lage gewesen, eine Verschlüsselung oder Löschung sämtlicher Unternehmensdaten auszulösen.

Gegenmaßnahmen:

- Logging & Alerting

## Über uns

Wir bei codecentric bieten umfangreiche Beratung und Tests im Bereich IT-Sicherheit an. Spezifisch im Bereich IT-Infrastruktur können wir Ihnen zum Beispiel mit Assessments zur Bestandsaufnahme, Pentests zur Überprüfung oder Red/Purple-Team Übungen zum Training eines Blue-Teams zur Seite stehen. Mehr Informationen finden Sie [hier](https://www.codecentric.de/it-security).

Volle Kontrolle trotz Virenschutz und moderner Systeme - Wie IT-Infrastruktur wirklich geschützt werden kann

Wie IT-Infrastruktur wirklich geschützt werden kann

Im letzten Beitrag haben wir das Plateau der Stabilität, die erste Zwischenstation auf dem Weg zur Resilienz, erörtert – wozu es gut ist, wo seine Grenzen liegen und warum es so beliebt ist.\nIn diesem Beitrag werden wir die 100-%-Verfügbarkeitsfalle, die ich am Ende des letzten Beitrags vorgestellt habe, ausführlicher erörtern und uns erneut mit dem Thema Verfügbarkeit befassen. Wir werden auch die Erkenntnisse diskutieren, die notwendig sind, um die Reise zum nächsten Plateau fortzusetzen.\nDie 100-%-Verfügbarkeitsfalle\nDie 100 %-ige Verfügbarkeitsfalle habe ich bereits in einem \nfrüheren Blogbeitrag\n ausführlich besprochen. Daher fasse ich mich hier kurz.\nDie 100-%-Verfügbarkeitsfalle ist der (immer noch weit verbreitete) Trugschluss, dass IT-Systeme zu 100 % der Zeit verfügbar sind.\nEs ist der Nachfolger der „Ops ist für Verfügbarkeit verantwortlich“-Mentalität. Es ist die implizite Annahme, dass alle Teile der Systemlandschaft, für die man selbst nicht verantwortlich ist, nie und nimmer ausfallen werden.\nNatürlich würde jede(r), wenn er bzw. sie direkt gefragt würde, zustimmen, dass alle Teile der Systemlandschaft ausfallen können und dass der Zeitpunkt des Ausfalls in der Regel nicht vorhergesagt werden kann. In der Praxis wird dieses theoretische Wissen jedoch weitgehend ignoriert. Nur selten werden Designs und Implementierungen erstellt, die mögliche Ausfälle anderer Systemteile berücksichtigen wie z. B.:\nBetriebssysteme\n⁠Scheduler (wie z. B. Kubernetes) u. ä.\nRouter\nSwitches\nMessage Busses\nDatenbanken\nService Meshes\nCloud-Dienste\nund insbesondere andere Anwendungen und Dienste.\nBei der Konzeption und Implementierung wird implizit davon ausgegangen, dass alles, was über den Rahmen der eigenen Anwendung hinausgeht, jederzeit verfügbar ist. Wir können es überall sehen:\nDas Senden von Nachrichten oder Events an einen Message Bus wird als ausreichend angesehen, um die garantierte und korrekte Verarbeitung der Nachrichten bzw. Events zu gewährleisten.\nDas Erstellen von Anwendungen, die beim Start versuchen, Verbindungen zu allen Systemen herzustellen, mit denen sie zusammenarbeiten. Sollte eines der Systeme nicht verfügbar sein, stürzt die Anwendung einfach mit einer Fehlermeldung ab, da diese Situation nicht erwartet wird. [1]\nDas blinde Verlassen auf die perfekte Verfügbarkeit der Dienste eines Cloud-Anbieters. Als z. B. Kinesis bei AWS einmal ausfiel, fielen die Anwendungen der meisten Unternehmen, die Kinesis nutzen, ebenfalls aus, weil sie nicht mit Blick auf einen möglichen Ausfall von Kinesis (oder eines anderen AWS-Dienstes) entwickelt wurden. All diese Anwendungen gingen blind davon aus, dass Kinesis niemals ausfallen würde, auch wenn das SLA von Kinesis etwas anderes besagte.\nUnd so weiter …\nMein persönliches Erklärungsmodell für dieses weit verbreitete Verhalten ist, dass es sich um eine Verallgemeinerung der tief verwurzelten „Ops ist für Verfügbarkeit verantwortlich“-Mentalität handelt. Es scheint, dass die „Problem Anderer Leute“-Einstellung (auch bekannt als P.A.L.) in Bezug auf die Verfügbarkeit eines nicht von einem selbst betreuten Systemteils sehr oft zu einer impliziten Annahme von 100 % Verfügbarkeit führt (selbst wenn die verantwortliche Partei in ihrem SLA deutlich macht, dass sie \nkeine\n 100 % Verfügbarkeit garantiert).\nDie 100-%-Verfügbarkeitsfalle führt sehr oft auch zu einer Art implizitem „Induktionsbeweis“ bezüglich Verfügbarkeit:\nAlles außer den Systemteilen, für die ich verantwortlich bin, ist zu 100 % verfügbar.\nWenn ich also Ausfälle in meinen Teilen mit Hilfe der anerkannten Redundanz-, Failover- und Überlastvermeidungsmethoden (siehe die Beschreibung des Stabilitätsplateaus im vorherigen Beitrag) vermeide, ist alles zu 100 % verfügbar.\nDer vielleicht faszinierendste Aspekt der 100 %igen Verfügbarkeitsfalle ist jedoch, dass sie allen anerkannten und bewährten Ingenieurspraktiken völlig widerspricht. Pat Helland und Dave Campbell begannen ihr großartiges Paper „Building on Quicksand“ mit dem Satz:\nZuverlässige Systeme wurden schon immer aus unzuverlässigen Komponenten gebaut.\nDas heißt, wir rechnen damit, dass die verwendeten Komponenten ausfallen können und entwerfen und implementieren unsere Systeme so, dass sie trotz des Ausfalls der verwendeten Komponenten zuverlässig funktionieren. Zumindest ist dies die akzeptierte und bewährte Ingenieurspraxis.\nAußer bei der Entwicklung von Unternehmenssoftware!\nBei der Entwicklung von Unternehmenssoftware neigen wir dazu, diese Praxis auf den Kopf zu stellen:\nBei der Entwicklung von Unternehmenssoftware bauen wir unzuverlässige Systeme (Anwendungen und Dienste) und erwarten von den verwendeten Komponenten (Infrastruktur und Middleware), dass sie das Gesamtsystem zuverlässig machen.\nDies ist das genaue Gegenteil davon, wie zuverlässige Systeme aufgebaut werden –­­ eine Auswirkung der 100-%-Verfügbarkeitsfalle, die immer noch sehr weit verbreitet ist.\nDas ist der Grund, warum so viele Unternehmen auf dem Plateau der Stabilität feststecken – einfach weil sie die 100-%-Verfügbarkeitsfalle noch nicht überwunden haben.\nDie zweite Erkenntnis\nDie 100-%-Verfügbarkeitsfalle ist jedoch eine Sackgasse in Bezug auf die Ausfallsicherheit, denn wie Michael Nygard in \neinem seiner Blog-Beiträge\n schreibt:\nKontinuierliche Teilausfälle sind der Normalzustand.\nHeutige komplexe und hochgradig vernetzte Systemlandschaften laufen fast immer in einer Art degradiertem Modus, d.h. fast immer funktionieren einige Teile davon nicht wie erwartet.\nUnd Werner Vogels, der CTO von Amazon, benutzte die folgende, nur teilweise scherzhafte Definition, um verteilte Systeme zu beschreiben:\nAlles kaputt. Andauernd. (Everything fails, all the time.)\nBeide wissen viel über verteilte Systeme und den Betrieb großer, komplexer, verteilter und stark vernetzter Systemlandschaften. Ihre Erkenntnisse sind die gleichen:\nAusfälle sind unvermeidlich.\nIm Grunde ist diese Erkenntnis nicht neu und nicht auf verteilte Systeme beschränkt. Michael Nygard z. B. macht in seinem oben erwähnten Blog-Beitrag deutlich, dass Ausfälle bei allen Arten von Systemen etwas ganz Normales sind.\nBis zum Plateau der Stabilität haben die Menschen jedoch immer noch ihre Scheuklappen auf und versuchen, die Tatsache zu ignorieren, dass Fehler unvermeidlich sind.\nDaher besteht die zweite notwendige Erkenntnis darin, \nzu akzeptieren, dass Fehler unvermeidlich sind\n, was uns weg von der Vermeidung von Ausfällen hin zum Akzeptieren und sinnbildlichen "Umarmen" von Ausfällen führt.\nVerfügbarkeit neu bewertet\nWas bedeutet das für Verfügbarkeit? Wie können wir Verfügbarkeit maximieren, wenn Ausfälle unvermeidlich sind?\n\n\nUm diese Fragen zu beantworten, müssen wir kurz zur Formel für Verfügbarkeit zurückkehren:\nVerfügbarkeit := MTTF / (MTTF + MTTR)\nmit\nMTTF: Mean Time To Failure (Durchschnittliche Zeit bis zum Ausfall), die durchschnittliche Zeit vom Beginn des Normalbetriebs bis zum Ausfall des betrachteten Systems, d.h. bis zum Auftreten eines von der Spezifikation abweichenden Verhaltens.\nMTTR: Mean Time To Recovery (Durchschnittliche Zeit bis zur Wiederherstellung), die durchschnittliche Zeit nach einem Ausfall, bis das betrachtete System wieder den normalen Betrieb aufnimmt, d. h. wie spezifiziert arbeitet.\nWenn wir uns diese Formel ansehen, können wir einige Beobachtungen machen:\nDer Nenner beschreibt die Gesamtzeit, während der Zähler die Zeit angibt, in der das System wie vorgesehen funktioniert, sprich der Bruch beschreibt den Anteil der Zeit, in der das System wie vorgesehen funktioniert.\nMTTF und MTTR sind beide positive Zahlen. Theoretisch könnten beide auch 0 sein, aber in der Praxis können wir davon ausgehen, dass beide Zahlen positiv sind, solange das betrachtete System überhaupt in der Lage ist, spezifikationskonform zu arbeiten (also MTTF ist nicht 0 ist).\nAus der Tatsache, dass MTTF und MTTR beide positive Zahlen sind, können wir schließen, dass der Nenner immer größer ist als der Zähler, d. h., der Wert des Bruches ist eine Zahl zwischen 0 und 1 (beides in der Praxis ausgeschlossen) - oder zwischen 0 % und 100 %, wenn du Prozentsätze lieber magst.\nJe größer MTTF im Vergleich zu MTTR ist, desto näher liegt die Verfügbarkeit bei 1 (oder 100 %).\nLetztendlich geht es uns darum, dass die Verfügbarkeit so nahe wie möglich an 1 (oder 100 %) herankommen soll.\nAuf dem Plateau der Stabilität versuchen die handelnden Personen, Ausfälle zu vermeiden. Sie versuchen, MTTF so groß zu machen, dass MTTR keine Rolle mehr spielt. Wenn du sie fragen würdest, würden sie wahrscheinlich nicht sagen, dass sie versuchen, MTTF unendlich groß zu machen, sondern dass sie versuchen, MTTF \nhinreichend\n groß zu machen. [2]\nEine solche „hinreichend große“ MTTF könnte zum Beispiel 1.000.000 Stunden betragen. Dies würde eine erwartete Verfügbarkeit von mehr als 100 Jahren bedeuten. Wenn du davon ausgehst, dass nicht du, sondern deine Nachkommen mit einem Ausfall konfrontiert werden, ist dir MTTR eigentlich egal - einfach weil du keinen Ausfall erwartest. Es spielt keine Rolle, ob MTTR eine Stunde, einen Tag oder eine Woche beträgt. Selbst wenn MTTR eine Woche betragen würde, wäre die Gesamtverfügbarkeit immer noch höher als 99,98 %.\nDa aber die MTTF als so hoch angenommen wird, denkt niemand über 99,98 % nach, sondern alle erwarten implizit, dass das System niemals ausfällt. Willkommen in der 100-%-Verfügbarkeitsfalle!

Wenn wir jedoch akzeptieren, dass Ausfälle unvermeidlich sind, müssen wir auch akzeptieren, dass MTTF für unser System eine Obergrenze hat. Wir können MTTF nicht willkürlich erhöhen. Wir kennen die Obergrenze nicht genau, aber höchstwahrscheinlich liegt sie näher bei 1.000 Stunden (das sind etwas mehr als 40 Tage) als bei 1.000.000 Stunden.\nWenn wir für unser System eine MTTF von 1.000 Stunden annehmen, wäre selbst eine MTTR von „nur“ einem Tag ein Problem, da dies eine Gesamtverfügbarkeit von ca. 97,5 % bedeuten würde, was für die meisten Szenarien zu wenig ist. Eine MTTR von 1.000 Stunden macht auch deutlich, dass Ausfälle nicht unsere Nachkommen treffen werden, sondern uns!\nDas bedeutet, dass es keine Option ist, einfach zu versuchen, MTTF immer weiter zu erhöhen und dabei MTTR zu ignorieren, wenn wir akzeptieren, dass Ausfälle unvermeidlich sind und MTTF daher eine Obergrenze hat, die wir einfach nicht überwinden können. Wir sollten immer noch versuchen, eine gute MTTF zu erreichen, aber um unsere Gesamtverfügbarkeit weiter zu erhöhen, müssen wir auch unsere MTTR im Auge behalten und versuchen, sie zu verringern.\nWenn wir in unserem Beispiel MTTR von einem Tag auf eine Stunde senken, würde die Verfügbarkeit auf 99,9 % steigen (unter der Annahme einer MTTF von 1.000 Stunden), was sich wesentlich besser anhört als 97,5 %.\nZusammengefasst: Wenn wir verstehen, dass Ausfälle unvermeidlich sind, erkennen wir auch, dass MTTF eine Obergrenze hat und nicht beliebig erhöht werden kann. Um die gewünschte hohe Verfügbarkeit zu erreichen, müssen wir also zusätzlich MTTR reduzieren.\nDie dritte Erkenntnis\nMit dieser Einsicht denken wir dann über die möglichen Arten von Fehlern nach, die uns treffen könnten, und darüber, wie wir sie schnell beheben können, d. h. wie wir unsere MTTR verringern können [3]. Dies führt unmittelbar zur dritten Erkenntnis:\nEs gibt andere Fehlerarten als Abstürze und Überlastsituationen.\nAuf dem Plateau der Stabilität neigt man dazu, sich auf Abstürze und Überlastsituation zu konzentrieren und versucht, diese mit allen Mitteln zu vermeiden, in der Annahme, dass dies ausreicht, um die gewünschte Verfügbarkeit zu erreichen.\nWenn man akzeptiert, dass Ausfälle unvermeidlich sind, fängt man an, sich die Fehler genauer anzuschauen, die das eigene System heimsuchen. Dann erkennt man sofort eine ganze Reihe von Fehlertypen, die nur darauf warten, die Robustheit deines Systems herauszufordern, wie z. B.:\nAbsturzfehler\nÜberlastfehler\nAuslassungsfehler\nZeitfehler (Latenzen)\nAntwortfehler\nByzantinische Fehler\nSoftware-Fehler\nKonfigurationsfehler\nFirmware-Fehler\nSicherheitslücken\nUnd, und, und ...\nAll diese Fehlermöglichkeiten führen in der Praxis zu einigen recht unangenehmen Auswirkungen, wie z. B.:\nWir verlieren Nachrichten vollständig oder erhalten unvollständige Updates.\nWir erhalten Nachrichten mehrfach.\nEs kommt zu Zeitüberschreitungen bis hin zum völligen Stillstand der gesamten Systemlandschaft aufgrund von Abhängigkeiten in der Aufrufkette.\nKnoten erhalten Updates in unterschiedlicher Reihenfolge (out-of-order), was zu unterschiedlichen Wissensständen der betroffenen Knoten führt (out-of-sync).\nWir erleben Split-Brain-Situationen, in denen Teile der Systemlandschaft einander und ihre jeweiligen Updates nicht sehen.\nWir treffen auf persistente Fehlfunktionen von Systemen oder Systemteilen, z. B. aufgrund von Softwarefehlern.\nWir stoßen auf metastabile Ausfälle, d. h. auf Situationen, in denen das Fehlverhalten auch dann noch andauert, wenn die ursprüngliche Fehlerursache beseitigt wurde.\nWir verlieren Daten oder haben beschädigte Daten.\nWir verlieren („leaken") vertrauliche Informationen.\nUnd so weiter …\nAll diese unschönen Dinge und noch viele weitere können passieren, was deutlich mehr ist als nur die Auswirkungen von Abstürzen und Überlastfehlern.\nIch habe z. B. einmal mit einem Kunden gearbeitet, der auf dem Plateau der Stabilität lebte. Er hat einen enormen Aufwand betrieben, um Absturz- und Überlastfehler zu vermeiden, aber alle anderen Arten von Fehlern weitgehend ignoriert. Für die Behebung von Softwarefehlern brauchten sie in der Regel Tage bis Wochen, weil sie ein sehr komplexes und rigides Deployment-Verfahren mit vielen Stufen und menschlichen Freigaben hatten, um „sicherzustellen, dass nichts schief geht“ (zur Erinnerung: Auf dem Plateau der Stabilität wird MTTR in der Regel ignoriert, was bedeutet, dass manuelle Deployment-Prozesse als "okay" angesehen werden).\nIch war auch Zeuge eines Fehlers, den sie in der Konfiguration der Datenreplikation für eine ihrer Control Planes hatten. Der Konfigurationsfehler blieb unbemerkt, bis eines Tages der ursprüngliche Primary der Control Plane ausfiel. Es wurde automatisch ein anderer Primary bestimmt. So weit, so gut. Leider hatte der neue Primary aufgrund des Fehlers in der Replikationskonfiguration nie Aktualisierungen über den Zustand der zugehörigen Worker Nodes erhalten. Die Zustandsdatenbank des neuen Primary war im Grunde genommen ein leeres Blatt – sie enthielt nichts. Infolgedessen fuhr die Control Plane sofort alle Worker Nodes herunter, da sie aufgrund der (fehlenden) Zustandsdaten in der Datenbank des neuen Primary zu dem Schluss kam, dass nichts (mehr) laufen sollte. Ups!\nEs dauerte fast eine Woche, bis der normale Betrieb wieder aufgenommen werden konnte, denn in ihrem Stabilitätsdenken war dies etwas, das als Fehlermöglichkeit nicht vorgesehen war. Sie hatten damit keine Möglichkeit, im Rahmen ihrer unzähligen ausgeklügelten Prozessen und Regeln zügig darauf zu reagieren, weil die implizite Annahme war, dass solche Ausfälle nicht vorkommen können.\nWenn man aber akzeptiert, dass Fehler unvermeidlich sind, beginnt man auch, diese Fehlerarten genauer unter die Lupe zu nehmen. Man fragt sich vor allem, wie man solche Fehler schneller erkennen und beheben kann, um die MTTR zu verringern.\nDiese beiden Erkenntnisse – dass Fehler unvermeidlich sind und dass es viele Arten von Fehlern gibt – führen uns zu unserem zweiten Zwischenstopp, den wir in unserem nächsten Beitrag erörtern werden.\nZusammenfassung\nWir haben uns die 100-%-Verfügbarkeitsfalle angesehen und gelernt, dass sie ein falscher Freund ist, der uns zu unzulässigen Annahmen verleitet. Dies führte uns zu der Erkenntnis, dass Ausfälle unvermeidlich sind.\nWir haben uns dann erneut mit dem Thema Verfügbarkeit befasst und festgestellt, dass es nicht ausreicht, MTTF zu erhöhen, wenn wir Verfügbarkeit maximieren wollen, sondern dass wir auch MTTR verringern müssen. Die Überlegung, wie MTTR reduziert werden kann, führte zu der Erkenntnis, dass es viele Arten von Ausfällen gibt, die berücksichtigt werden müssen.\nMit diesen beiden Erkenntnissen sind wir bereit für das nächste Plateau, das Plateau der Robustheit, das wir in unserem nächsten Beitrag behandeln werden. Bleibt dran ... ;)\n\n[1] Diese Art der Programmierung führt übrigens zu einem sehr unangenehmen Verhalten der Systemlandschaft nach größeren Ausfällen, die die gesamte Systemlandschaft oder zumindest einen größeren Teil davon zum Erliegen gebracht haben. Wenn die Administratoren versuchen, die Systeme wieder hochzufahren, fahren sich nahezu alle Systeme sofort wieder herunter, weil ein oder mehrere andere Systeme, die sie zur Laufzeit benötigen, noch nicht verfügbar sind. Die Administratoren müssen dann manuell – häufig durch Ausprobieren – die Abhängigkeiten zwischen den Systemen herausfinden und versuchen, die Systeme eines nach dem anderen in der richtigen Reihenfolge hochzufahren. Im schlimmsten Fall hat sich im Laufe der Zeit eine zyklische Abhängigkeit zwischen einigen Systemen entwickelt und die Administratoren stehen im Regen.\n[2] Meiner Erfahrung nach machen sich Leute, die sich auf dem Plateau der Stabilität befinden, nicht allzu viele Gedanken über Dinge wie MTTF und Ähnliches. Normalerweise wenden sie die „Standardmaßnahmen“ wie Redundanz und Rate Limiting an. Basierend auf diesen Maßnahmen und der genutzten Middleware und Infrastruktur gehen sie dann davon aus, dass dies ausreichend ist, d. h. dass sie sich über diese Standardmaßnahmen hinaus keine weiteren Gedanken über Verfügbarkeit machen müssen, sondern davon ausgehen können, dass keine Ausfälle auftreten werden.\n[3] Hoffentlich denken wir nicht nur darüber nach, welche Ausfälle uns treffen könnten, sondern erheben auch Daten zu den in der Produktion tatsächlich auftretenden Ausfällen und wie lange es dauert, sie zu beheben.\nDieser Blogpost ist \nursprünglich auf Englisch\n in Uwe Friedrichsens Blog erschienen.

Was ist Resilienz in IT-Systemen? Uwe Friedrichsen erklärt, wie Robustheit und Denkmodelle helfen, unerwartete Herausforderungen zu meistern. Jetzt lesen!

Was ist Resilienz? Grundlagen für IT-Systeme. Part 4.

Der lange und steinige Weg zur Resilienz – Teil 4

Senior Integration Architect

Wie löst man am einfachsten einen Flame-War aus? Man nehme zwei Sprachen und vergleiche sie auf Basis *einer* Eigenschaft. Ich habe mehr als 20 Jahre meines Berufslebens mit Java verbracht, jetzt schaue ich mir Rust an und dachte mir: Warum nicht mal die Performance vergleichen? Rust soll ja so schnell wie C sein, wobei ich auch schon gelesen habe, dass der Just in Time Compiler von Java so gut wie der C-Compiler ist. Sind sie also alle drei gleich schnell? In diesem Blog-Post lasse ich C aus und vergleiche nur Java und Rust.

Warum mache ich das überhaupt und lerne nach langer Zeit eine neue Sprache? An der Universität habe ich C genutzt. Für die Entwicklung von Betriebssystemen war das einfach die Sprache der Wahl. Auch in den Jahren danach habe ich C immer noch für die beste Sprache für diese Aufgabe gehalten. Mit dem Aufkommen von Rust bin ich mit dieser Aussage vorsichtig geworden: Ich kenne die Nachteile von C aus eigener Erfahrung nur zu gut. Arrays ohne Bereichskontrolle und manuelle Speicherverwaltung (teilweise mit Referenz-Zählern) lassen einen die militärischen Dienstgrade des Linux-Kernels kennerlenen: "Kernel panic", "Major failure" und "General protection fault". 

Die Vorstellung, Business-Anwendungen mit C zu schreiben, löst bei mir nur Gruselgefühle aus. Da kommt es meistens nicht auf die letzte Nanosekunde im eigenen Code an, eher darauf, dass man sinnvoll mit der Datenbank, Frameworks oder REST-Schnittstellen umgeht. Da habe ich Java lange Zeit für eine sehr gute Wahl gehalten: Strickte Memory-Checks, Garbage Collection und eine Unzahl von verfügbaren Bibliotheken machen einem das Leben dort einfach.

Daher galt lange Zeit für mich: C für Betriebssysteme oder Microcontroller, Java für Business Anwendungen. Und dann kommt Rust um die Ecke: Die Sicherheit von Java kombiniert mit Eigenschaften, die eine Performance ähnlich wie in C versprechen. Damit erscheint Rust auch für low-level-Programmierung geeignet. Diese Argumente führen dazu, dass Rust inzwischen auch im Linux-Kernel einzieht.

Da man Benchmarks (wie Statistiken) nur glauben kann, wenn man sie selbst gefälscht hat, habe ich mich hingesetzt und ein kleines (sehr altes) Java-Programm von mir in Rust neu implementiert. 

Bei Benchmarks muss man beachten, was man wirklich misst. Was ist ein guter Vergleich? Man könnte beispielsweise ein ERP-System zu Vergleichszwecken doppelt implementieren (Java + Rust) und dann die beiden Versionen vergleichen. Ist ziemlich teuer und liefert Zahlen. Aber welche? Am Ende vergleicht man hier vermutlich eher die Implementierungen der verwendeten Bibliotheken als die der Sprache an sich. Ist das falsch? Wenn es um den Vergleich der Ökosysteme und nicht nur des Sprachkerns geht sicher nicht. Man könnte dann auch vergleichen, wie viel Zeit die Teams jeweils für die Implementierung benötigen. Das Ergebnis ist natürlich nur valide, wenn die Teams in ihrem jeweiligen Ökosystem gleich gut sind. Die notwendigen Ressourcen habe ich nicht, so habe ich es bei einem einfachen Vergleich belassen, der nur den Sprachkern und kleine Teile der Standardbibliothek nutzt. 

Ich habe mich nach Benchmarks umgeschaut, eine Liste von kleinen, algorithmischen Benchmarks findet man zum Beispiel auf der Seite [Programming Language and compiler
Benchmarks](https://medium.com/deno-the-complete-reference/java-vs-rust-how-faster-is-machine-code-compared-to-interpreted-code-for-jwt-sign-verify-fa6aeeabff58). Warum hat mich das nicht zufrieden gestellt? Bei einigen Benchmarks ist der Java und Rust Code strukturell deutlich unterschiedlich, so dass mir die Vergleichbarkeit fehlt. Außerdem fehlt mir die Analyse, warum die eine oder andere Variante schneller ist. Ein anderer Benchmark - [Java vs Rust: How faster is machine code compared to byte code for JWT sign &amp; verify?](https://medium.com/deno-the-complete-reference/java-vs-rust-how-faster-is-machine-code-compared-to-interpreted-code-for-jwt-sign-verify-fa6aeeabff58) - vergleicht aus meiner Sicht nur die verwendeten Bibliotheken.

## Die Aufgabe

Die für den Vergleich genutzte Aufgabe und das zugehörige Java-Programm habe ich vor Jahren in einem Blog-Post beschrieben: [Fork/Join und andere Optimierungen von Algorithmen](https://www.codecentric.de/wissens-hub/blog/java-forkjoin-optimierung-programme). Damals habe ich verschiedene Parallelisierungsstrategien verglichen, in diesem Blog-Post vergleiche ich nur sequentielle Varianten. Umgebung war jeweils mein Laptop unter Windows.

Was ist die Aufgabe? Es geht darum, die Anzahl der möglichen Lösungen für eine dreieckige [Solitär](https://de.wikipedia.org/wiki/Solitär_(Brettspiel)), auch Toblerone-Puzzle genannt, zu ermitteln. Das Brett hat die Kantenlänge `n`, in der dritten Reihe von oben befindet sich in der Mitte ein freies Feld, alle anderen Felder sind mit Steinen belegt. Ein Stein darf über einen anderen Stein springen, der dann entfernt wird. Das Spiel ist gelöst, wenn nur noch ein Stein - egal wo - übrig ist.

Hier eine Startkonfiguration für ein Spielfeld der Größe fünf: 

```
      x 
     x x
    x o x
   x x x x
  x x x x x
```

Die Anzahl der Steine auf dem Spielfeld steigt quadratisch mit der Kantenlänge, der Berechnungsaufwand exponentiell mit der Anzahl der Steine. Kombiniert ergibt das O(2 hoch (n*n)). Für die Größe der ersten Spielfelder ergibt sich:

|Kantenlänge|Anzahl Felder|
|---|---|
| 5 | 15 |
| 6 | 21 |
| 7 | 28 |
| 8 | 36 |
| 9 | 45 |

Spielfelder mit einer Kantenlänge kleiner oder gleich sieben lassen sich in einer 32 Bit Ganzzahl speichern, anschließend benötigt man eine 64 Bit Zahl, um das Feld zu speichern. Man kann übrigens beweisen, dass sich jede dritte Spielfeldgröße nicht lösen lässt: 4, 7, 10, 13 und so weiter. Einen Beweis dazu habe ich am Ende meines alten Blog-Posts aufgeschrieben.

Der Kern des Algorithmus besteht aus einer Tiefensuche mit Cache, damit gleiche Stellungen nicht mehrfach ausgewertet werden. Hier die Java-Version:

```Java
long countSolutions(long[] cache, Board start) {
	int asInt = start.asInteger();
	if (cache[asInt] != -1) {
		return cache[asInt];
	} else if (start.isSolution()) {
		cache[asInt] = 1;
		return 1;
	} else {
		long count = 0;
		List nextBoards = start.nextBoards();
		for (Board board : nextBoards) {
			count += countSolutions(cache, board);
		}
		cache[asInt] = count;
		return count;
	}
}
```

Bei `Board` handelt es sich um ein Interface, hinter dem - je nach Feldgröße - ein `int` oder `long` verbirgt. Diese konkrete Methode `countSolutions()` funktioniert allerdings nur mit Feldern bis Kantenlänge sieben, da das Feld in seiner Bit-Darstellung direkt als Array-Index für den Cache verwendet wird. Für größere Spielfelder benötigt man eine andere Cache-Implementierung. Die Größe des Caches beträgt für `n=7`übrigens zwei Gigabyte. Für den alten Blog-Artikel hatte ich auch versucht, die Anzahl der Lösungen für Kantenlänge acht zu ermitteln. Spoiler: Es ist mir nicht gelungen.

Die Werte im Array stehen für die Anzahl der Lösungen der zugehörigen Stellung, -1 für "noch nicht untersucht". Also kann jeder Wert ungleich -1 direkt ohne weitere Berechnung zurückgegeben werden. Handelt es sich um eine "gelöste Stellung" (nur noch ein Stein auf dem Feld), gibt die Methode 1 zurück. Ansonsten beginnt die Arbeit: Liste der Nachfolgefelder erzeugen, die mit einem Zug erreichbar sind, für alle die Anzahl von Lösungen (rekursiv) ermitteln, addieren, im Cache eintragen und zurückgeben. Wer den Code der restlichen Methoden sehen möchte, kann im [Github-Repository](https://github.com/rbutenuth/java-vs-rust ) nachschauen. Dort befinden sich verschiedene Java- und Rust-Varianten in einem Repository. Sowohl für Java als auch für Rust existiert eine Funktion, mit der sich die Anzahl der gesetzten Bits in einer Ganzzahl zählen lässt. Vermutlich basieren sie auf dem gleichen Assemblerbefehl, selbst muss man keine Bitfummelei dazu implementieren. 

In Rust sieht der Kern des Algorithmus sehr ähnlich aus:

```Rust
fn count_solutions(mut cache: &amp;mut[i64], board: Box) -&gt; i64 {
    let index = board.as_usize();
    if cache[index] != -1 {
        cache[index]
    } else if board.is_solution() {
        cache[index] = 1;
        1
    } else {
        let mut count: i64 = 0;
        let next_boards = board.next_boards();
        for board in next_boards {
            count += count_solutions(cache, board)
        }
        cache[index] = count;
        count
    }
}
```

Der Cache besteht hier aus einem `Vec`, an die Methode wird eine mutable Slice-Sicht daraus übergeben. Die Lösung entspricht einem Array in Java. Das Spielfeld, in Java durch ein Interface repräsentiert, ist hier ein Trait mit zwei Implementierungen: Für kleine Felder 32 Bit, für größere 64 Bit. An die Stelle der `ArrayList` mit den Folgestellungen tritt hier ein `Vec`, auch hier kaum Unterschiede zwischen den beiden Sprachen. 

## Performance

Welche Laufzeit ergibt sich für die beiden Implementierungen, wenn man ein Spiel mit Kantenlänge sieben spielt? Das Ergebnis überrascht auf den ersten Blick:

* Java 21, 20 s
* Rust, debug version: 111 s
* Rust, release version: 36 s

In Java habe ich den Code sicherheitshalber in einer Schleife zwei mal laufen lassen, damit der JIT sich warmlaufen kann. Die Unterschiede sind aber marginal, die JIT-Zeiten für die wenigen, kleinen Methoden fallen offensichtlich kaum ins Gewicht. Bei Rust muss man natürlich darauf achten, die Release-Version mit eingeschaltetem Optimizer zu nutzen. Die spannende Frage: Warum ist Rust trotz Optimizer langsamer als Java? Der Grund liegt im Trait und den Möglichkeiten eines JIT Compilers versus eines ahead of time Compilers: Der Rust Optimizer kann sich nur auf statische Informationen stützen, die zur Compile-Zeit vorliegen. Der Java JIT Compiler sieht jedoch die aktuell vorliegenden Daten: Er kann auf das kleine Feld (mit 32 Bit) optimieren und muss beim Methodenaufruf keinen dynamischen Dispatch durchführen. Da bis zur Kantenlänge sieben sowieso nur das Feld mit 32 Bit notwendig ist, habe ich eine zweite Version des Rust Codes geschrieben, direkt mit einer `struct`, ohne Trait. Die Signatur der Funktion ändert sich dadurch, der Rumpf bleibt syntaktisch gleich (wird aber natürlich zu anderem Assemblercode übersetzt):

```Rust
fn count_solutions(cache: &amp;mut[i64], board: SmallBoard) -&gt; i64 {
```

* Rust, debug version: 81 s
* Rust, release version: 17 s

Mit dieser Version ist Rust schneller als Java, ca 15 %. Keine Größenordnung, aber immerhin. Was lernen wir daraus? 

1. Rust rühmt sich für die vielen zero cost abstractions, die zwar dem Compiler Arbeit machen, dafür zur Laufzeit keine Kosten erzeugen. Der Aufruf von trait associated functions gehört nicht dazu: Hier muss ein dynamischer Dispatch erfolgen, der einen Lookup im Speicher erforderlich macht. Ich vermute, dass dadurch auch die Sprungvorhersage von modernen Prozessoren ausgehebelt wird. 
2. Der JIT Compiler von Java erzeugt sehr effizienten Code, bei Berücksichtigung von Laufzeitinformationen manchmal sogar schnelleren Code als der Rust-Compiler.
3. `ArrayList` in Java und `Vec` sind zwar ähnlich, aber nicht gleich: Java speichert in dem dahinterliegenden Array nur Referenzen, Rust die Objekte selbst. Java hat dadurch beim Skalieren Vorteile (nur Referenzen kopieren, keine Inhalte), Rust beim Zugriff: Die Indirektion über die die Referenz entfällt.

Was ich nicht gemessen habe sind die Startup-Zeiten der beiden Versionen. Bei dieser Größe sind sie für beide zu vernachlässigen. Wer mit großen Java-Anwendungen mit vielen Bibliotheken arbeitet, weiß aber, dass der Start relevant Zeit benötigt. Egal ob fat jar oder einzelne jars: Es muss viel Bytecode geladen und dann durch den JIT verarbeitet werden. Überschläglich gemessen habe ich den Ressourcenverbrauch der beiden Versionen. 

Für Rust habe ich übrigens noch eine dritte Version implementiert, die komplett auf `struct` und assoziierte Methoden verzichtet. Weiterhin ist der `Vec` für die aus einer Stellung ermittelten Nachfolgestellungen durch ein Array fester Größer ersetzt, das komplett auf dem Stack liegt. Das ist möglich, da es bei einem Spielfeld mit 32 Feldern nie mehr als 32 Züge aus einer Stellung geben kann. Die Aufrufe für eine dynamische Speicherverwaltung (`malloc()`, `free()`), die `Vec` im Hintergrund durchführt, fallen somit weg. Die Zeit sinkt damit von 17 s auf 12 s. Der zugehörige Code ist aber so hässlich, dass ich ihn hier nicht zeigen möchte. Im git Repository steht er im Verzeichnis `array_solver_with_cache`.

## Ressourcenverbrauch

Lässt man Java ohne `-Xmx` Parameter laufen, liegt der Speicherverbrauch bei ca. 3.380 MByte (Erinnerung: 2 GByte werden für den Cache verbraucht). Ein Blick in den Task-Manager (ich arbeite mit Windows) zeigt, dass während der Laufzeit meistens nur einer der CPU-Kerne beschäftigt ist. Der "Kleinkram" - die Felder - lebt offensichtlich kurz genug, so dass der Garbage Collector mit genügend Reserve im Heap recht schnell ist. Anders sieht es aus, wenn man den Heap per `-Xmx2053m` auf den Wert verkleinert, der für den Cache und den Kleinkram notwendig ist. Der Gesamtspeicherverbrauch liegt dann bei ca. 2.117 MByte, das heißt, ca. 64 MByte benötigt die JVM zusätzlich zum Heap. Die Laufzeit steigt auf 53 s, mehr als das Doppelte. Im Task Manager sieht man, dass der Garbage Collector die restlichen Kerne auch in Beschlag nimmt.

Bei Rust gibt man keine Heap-Größe an, die Laufzeit nimmt sich, was angefordert wird. Laut Task-Manager benötigt die Anwendung 2048,4 MByte, zusätzlich zum Cache also nur 400 KByte, deutlich weniger als die 64MByte der Java-Variante. 

Die Erkenntnis aus diesen Beobachtungen: Java ist in diesem Benchmark geringfügig langsamer als Rust, benötigt dafür aber deutlich mehr Ressourcen: Speicher und/oder CPU. Wenn man nur einen Benchmark ausführt und der eigene Laptop sich ansonsten langweilt ist es relativ egal, in der Praxis für größere Anwendungen gilt dies jedoch nicht: CPU und Speicher müssen bezahlt werden, sowohl im lokalen Rechenzentrum als auch in der Cloud. Startup-Zeiten sind ebenso relevant, wenn nicht ein Service mit konstanter Last lange läuft, sondern die Anwendung on demand skaliert wird oder als Lambda läuft: Instanzen sollten dann schnell verfügbar sein.

## Fazit

Was nehme ich aus den Messungen für mich mit? Ob man - wie Rust - direkt Maschinencode erzeugt oder - wie Java - zweistufig vorgeht (Bytecode, Maschinencode) hat beides Vor- und Nachteile: Ein JIT kann die aktuellen Daten berücksichtigen, benötigt jedoch zusätzliche Ressourcen zur Laufzeit. Für lang laufende Server-Anwendungen mit vielen Threads und viel RAM für Daten fällt dies unter Umständen nicht stark ins Gewicht. Benötigt man jedoch kleine Server mit schneller Startup-Zeit für flexible Skalierung, macht sich dieser Overhead stärker bemerkbar, hier hat Rust klare Vorteile. Bei der Generierung des Titelbildes lag die KI mit einem fetten Java-Maskottchen da richtig (nein, dass habe ich nicht im Prompt so angefordert).

Gegenüber Java ist das gesamte Rust-Ökosystem noch recht jung. Das hat Nachteile (weniger Frameworks, weniger Erfahrung in der Entwicklercommunity), aber auch Vorteile: Rust konnte aus vielen "Fehlern" lernen, die bei der Entwicklung von Java und anderen Sprachen in den letzten Jahrzehnten gemacht wurden. Für mich ist klar, dass ich mich weiter mit Rust beschäftigen werde: Auf der einen Seite für Services, die in der Cloud auf kleinen Servern skalierbar laufen sollen, auf der anderen Seite für Spielprojekte auf Microcontrollern.  


Rust ist schneller als Java. Wirklich? Ein Benchmark liefert Messergebnisse, Hintergrundinfos zu ahead of time compiler versus JIT und Ressourcenverbrauch.

Java vs. RUST: Ein Performancevergleich

Senior IT-Consultant und Developer

### Einleitung

In diesem Artikel geht es um das Aufsetzen eines Datenprojekts mit Databricks Asset Bundles. Wir schauen uns
das Basis Setup an und eine typische Projektstruktur, gehen anschließend auf einige wichtige Details und mögliche
Stolpersteine und zeigen wie eine CI/CD-Integration mit GitLab funktionieren könnte.

#### Was ist Databricks?

Databricks wurde 2013 von den Originalentwicklern von Apache Spark gegründet und hat sich seither zu einer führenden
Data-Plattform für die moderne Datenverarbeitung entwickelt. Die Plattform vereint Funktionen zum Speichern,
Verarbeiten, Abfragen und Visualisieren von Daten und unterstützt dabei das Konzept des Lakehouse – einer Architektur,
die die Vorteile von Data Warehouses und Data Lakes kombiniert.

Databricks richtet sich an verschiedene Nutzergruppen: Data Engineers, Data Scientists, Data Analysts sowie
Business-Anwender ohne tiefere technische Kenntnisse können unter einer einheitlichen Oberfläche zusammenarbeiten. Dafür
stehen unter anderem interaktive Notebooks mit Multi-Language-Unterstützung (z. B. Python, SQL, Scala), ein
leistungsstarker SQL-Editor, Dashboards, Workflows für Data Pipelines sowie integrierte Machine-Learning-Tools wie
MLflow zur Verfügung.

Die Plattform ist als vollständig verwaltete PaaS-Lösung in allen großen Public Clouds verfügbar – Azure, AWS und Google
Cloud – und erlaubt so eine nahtlose Integration in bestehende Cloud-Umgebungen.

Im weiteren Verlauf liegt der Fokus auf dem Bereich Data Engineering und CI/CD mit Databricks: Ich zeige anhand eines
typischen Projektaufbaus,
wie man mit Databricks Asset Bundles eine Datenpipeline erstellt und diese in einen CI/CD-Workflow integriert.

#### Was sind Databricks Asset Bundles?

Ein Databricks Bundle ist eine Sammlung von Coderessourcen und Metadaten, die als ein einziges Bundle in einem
Databricks Workspace ausgerollt werden können.
Ein Bundle wird lokal entwickelt und kann anschließend in ein
Repository eingecheckt werden (wir verwenden GitLab).
Alternativ kann man direkt per CLI ausrollen.
Grob beinhaltet ein
Bundle folgende Ressourcen:

- Databricks Workspace- und Projektkonfiguration
- Python-Code (z.B. Notebooks oder Module für ETL-Pipelines)
- Definitionen und Einstellungen für Databricks Ressourcen, wie Job-Definitionen für Serverless Jobs
- Unit-Tests and Integration-Tests

Da Businesslogik nicht im Fokus steht werden wir ein minimales Bundle Setup verwenden, das eines der von Databricks
bereitgestellten `samples`-Datensätze (`nyctaxi`) einbezieht.

### Wie sieht ein typischer Projektaufbau mit Databricks aus?

Im Folgenden wird davon ausgegangen, dass ein gültiger Cloud-Account und ein Databricks Workspace bereits existieren.

#### Basis-Setup für Python-Projekt:

- Pyenv zu Verwaltung und lokaler Installation verschiedener Python Versionen
- Poetry zur Erstellung von virtuellen Python-Umgebungen
- Ruff als Tool zu Linting &amp; Codeanalyse (Diese Tools erhöhen die Qualität und Wartbarkeit von Python-Pipelines)
- Typer zur Erstellung von Kommandozeilenanwendungen (Typer CLI). Das ist optional, wie ich weiter unten ausführe.

Als Erstes installieren wir eine Python Version in unserem Projektverzeichnis:

```
pyenv local 3.11.10
```

*Hinweis:* hier sollte die gleiche Python Version verwendet werden wie im Databricks Workspace. Letztere kann man leicht
herausfinden, wenn man in einem Notebook den Befehl: `!python --version` ausführt.
Der Befehl erstellt eine `.python-version` Datei, die man normalerweise nicht ins Repository eincheckt. Alternativ kann
man natürlich eine systemübergreifende Python Version installieren.
Als Nächstes erstellen wir eine virtuelle Umgebung, die wir auf unser Projektverzeichnis beschränken:

```
poetry config virtualenvs.in-project true
```

#### Databricks Bundle Setup:

Unsere Ziel-Projektstruktur sieht in etwa so aus:

```
databricks_bundle_example/
├── .databricks/ # Bundle-spezifische Konfigurationen und Artefakte pro Umgebung
│
├── .venv/ # Virtuelle Umgebung (optional, lokal)
│
├── src/ # Der eigentliche Code (z.B. ETL-Logik, Helper-Module)
│
├── resources/ # Job-Definitionen für Pipelines
│ └── databricks_bundle_demo.job.yml # Beispielhafte Job-Definition im YAML-Format
│
├── tests/ # Pytest-basierte Unit- oder Integrationstests
│
├── databricks.yml # Hauptdefinition des Databricks Bundles
├── .gitlab-ci.yml # CI/CD-Konfiguration für GitLab
└── pyproject.toml # Zentrale Konfigurationsdatei für das Python-Projekt
```

Ich möchte nicht auf jede einzelne Datei eingehen, nur einige wichtige Anmerkungen:

`databricks.yml`:

| **Feld**    | **Bedeutung**                                                                                                                                                                                                                                                                                          |
|-------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `variables` | Können in verschiedenen Stages verwendet werden, um Stage-spzifische Werte zu übergeben                                                                                                                                                                                                                |
| `sync`      | Steuert, welche lokalen Dateien beim Deployment ins Databricks-Dateisystem (meist `/Workspace/...`) hochgeladen werden. Die `exclude`-Einträge **überschreiben** `include`-Einträge, d. h. Dateien in `exclude` werden **nicht synchronisiert**, selbst wenn sie in `include` stehen.                  |
| `targets`   | Definiert verschiedene Deployment-Umgebungen wie `dev_local`, `dev`, `prod`. Ermöglicht isolierte Entwicklungsumgebungen sowie zentralisierte Produktionsdeployments. Jede Umgebung kann eigene Parameter (z. B. Kataloge, Cluster-Modi) enthalten.                                                    |
| `root_path` | Gibt den genauen Pfad im Databricks Workspace an, in dem die Bundle-Inhalte abgelegt werden. Das ist wichtig zur Trennung von Umgebungen und Nutzern und verhindert Ressourcenkollisionen. Wird `root_path` nicht definiert, kann die Pipeline scheitern, weil nötige Artefakte nicht gefunden werden. |
| `host`      | Workspace URL, hat die Form: `https://.azuredatabricks.net`                                                                                                                                                                                                                              |

Hier ist ein beispielhafter Aufbau einer `databricks.yml`:

```
bundle:
  name: databricks_bundle_demo
  uuid: 57dddb64-fdcd-45bd-b00c-70de62f98c72

variables:
  schema_prefix:
    description: Prefix for local development schema
    default: ""
  catalogue:
    description: Catalogue to store schema and tables
  branch_ref:
    description: Branch reference name used for naming test deployments
    default: ""
  schedule_pause_status:
    description: Status of schedule triggers 'UNPAUSED' = enabled, 'PAUSED' = disabled
    default: "UNPAUSED"
sync:
  include:
    - src/**/*.py 

  exclude:
    - "test/*"
    - "resources/*"
    - ".*"
    - "*.lock"
    - "*.md"
    - "*.toml"
    - "databricks.yml"

include:
  - resources/*.yml

permissions:
  - group_name: users
    level: CAN_VIEW
  - user_name: "${workspace.current_user.userName}"
    level: CAN_MANAGE

targets:
  dev_local:
    mode: development
    default: true
    artifacts:
      wheel:
        type: whl
        files:
          - source: ./dist/*.whl
    variables:
      catalogue: "demo_dev_local"
      schema_prefix: "${workspace.current_user.short_name}_"
      schedule_pause_status: "PAUSED"
    workspace:
      host: https://adb-185960349365378.18.azuredatabricks.net
  dev:
    mode: development
    default: false
    variables:
      catalogue: "demo_dev"
      schema_prefix: "${workspace.current_user.short_name}_"
      schedule_pause_status: "PAUSED"
    workspace:
      host: https://adb-185960349365378.18.azuredatabricks.net
      root_path: /Shared/.bundle/${bundle.name}/dev/${workspace.current_user.short_name}/

  prod:
    mode: production
    workspace:
      host: https://adb-185960349365378.18.azuredatabricks.net
      root_path: /Workspace/Users/${workspace.current_user.name}/.bundle/${bundle.name}/${bundle.target}
    permissions:
      - user_name: ${workspace.current_user.name}
        level: CAN_MANAGE
```

`databricks_bundle_demo.job.yml`:

| Feld              | Bedeutung                                                                                                                                                  |
|-------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `environments`    | Definiert, mit welchen Libraries/Settings ein Task ausgeführt wird. Wir nutzen Serverless                                                                  |
| `./../dist/*.whl` | Zeigt auf das gebaute Python-Wheel mit deinem Code. Wichtig für Python-Wheel-Jobs.                                                                         |
| `entry_point`     | Name des Python-Moduls bzw. Scripts im Paket, das gestartet werden soll.                                                                                   |
| `pause_status`    | `"UNPAUSED"` bedeutet, dass der Schedule aktiv ist. In `dev` meist `"PAUSED"`.                                                                             |
| `tasks`           | Hier werden einzelne Job-Schritte, benötigte Variablen und Abhängigkeiten definiert. Im Databricks Portal kann das als Prozessdiagramm visualisiert werden |

Hier ist ein Beispiel für eine `databricks_bundle_demo.job.yml`:

```
resources:
  jobs:
    databricks_bundle_demo_job:
      name: databricks_bundle_demo_job
      max_concurrent_runs: 1
      schedule:
        timezone_id: "UTC"
        quartz_cron_expression: "0 15 0 ? * *"
        pause_status: "UNPAUSED"
      environments:
        - environment_key: Serverless
          spec:
            client: "2"
            dependencies:
              - ./../dist/*.whl

      tasks:
        - task_key: task_get_taxis
          python_wheel_task:
            package_name: databricks_bundle_example
            entry_point: demo_script
          environment_key: Serverless
```

`main.py`:

Ich möchte nicht näher auf den Inhalt des Codes eingehen, sondern nur ein Beispiel geben:

```
from loguru import logger
from pyspark.sql import SparkSession, DataFrame

def task_get_taxis():
    """
    Request taxis from databricks example data sample.
    """
    logger.info("running task_retrieve_roads_raw_data")

    get_taxis(get_spark()).show(5)

    logger.info("loaded roads data successful!")


def get_taxis(spark: SparkSession) -&gt; DataFrame:
    return spark.read.table("samples.nyctaxi.trips")

def get_spark() -&gt; SparkSession:
    try:
        from databricks.connect import DatabricksSession

        return DatabricksSession.builder.getOrCreate()
    except ImportError:
        return SparkSession.builder.getOrCreate()
```

In diesem Beispiel werden keine Parameter in der Funktion übergeben, weshalb es nicht notwendig ist, diese als
CLI-Befehl zu kennzeichen.
Anders sieht es aus, wenn man Parameter übergeben möchte, wie das folgende Beispiel zeigt:

```
import typer
from loguru import logger
from pyspark.sql import SparkSession, DataFrame

cli = typer.Typer()

def main():
    cli(standalone_mode=False)

@cli.command()
def task_get_taxis(schema_path: str = typer.Option(...)):
    """
    Request taxis from databricks example data sample.
    """
    logger.info("running task_get_taxis")

    taxies_data = get_taxis(get_spark())

    logger.info("loaded taxies data successful!")
    
    write_taxies_data(taxies_data, schema_path)
   
...
```

Für dieses Beispiel würde der entsprechende Task-Abschnitt in der Job-Definition so aussehen:

```
...
      tasks:
        - task_key: task_get_taxis
          python_wheel_task:
            package_name: databricks_bundle_example
            entry_point: demo_script
            parameters: [ "task-get-taxis", "--schema-path", "${var.catalogue}.${var.schema_prefix}" ]
          environment_key: Serverless
...
```

Die Annotation `@cli.command()` ist wichtig. Databricks ruft das Script über CLI auf, d.h.
wenn man in der Task-Definition Parameter einträgt, dann sind das CLI Parameter und keine Python Parameter. Deswegen
muss man im Python-Code die Aufrufargumente parsen. `Typer-CLI` macht an dieser Stelle eine CLI-Applikation aus unserem
Code, sodass dieser mit den übergebenen Parametern in der Pipeline laufen kann.

`pyproject.toml`:

Das ist die zentrale Konfigurationsdatei für unser Projekt und wird bei einem Poetry-Setup vorausgesetzt. Hier ist ein
Beispiel, wie die Datei in unserem Projektkontext aussehen könnte:

```
[tool.poetry]
name = "databricks_bundle_example"
version = "0.1.0"
packages = [{ include = "src" }]
authors = ["denis.khaskin@codecentric.de"]
[tool.poetry.scripts]
demo_script = 'src.databricks_bundle_demo.main:main'

[tool.poetry.dependencies]
python = "^3.11"
loguru = "^0.7.2"
databricks-connect = "15.4.2"

[tool.poetry.group.dev.dependencies]
pre-commit = "^3.6.2"
freezegun = "1.5.1"
ruff = "^0.3.7"

[tool.ruff]
line-length = 120
exclude = ["*.ipynb"]

[tool.ruff.format]
quote-style = "single"
indent-style = "space"
docstring-code-format = false

[tool.ruff.lint]
unfixable = ["F401"] # E.g. disable fix for unused imports (`F401`).

[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"
```

Der Eintrag `demo_script` korrespondiert zu dem Eintrag `entry_point` in dem entsprechenden Task in der Jobdefinition,
sodass der auszuführende Code zur Laufzeit gefunden wird.

### Wie richte ich eine GitLab CI/CD-Pipeline für Databricks ein?

Bevor wir eine Pipeline in GitLab aufsetzen ist es wichtig eine Authentifizierung Methode festzulegen, mit der sich die
Pipeline gegenüber Databricks authentifizieren soll, um den Code auszurollen und den Job zu starten.
Wir verwenden dazu OAuth2-konform ein Service Principal, der für automatisierte Deployments mit GitLab CI/CD genutzt
wird.
Wichtig ist, dass dieses direkt im Databricks Portal und nicht im Portal des jeweiligen Cloud-Anbieters erstellt wird.
Dazu wechselt man in Databricks zu den Einstellungen (rechts oben auf den Nutzer klicken).
Dann navigiert man zu "Identity and access-Service principals-Manage".
Dort kann man ein neues Service principal erstellen.
Ist es erstellt, wechselt man zu "Secrets" und erstellt ein neues secret.
Die erzeugten `Secret`-Daten sollte man sich sofort speichern, sie werden später nicht mehr angezeigt.
Anschließend müssen die erzeugten `Secret`-Daten in GitLab (oder einem anderen Anbieter der Wahl) als Variablen
hinterlegt werden.
Folgend ein Beispiel wie es in GitLab aussehen könnte:

| **Key**                              | **Value** | **Masked** | **Expanded** | **Environments** |
|--------------------------------------|-----------|------------|--------------|------------------|
| `DATABRICKS_CLIENT_ID`               | *****     | Nein       | Ja           | All (default)    |
| `DATABRICKS_CLIENT_SECRET`           | *****     | Ja         | Ja           | All (default)    |
| `DATABRICKS_HOST`                    | *****     | Nein       | Ja           | All (default)    |
| `DATABRICKS_SERVERLESS_WAREHOUSE_ID` | *****     | Nein       | Ja           | All (default)    |

Die ersten beiden Variablen stammen direkt aus dem erzeugten `secret`. Databricks Host kann bei dem jeweiligen
Cloud-Anbieter oder direkt in der URL des Portals eingesehen werden. Für die Warehouse-ID navigiert man im Portal zu
SQL-warehouses, klickt auf das genutzte (sofern bereits erstellt, sonst ein neues erstellen), die ID steht direkt hinter
dem Namen.

Sind die Variablen gesetzt können wir die CI/CD-Pipeline aufbauen. Nachfolgend das Beispiel einer `.gitlab-ci.yml` (ich
gehe bewusst nicht auf alle Details ein, sondern setze hier ein Grundwissen voraus):

```
image: gitlab.codecentric.de:4567/data_ml_ai/databricks_pipeline_build_image:latest

stages:
  - check
  - unittest
  - build
  - deploy_dev
  - deploy_prod

python-lint-and-format:
  stage: check
  before_script:
    - poetry install
  script:
    - poetry run pre-commit run --all-files
  rules:
    - if: '$CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH &amp;&amp; $CI_PIPELINE_SOURCE == "merge_request_event"'

validate-bundle:
  stage: check
  script:
    - databricks bundle validate
  rules:
    - if: '$CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH &amp;&amp; $CI_PIPELINE_SOURCE == "merge_request_event"'

unit-tests:
  stage: unittest
  before_script:
    - poetry install
  script:
    - poetry run pytest --capture=no .
  rules:
    - if: '$CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH &amp;&amp; $CI_PIPELINE_SOURCE == "merge_request_event"'

build:
  stage: build
  before_script:
    - poetry install
  script:
    - poetry build
  artifacts:
    paths:
      - dist
  rules:
    - if: '$CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH &amp;&amp; $CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH &amp;&amp; $CI_PIPELINE_SOURCE == "push"'

debug-auth:
  stage: check
  script:
    - echo $DATABRICKS_HOST
    - echo $DATABRICKS_CLIENT_ID
    - echo ${#DATABRICKS_CLIENT_SECRET} # nur Länge anzeigen
    - echo $DATABRICKS_TENANT_ID
  rules:
    - when: always

rollout-dev:
  stage: deploy_dev
  environment:
    name: dev
  script:
    - databricks version
    - databricks auth describe
    - databricks bundle deploy --target dev --var="branch_ref=$CI_COMMIT_REF_SLUG" --force --auto-approve

  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH &amp;&amp; $CI_PIPELINE_SOURCE == "push"'

run-dev:
  stage: deploy_dev
  needs:
    - rollout-dev
  environment:
    name: dev
  script:
    - databricks bundle run databricks_bundle_demo_job --target dev --var="branch_ref=$CI_COMMIT_REF_SLUG"
  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH &amp;&amp; $CI_PIPELINE_SOURCE == "push"'

deploy-prod:
  stage: deploy_prod
  environment:
    name: prod
  script:
    - databricks bundle deploy --target prod
  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH &amp;&amp; $CI_PIPELINE_SOURCE == "push"'
```

Man beachte, dass hier ein selbst gebautes Docker image verwendet wird, in dem Databricks-CLI und andere Abhängigkeiten
bereits installiert sind.
Man erkennt, dass die Pipeline nicht nur das Projekt baut, sondern auch im Databricks Workspace ausrollt und den Job
startet. Dazu
ist das erstellte Service Principal notwendig.
Nach einem erfolgreichen Lauf sollte man im Portal unter "Workflows" den entsprechenden Eintrag mit dem Tag
`gitlab_deployment` (oder je nachdem was man verwendet) sehen können. Geht man weiter in die Jobdetails können einzelne
Tasks und ihre Ergebnisse eingesehen werden.

### Fazit

An dem hier vorgestellten Aufbau sieht man, dass es relativ einfach ist, ein Datenprojekt mit Databricks aufzusetzen.
In Kombination mit den Portalwerkzeugen wie Notebooks oder SQL-Editor ist es sehr einfach eine Funktionalität zu
entwickeln: Man kann nahezu alles ausprobieren, bevor man es ins Repository eincheckt. Auf der anderen Seite bieten
Databricks Asset Bundles die Möglichkeit, Code unter modernen Softwarearchitektur-Prinzipien zu entwickeln – mit klarer
Trennung von Umgebungen, CI/CD-Automatisierung und reproduzierbaren Serverless Workflows.

Data Engineering Projekt mit Databricks Asset Bundles und GitLab CI/CD aufsetzen – inklusive Projektstruktur und Beispielcode.

Databricks Asset Bundle Projekt aufsetzen und ausrollen

Erstes Data Engineering Projekt mit Databricks Asset Bundles und GitLab CI/CD

IT-Security Consultant

Docker hat sich als leistungsstarkes Werkzeug etabliert, das Entwicklern hilft, Anwendungen effizient zu containerisieren und zu skalieren. Doch wie bei jeder Technologie gibt es Aspekte, die es ermöglichen, versehentlich Sicherheitslücken zu erzeugen. Einer dieser Aspekte beim Umgang mit Docker-Images ist die Art und Weise, wie Dateien gelöscht werden. In diesem Blogpost wird erklärt, warum das Löschen von Dateien in Docker-Images problematisch sein kann und wie diese Lücke vermieden werden kann.

## Docker Schichtensystem: Ein kurzer Überblick

Docker-Images bestehen aus mehreren [Schichten](https://docs.docker.com/get-started/docker-concepts/building-images/understanding-image-layers/), die nacheinander aufgebaut werden. Jede Schicht repräsentiert einen schreibgeschützten Schnappschuss des Dateisystems. Änderungen oder Ergänzungen des Dateisystems erzeugen einen neuen Schnappschuss, aufbauend auf den vorherigen Schichten. 

Für dieses beispielhafte Dockerfile werden drei Schichten erzeugt.

```docker
FROM alpine
RUN apk update && apk add python3
COPY src/ /app/
```

*![Schichten des Dockerfiles](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmbqh4dfwezp607usw8lrm12o)Schichten des Dockerfiles*

 

## Das Problem beim Löschen von Dateien

Angenommen in dem Dockerfile wird eine Datei hinzugefügt, die ein Secret enthält. Später wird diese Datei wieder durch den `rm` Befehl gelöscht, da sie nicht im finalen Image enthalten sein soll. Insgesamt werden für das folgende Dockerfile fünf Schichten erzeugt. Obwohl die Datei in der neuesten Schicht als gelöscht markiert wird, bleibt sie in den vorherigen Schichten vorhanden.

```docker
FROM alpine
RUN apk update && apk add python3
COPY buildconfig.json /buildconfig.json
COPY src/ /app/
# Do something with the build config
RUN rm /buildconfig.json
```

*![Schichten nach dem Löschen einer Datei](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmbqh68ddevpg07ukslbw1my4)Schichten nach dem Löschen einer Datei*

## Ein Beispiel zur Veranschaulichung

Nachdem das Image aus dem obigen Dockerfile gebaut wurde, kann es als tar Archiv gespeichert werden.

```bash
docker save -o exampleimage.tar exampleimage
```

In diesem Archiv befindet sich das Image Manifest `manifest.json`, in dem die Binär Blobs der Schichten aufgelistet werden. Die Binär Blobs sind ebenfalls tar Archive, welche die Änderung der  jeweiligen Schicht beinhaltet.

```bash
"Layers": [
  "blobs/sha256/63ca1fbb43ae5034640e5e6cb3e083e05c290072c5366fcaa9d62435a4cced85",
  "blobs/sha256/01ab1ebbd41659e8b36216acb45a5108a1bb4d42eaae40c6cfb82e4d532e8558",
  "blobs/sha256/35496380094a9854f97ff02beddde9ca0ec9ea1cac47b4a659d5595102dfeb48",
  "blobs/sha256/8d8d469b0e64e18c2ec91f4e0d62684a950fe21ce39e179950392ca29e5544ad",
  "blobs/sha256/f6b4e08453d8488c6fbb8062fb291c9dfeef9b979101e9edcbb5c1cd3fb6df30"
], 
```

Wenn die Dateien, der letzten Schicht gelistet werden, sieht man die als gelöscht markierte buildconfig.json Datei. Der Prefix `.wh.` dient dabei als Marker dafür, dass diese Datei gelöscht wurde.

```bash
tar --list -f blobs/sha256/f6b4e08453d8488c6fbb8062fb291c9dfeef9b979101e9edcbb5c1cd3fb6df30
.wh.buildconfig.json
```

Wird die dritte Schicht gelistet, findet man die buildconfig.json Datei. Somit hat jeder, der Zugriff zu diesem Docker Image hat, auch Zugriff auf die Konfigurationsdatei und kann somit das Secret auslesen und missbrauchen.

```bash
tar --list -f blobs/sha256/35496380094a9854f97ff02beddde9ca0ec9ea1cac47b4a659d5595102dfeb48
buildconfig.json
```

## Best Practices zur Vermeidung dieser Lücke

Eine gängige Methode, um diese Lücke zu vermeiden, sind [Multi-Stage Builds](https://docs.docker.com/build/building/multi-stage/). Dadurch existieren die sensiblen Dateien nur in dem temporären Image, werden aber nicht in dem endgültigen Image inkludiert. 

```docker
FROM alpine AS intermediate
RUN apk update && apk add python3
COPY buildconfig.json /buildconfig.json
COPY src/ /app/
# Do something with the build config
RUN rm /buildconfig.json

FROM alpine
COPY --from=intermediate /app/ /
```

Außerdem sollte sorgfältig geplant werden, welche Dateien im endgültigen Image enthalten sein sollen und sichergestellt werden, dass sensible Dateien nicht aus Versehen mit eingebaut werden.

## Fazit

Durch das Verständnis der Arbeitsweise von Docker-Image Schichten und die Anwendung der richtigen Strategie kann sichergestellt werden, dass sensible Daten wirklich aus Docker-Images entfernt werden. Docker ist ein mächtiges Werkzeug, aber wie jede Technologie erfordert es sorgfältige Handhabung, um sicherzustellen, dass die Anwendungen sicher und effizient laufen.

Dateien sicher löschen in Dockerfiles und unbeabsichtigte leaks vermeiden.

Dateien sicher löschen in Dockerfiles

Principal IT-Security Consultant

Noch schnell patchen, bevor die Sommerpause kommt.\nWas ist der Patch Tuesday?\nDer Begriff bezeichnet den zweiten Dienstag im Monat, an dem Microsoft wichtige Patches für seine Systeme veröffentlicht. Durch den festen Rhythmus wird die Arbeit von Systemadministratoren und Nutzern erleichtert, da somit ein klarer Planungszeitpunkt zum Einspielen von Updates gegeben ist.\nDer Patch Tuesday bringt im Juni 2025 unter anderem wichtige Sicherheitsupdates von Microsoft und schließt damit mehrere Sicherheitslücken.\nSo wurden bei Microsoft fast 80 Sicherheitslücken geschlossen. Zu diesen zählen 13 Schwachstellen zur Erweiterung von Privilegien und 25 Optionen der sog. “Remote Code Execution” in mehreren Produkten wie Office oder SharePoint. Zwei geschlossene Schwachstellen (\nCVE-2025-33053\n, \nCVE-2025-33073\n) werden bereits aktiv von Angreifern ausgenutzt.\nAuch in Google Chrome, wurde in den letzten Tagen eine neue Version veröffentlicht, die die bereits von Angreifern ausgenutzte Sicherheitslücke \nCVE-2025-5419\n schließt.\nWeitere Hersteller, die Sicherheitsupdates herausgebracht haben, sind nachfolgend aufgelistet:\n\nCisco\n: Sicherheitsupdates für mehrere Produkte mit Schwachstellen, darunter eine “Remote Code Execution” und die Möglichkeit, Zugangsdaten aus Cisco ISE Cloud-Installationen zu extrahieren.\n\nIvanti\n: Sicherheitsupdates für mehrere Produkte.\n\nFortinet\n: Sicherheitsupdates für mehrere Produkte, einschließlich einem Fix für einen “Authentication Bypass”, sowie für eine “OS Command Injection”-Schwachstelle\n\nSAP\n: Behebung von 14 Schwachstellen, darunter eine kritische Lücke zur Erweiterung der Privilegien.

Zusammenfassung der geschlossenen Sicherheitslücken im Juni 2025.

Patch Tuesday Juni 2025

Was ist Resilienz? Grundlagen für IT-Systeme. Part 3.

Der lange und steinige Weg zur Resilienz – Teil 3

IT Consultant

Neben den dominierenden US-Anbietern wie AWS, Azure und GCP bietet das französische Unternehmen Scaleway jetzt auch ein umfangreiches Serverless-Computing-Angebot.
Dieses umfasst unter anderem Services für Function as a Service, einen leichtgewichtigen Key/Value Store und einen einfachen Messaging-Dienst und bietet somit die Basisfunktionen für Cloud-natives Serverless-Computing.
Um dieses Angebot auf den Prüfstand zu stellen, habe ich eine Beispielanwendung zu Scaleway migriert und möchte meine Erfahrungen in diesem Beitrag mit euch teilen.

# Anwendungsfall und Testumgebung

Die Anwendung besteht aus einer Single Page Application, einem Backend mit mehreren Serverless-Functions für API-Aufrufe und Authentifizierung per OAuth und einer Key/Value-Datenbank zur Nutzerverwaltung.
Ursprünglich habe ich die Implementierung auf AWS aufgebaut, wo mir zahlreiche Managed Services zur Verfügung standen.
Dafür habe ich mir ein Äquivalent bei Scaleway angesehen.
Auch bei Scaleway konnte ich die Anwendung mit wenigen Einschränkungen implementieren.
Die Repositories für beide Implementierungen finden sich auf GitHub.
[GitHub Repository der AWS-Implementierung](https://github.com/florianluediger/playlist-cutter-full-stack)
[GitHub Repository der Scaleway-Implementierung](https://github.com/florianluediger/playlist-cutter-full-stack-scaleway)

| Feature                            | AWS Service            | Scaleway Service                       |
|------------------------------------|------------------------|----------------------------------------|
| Hosten der Single Page Application | AWS S3                 | Scaleway Object Storage                |
| Verwalten der Subdomains           | AWS Route53            | Scaleway Domains and DNS               |
| Ausliefern der Website mit SSL/TLS | AWS CloudFront         | Teilweise vom Object Storage abgedeckt |
| Erstellen von SSL Zertifikaten     | AWS CertificateManager | -                                      |
| Serverless Functions Backend       | AWS Lambda             | Scaleway Serverless Functions          |
| Konsolidierung von Functions       | AWS ApiGateway         | -                                      |
| Verwaltung externer Secrets        | AWS ParameterStore     | Scaleway Secret Manager                |
| Session-Verwaltung für Anwender    | AWS DynamoDB           | Managed Database for Redis             |

# Positive Erfahrungen

Grundsätzlich hat mir der Umgang mit Scaleway sehr gut gefallen.
Das UI ist sehr aufgeräumt und intuitiv, besonders wenn man die überladene Oberfläche der AWS-Konsole gewöhnt ist.
Dadurch konnte ich mir schon bei der Bedienung der Website einen guten Überblick über den Funktionsumfang der Services verschaffen.
Meine Anwendung habe ich mit Infrastructure as Code und dem [Scaleway Terraform-Provider](https://registry.terraform.io/providers/scaleway/scaleway/latest/docs) erstellt.
Dieser hat für mich gut funktioniert und meiner Erfahrung nach auch verständliche Fehlermeldungen ausgegeben, wenn mal etwas schiefgelaufen ist.

Meiner Meinung nach setzt Scaleway an vielen Stellen sinnvollerweise auf Open Source Software und spart sich somit viel Arbeit zur Implementierung einer eigenen Lösung.
Beispielsweise werden Logs und Metriken in einer Grafana-Instanz dargestellt, die komplett transparent in das System integriert ist, wodurch Logs automatisch erfasst werden und dann durch einen Klick direkt in der Konsole abgerufen werden können.
Dadurch fühlt sich zwar nicht alles wie aus einem Guss an wie bei den anderen Anbietern, es erlaubt Scaleway aber, sich um andere spannende Features zu kümmern.

Eines dieser Features ist die Möglichkeit, Serverless-Funktionen zu deployen, was ich auch für meinen Anwendungsfall ausgiebig getestet habe.
Außerdem gibt es noch die Möglichkeit, Serverless-Container zu deployen und die Kommunikation zwischen Services durch Queues und Topics zu gestalten.
Die Verwaltung von Berechtigungen zwischen diesen Services wird über ein simples IAM-System möglich.
Für mich sind das genau die Features, die ich von einem konkurrenzfähigen Cloud-Anbieter erwarte, um Cloud-native Anwendungen bauen zu können.

# Herausforderungen und Hindernisse

Bei der Implementierung meiner Beispielanwendung bin ich an einigen Stellen auf Herausforderungen gestoßen.
Dies lag hauptsächlich daran, dass meine ursprüngliche Implementierung auf AWS zugeschnitten war und Scaleway nicht alle Features anbot, die ich dafür verwendet habe.
Ich möchte hier ein paar Beispiele für Features geben, auf die man aktuell verzichten müsste, wenn man sich für Scaleway entscheidet.

In meiner AWS-Implementierung konnte ich mein Serverless-Backend in mehrere Funktionen aufteilen, die ich mit einem ApiGateway konsolidiert und mit Pfad-basiertem Routing unter einer URL verfügbar gemacht habe.
Mit Scaleway ist das nicht möglich, da es kein Äquivalent zum ApiGateway gibt und jede Funktion eine eigene URL bekommt.
Da mein Backend sehr überschaubar ist, habe ich den gesamten Code [in einer Funktion](https://github.com/florianluediger/playlist-cutter-full-stack-scaleway/blob/main/backend/src/backend-handler.ts) zusammengefasst und dann innerhalb der Funktion die Zugriffspfade ausgewertet.
Für größere Anwendungen ist dies aber nicht mehr praktikabel, weshalb man beispielsweise selbst einen Service hosten muss, der das Routing übernimmt.
Scaleway empfiehlt dazu eine [Lösung, die auf dem Kong Gateway basiert](https://github.com/scaleway/serverless-gateway).

Auch das Berechtigungssystem für die Kommunikation zwischen Services ist an einigen Stellen noch nicht ganz ausgereift.
So musste ich für den Zugriff auf den Secrets Manager zuerst im IAM Service einen API-Key anlegen, der über eine Policy die Berechtigung für den Secrets Manager erhält.
Diesen API-Key habe ich dann [per Umgebungsvariable an meine Serverless-Funktion übergeben](https://github.com/florianluediger/playlist-cutter-full-stack-scaleway/blob/45755d4513d3e70099f2aecd3e4c25d1af459e24/main.tf#L133), die diesen Wert auslesen und für den direkten Zugriff auf das Secret verwenden muss.
Bei AWS dagegen kann ich einfach der [Execution Role einer Lambda-Funktion über eine Policy](https://github.com/florianluediger/playlist-cutter-full-stack/blob/a25e91da5befcd44867033436619fc9393012be4/backend/src/auth/auth.ts#L55) den Zugriff auf ein bestimmtes Secret zuweisen.
Dadurch entfällt das manuelle Key-Management, wodurch auch kein Key verloren oder in falsche Hände geraten kann.

Als Alternative zu AWS CloudFront bietet Scaleway ein Feature namens Edge Services, mit dem öffentliche Endpunkte für Buckets und Load Balancers mit Caching und SSL/TLS versehen werden können.
Die Bedienung des Services über die Oberfläche funktioniert zwar gut, allerdings hat das Erstellen von Ressourcen via Terraform bei mir für einen Absturz gesorgt.
Dabei war das komplette Feature in der Web-Konsole nicht mehr nutzbar, bis ich die entsprechenden Ressourcen mit Terraform wieder entfernt habe.
Die Scaleway Edge Services werden aktuell noch als neues Feature beworben, weshalb diese Fehler vermutlich bald behoben sein werden.

Generell hatte ich das Gefühl, dass aktuell sehr viel an neuen Funktionen und Services gearbeitet wird und sich vieles im Umbau befindet.
Auch bei dem relativ neuen Angebot für Serverless Functions bin ich auf ein Hindernis gestoßen, als ich die Dokumentation durchsucht habe.
In der [Referenz-Dokumentation](https://www.scaleway.com/en/docs/serverless-functions/reference-content/functions-handlers/) zum Code der Handler-Funktionen steht leider aktuell beispielsweise nicht, wie die an die Funktion übergebenen `event` und `context` Objekte genau aussehen und welche Attribute diese besitzen.
Diese Informationen muss man sich also aus Beispielen im Internet zusammensuchen.

# Fazit

Insgesamt hat mir das Arbeiten mit Scaleway sehr gut gefallen und besonders durch die intuitiv gestaltete Oberfläche der Web-Konsole Spaß gemacht.
Vor allem für Entwickler, die noch nicht viel Erfahrung mit Cloud-Technologien haben, bietet der etwas reduzierte Funktionsumfang und die aufgeräumte Bedienung einen einfachen Einstieg.
Einige Anwendungsfälle erfordern zwar etwas mehr Aufwand, als dies bei den großen Hyperscalern der Fall wäre, es gibt aber für die meisten Probleme auch eine Lösung.
Die Basis-Services, die für eine Serverless-Architektur benötigt werden, sind vorhanden und es gibt sogar einige spezialisierte Angebote für IoT- oder Machine-Learning-Anwendungen.
Mich persönlich hat am meisten das Berechtigungskonzept gestört, da ich durch die Benutzung von AWS sehr daran gewöhnt bin, sämtliche Berechtigungen durch Roles und Policies zu verwalten und mich nicht um Secrets kümmern zu müssen.
Für Kunden, die auf europäische Lösungen setzen wollen und keine spezifischen Features benötigen, stellt Scaleway dennoch meiner Meinung nach eine sinnvolle Alternative zu den etablierten US-Unternehmen dar.


Scaleway Serverless im Praxistest: Kann die europäische Cloud-Alternative mit AWS & Co. mithalten? Meine Erfahrungen.

Serverless aus Europa: Meine Erfahrung mit Scaleway

Serverless aus Europa: Meine Erfarhrung mit Scaleway als Alternative zu AWS und Co.

IT Consultant & Developer

Lead API Consultant

*API Discovery bezeichnet die Fähigkeit, alle in einer Organisation verwendeten APIs zu identifizieren, zu katalogisieren und zu dokumentieren mit dem Ziel, sie auffindbar und nutzbar zu machen und die Governance zu stärken. Es gibt unzählige Tools, die die API Discovery unterstützen. Typischerweise heißen sie Developer Portal, Katalog oder Marktplatz. Bei dieser Fülle an unterschiedlichen Namen ist es leicht möglich, den Überblick zu verlieren. Was sollte ein API Discovery Tool überhaupt leisten? Und welcher Name ist für welche Art Tool der richtige?*

## Developer Portal

Developer Portale bieten den Zugriff auf APIs als Self-Service, ein nahtloses Onboarding, gute Dokumentation und Integrationsunterstützung. Ihre Hauptzielgruppe ist technisch, was auch durch den Namen repräsentiert wird.

Die typischen Funktionen, die ein Developer Portal unterstützt sind:
- API Dokumentation
- Interaktive API Exploration und Sandboxes
- SDKs, Beispielcode, Bruno / Postman Collections
- Authentifizierung &amp; API Key/Token Management
- Support für Entwicklungsteams

Ein gutes Developer Portal unterstützt Entwicklungsteams dabei zu verstehen, wie sie eine API verwenden. Es reduziert die für die Integration nötige Zeit, auch bereits bei der ersten Benutzung. Zusätzlich erhöht es die Adoptionsrate für APIs durch den angebotenen Self-Service.

## Katalog

Kataloge organisieren und verwalten APIs für eine bessere Auffindbarkeit und Konsistenz. Ihre Hauptzielgruppe ist meist technisch und unternehmensintern, da sie eine komplette Übersicht bieten, die für Externe oft nicht notwendig ist.

Die typischen Funktionen, die ein Katalog unterstützt sind:
- Zentralisiertes API-Inventar
- Suche, Filterung &amp; Kategorisierung
- Visualisierung von API Metadaten
- Governance und Durchsetzung von Richtlinien
- Standardisierung von API-Verträgen und Abhängigkeiten

Ein guter Katalog führt dazu, dass APIs wiederverwendet werden, weil sie einfacher zu finden sind. Damit reduziert er auch Duplikate und API-Sprawl. Er fördert Governance über die Durchsetzung von Richtlinien und Konsistenz über die Grenzen von Teams hinweg. Durch das zentralisierte API-Inventar ermöglicht ein Katalog auch die Standardisierung von API-Verträgen und Abhängigkeiten.

## Marktplatz

Marktplätze verbinden API-Anbietende mit ihren Konsumierenden und fördern dabei Monetarisierung und Partnerschaften. Ihre Zielgruppe ist vielfältiger und schließt sowohl Menschen mit Business- als auch Technik-Fokus ein. Meist werden Marktplätze unternehmensextern angeboten und zeigen nur einen ausgewählten Ausschnitt der API-Landschaft.

Die typischen Funktionen, die ein Marktplatz unterstützt sind:
- Bewertungen, Rezensionen und Community-Engagement
- Mechanismen zur Abrechnung und Umsatzbeteiligung
- Rechtliche Vereinbarungen und transparente SLAs
- Onboarding von Anbietenden und Konsumierenden
- Preismodelle für APIs

Ein guter Marktplatz erweitert die API-Verwendung über interne Teams hinaus. Er unterstützt vor allem bei der Kommerzialisierung und der Monetarisierung von APIs. Gleichzeitig muss er Entscheidungsträger*innen eine effektive Überwachung ihrer API-Nutzung ermöglichen.

## Bedürfnisse der Konsumierenden

Discovery Tools sind das Fenster zur API-Landschaft einer Organisation. Die wichtigsten Stakeholder sind die Konsumierenden der APIs, die typischerweise vier Bedürfnisse haben:
- Auffindbarkeit: Welche API ist die richtige für meinen Use Case?
- Onboarding: Wie kann ich sofort loslegen?
- Integration: Ist die API stabil, verlässlich und sicher?
- Geschäftsausrichtung: Was kostet mich die Nutzung der API?

Die vorgestellten Typen von Discovery Tools fokussieren sich auf unterschiedliche Bedürfnisse:

<style>
  .api-table {
    width: 100%;
    border-collapse: collapse;
    margin: 20px 0;
    border-radius: 8px;
    box-shadow: 0 0 20px rgba(0, 0, 0, 0.1);
    overflow: hidden;
  }
  
  .api-table thead {
    background-color: #007286;
    color: white;
  }
  
  .api-table th {
    padding: 12px 15px;
    text-align: left;
    font-weight: bold;
    text-transform: uppercase;
    font-size: 14px;
    letter-spacing: 0.5px;
  }
  
  .api-table td {
    padding: 12px 15px;
    border-bottom: 1px solid #eee;
  }
  
  .api-table tbody tr:nth-child(even) {
    background-color: #f9f9f9;
  }
  
  .api-table td:first-child {
    font-weight: bold;
    color: #333;
  }
</style>

<table class="api-table">
  <thead>
    <tr>
      <th>Bedürfnis</th>
      <th>Developer Portal</th>
      <th>Katalog</th>
      <th>Marktplatz</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Auffindbarkeit</td>
      <td>❌ Nicht der primäre Fokus</td>
      <td>✅ API Metadaten, Kategorisierung, Taxonomie</td>
      <td>✅ Kategorisierung basierend auf Preismodellen und Fit zum Ökosystem</td>
    </tr>
    <tr>
      <td>Onboarding</td>
      <td>✅ Tutorials, interaktive Dokumentation, SDKs, Sandboxes</td>
      <td>❌ Nicht die Hauptfunktion</td>
      <td>❌ Limitiert auf die Beschreibung der APIs</td>
    </tr>
    <tr>
      <td>Integration</td>
      <td>✅ Self-Service</td>
      <td>❌ Nicht die Hauptfunktion, mehr Governance</td>
      <td>❌ Vorgefertigte Integrationen, API Verträge</td>
    </tr>
    <tr>
      <td>Geschäftsausrichtung</td>
      <td>❌ Hauptsächlich auf Entwickler*innen ausgerichtet</td>
      <td>✅ Governance über den API Lebenszyklus</td>
      <td>✅ Ermöglicht Monetarisierung und Partnerschaften</td>
    </tr>
  </tbody>
</table>

## Ein Tool für API-Verantwortliche

Zusätzlich zu Developer Portalen, Katalogen und Marktplätzen entstehen auch immer mehr API Registries. Registries verwalten API-Artefakte, um Transparenz über deren Lebenszyklus zu schaffen. Ihre Hauptzielgruppe sind API-Verantwortliche.

Die typischen Funktionen, die eine Registry unterstützt sind:
- Versionierung &amp; Änderungsverfolgung
- Zentrale Speicherung von API-Definitionen
- Schema- und Abhängigkeitserkennung
- Verwaltung des Lebenszyklus

Eine gute Registry stellt die Transparenz des API-Lebenszyklus sicher. Sie verbessert die Kollaboration zwischen Teams und stellt strukturiert alle API-Artefakte zur Verfügung. Im Gegensatz dazu fokussieren sich Portale, Kataloge und Marktplätze auf den Konsum von APIs. Die Registry ist somit die zentrale und maßgebliche Datenquellen für alle Discovery Tools, die intern und extern im Einsatz sind.

![API-Zugangskanäle.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmb5brkk9ogkf06ug5276vid0)
*Die API Registry dient der zentralen Speicherung von API-Artefakten. Von ihr werden APIs in verschiedene Zugangskanäle wie Developer Portale, Kataloge und Marktplätze synchronisiert, wo sie unterschiedlichen Zielgruppen von Konsumierenden zur Verfügung stehen.*

## Fazit

Unterschiedliche API Discovery-Tools haben auch einen unterschiedlichen Fokus. Je nachdem, ob das Publikum rein technisch ist oder Business-Stakeholder mit eingeschlossen werden sollen, sollte ein anderes Tool eingesetzt werden. Dabei haben die unterschiedlichen Tool-Typen auch verschiedene Aufgaben. Während Registries und Kataloge eher den Lebenszyklus der API regeln und eine Übersicht über alle APIs bieten, fokussieren sich Developer Portale und Marktplätze auf den Konsum der APIs.

![DevPortal Quadrants - de.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmb4ntkwvbzbc07tflsqd97dv)
*Übersicht über die typische Zielgruppe (horizontale Achse) und die typische Aufgabe (vertikale Achse) verschiedener Tool-Typen für die API Discovery.*

API Discovery mit Developer Portalen, Katalogen und Marktplätzen: Das richtige Tool für API-Konsumenten finden

API Developer Portalen, Katalogen oder Marktplatz?

Ransomware kann für Unternehmen zum Stresstest werden: Daten und Systeme, mit denen man täglich arbeitet, sind nicht mehr verfügbar und werden nur gegen die Bezahlung hoher Summen wieder freigegeben. Umso schlimmer ist es, wenn die Backups ebenfalls von der Verschlüsselung betroffen sind oder gar für bestimmte Bereiche der IT-Infrastruktur gar nicht erst angefertigt wurden.\nSo kommt es immer wieder vor, dass nicht nur die Dateien auf Arbeitsplatz-Rechnern, Servern und Fileshares verschlüsselt, sondern auch die Hypervisoren wie Hyper-V oder ESX-Server übernommen werden. Dabei werden die dort vorliegenden virtuellen Festplatten (z. B. in Form von vhdx- oder vmdk-Dateien) ebenfalls verschlüsselt, sodass die Server-Systeme gar nicht erst gestartet werden können.\nDiese Dateien sind mitunter sehr groß und eine Vollverschlüsselung der virtuellen Festplatten kann sehr viel Zeit in Anspruch nehmen. Je länger die Verschlüsselung dauert, desto eher kann das Opfer diese erkennen und Gegenmaßnahmen treffen. Deshalb wird bei großen Dateien nicht immer alles, sondern nur der Dateianfang und das Dateiende verschlüsselt. Das reicht in den meisten Fällen aus, um die Datei unbrauchbar zu machen: Virtuelle Maschinen lassen sich so nicht mehr starten oder in anderen Systemen mounten. Für klassische Recovery-Strategien sieht es dann düster aus, wenn die Backups auch nicht mehr funktionieren.\nUnd genau so einen Fall hatten wir bei einem Kunden im Rahmen eines DFIR-Einsatzes!\nWir müssen an die unternehmenskritischen Daten\nUm den Betrieb wieder aufnehmen zu können, mussten zwingend unternehmenskritische Daten eines dedizierten Systems wiederhergestellt werden. Doch diese befanden sich auf einem System, was über den Zugriff der Angreifer auf den Hypervisor verschlüsselt wurde. Ein Mounten der virtuellen Festplatte war leider unmöglich, doch wir konnten nach einer kurzen Analyse erkennen, dass nicht die gesamte Festplatte, sondern nur ein Teil (Anfang und Ende) der Festplatte verschlüsselt war. Zwar ist das Dateisystem mit Informationen wie Dateinamen, Dateigrößen, oder Struktur nicht mehr nutzbar, aber mit ein bisschen Glück kann man über sogenanntes File Carving an die Rohdaten der Festplatte.\nFile Carving\nFile Carving ist eine forensische Methode zur Wiederherstellung von Dateien, bei der ein intaktes Dateisystem nicht zwingend notwendig ist. Stattdessen werden dabei die Rohdaten auf einem Speichermedium auf bekannte Dateistrukturen anhand definierter Muster - wie Header (Dateianfang) und Footer (Dateiende) - analysiert. Wenn der Anfang von einer Festplatte betroffen ist, sind meist auch die Partitionstabellen und die Dateisystem-Metadaten nicht mehr lesbar. Das führt dazu, dass Betriebssysteme oder klassische Wiederherstellungssoftware keine Informationen mehr darüber haben, welche Dateien vorhanden waren, wo sie gespeichert wurden oder wie groß diese waren. File Carving kann Fragmente von Dateien extrahieren, indem es direkt in den Rohdaten nach Dateisignaturen sucht. Beim klassischen File Carving werden die sogenannten Header und Footer gesuchter Dateitypen identifiziert. Anschließend wird manuell oder vorwiegend automatisiert eine Suche nach dem Header dieses Dateityps gestartet. Wird dieser gefunden, findet eine Prüfung statt, ob in den nachfolgenden Fragmenten der Footer des Dateityps identifiziert werden kann. Fragmente, die sich zwischen Header und Footer befinden, werden als Dateiinhalte klassifiziert und inklusive Header/Footer exportiert.\n\nDiese Methode hat allerdings auch ihre Grenzen. Insbesondere dann, wenn die gesuchten Dateien kein eindeutiges Ende haben.\nWährend viele Formate klar definierte Header und Footer verfügen, die Anfang und Ende der Datei markieren, fehlt diese Struktur bei anderen, wie z. B. bei Datenbanken, Rohdaten oder proprietären Formaten. In solchen Fällen ist es sehr schwierig bis unmöglich, exakt zu bestimmen, wo eine Datei aufhört. Das kann dazu führen, dass beim Carving entweder nur unvollständige Datenfragmente extrahiert oder dass versehentlich benachbarte Datenbereiche mitgelesen werden, die zu anderen Dateien gehören. Das Resultat sind beschädigte oder vermischte Dateien, deren inhaltliche Integrität nicht mehr gewährleistet werden kann. Die Interpretation der wiederhergestellten Inhalte erfordert dann Erfahrung im Umgang mit den spezifischen Dateiformaten, um relevante Informationen korrekt zu identifizieren und voneinander abzugrenzen.\nFile Carving lässt sich mit diversen Werkzeugen - von professionellen kommerziellen Tools bis hin zu kostenfreien und dennoch gut funktionieren Open-Source-Programmen - umsetzen.\nEine Variante ist die Verwendung des Open-Source-Tools foremost.\nBenutzung von foremost\nMöchte man Dateien aus einem defekten oder verschlüsselten Image extrahieren, ist es am einfachsten, wenn man sowohl den Datei-Header als auch den Footer kennt. Im folgenden Beispiel wird versucht, aus einem Image verloren gegangene xcf-Dateien des Open-Source-Bildbearbeitungsprogramms GIMP wiederherzustellen. Leider bietet foremost per Standardkonfiguration keine Möglichkeit der Extraktion von xcf-Dateien an. Daher ist es empfehlenswert, sich vorher Referenzdateien anzusehen. Hierbei wird überprüft, ob die Anfänge von fünf Referenzdateien dasselbe Muster aufweisen:\n\nEs scheint, dass alle Dateien mit derselben Zeichenfolge beginnen. Daher wird in diesem Beispiel der folgende Header (”gimp xcf”) definiert:\n\x67\x69\x6d\x70\x20\x78\x63\x66\nDasselbe Verfahren wird nun für das Dateiende genutzt. Nicht alle Dateitypen haben ein fest definiertes Ende. Anhand der Referenzdateien kann überprüft werden, ob dies hier der Fall sein könnte:\n\nDie Dateienden sind nicht unbedingt eindeutig, scheinen aber grundsätzlich mit vier Nullbytes abzuschließen:\n\x00\x00\x00\x00\nMit diesen Informationen kann nun eine neue Zeile in der Konfigurationsdatei von foremost (\n/etc/foremost.conf\n) eingetragen werden:\n\nDabei wird Folgendes definiert:\nDateiendung, mit der die wiederhergestellten Dateien benannt werden sollen\nBeachtung der Groß- und Kleinschreibung von gesuchten Dateiinhalten (in diesem Fall nein)\nMaximale Dateigröße (hier 5 MB)\nDatei-Header\nDatei-Footer\nAnschließend kann foremost mit den Parametern -o (Ablageort für wiederhergestellte Dateien) und -i (zu nutzendes Image) gestartet werden:\nforemost -o recovered -i image.img\nDer Test zeigt, dass foremost mit der gesetzten Konfiguration in der Lage war, mehrere xcf-Dateien wiederherzustellen.\n\n\n\nFile Carving im konkreten Ransomware-Fall\nWas im Beispiel für die xcf-Dateien so einfach aussah, hat sich im konkreten Fall beim Kunden als wesentlich schwieriger herausgestellt. Die dringend benötigten Daten hatten keinen eindeutigen Datei-Footer und sowohl die Header als auch die Dateiinhalte der unterschiedlichen Dateitypen wiesen sehr starke Ähnlichkeiten auf. Dadurch ergaben sich folgende Probleme:\nBeim File Carving würden zwangsläufig unsaubere Dateien entstehen\nDie Dateien lassen sich nicht während des Carvings eindeutig voneinander unterscheiden\nUm die Probleme anzugehen, haben wir uns vom Kunden mehrere Referenzdateien der unterschiedlichen Dateitypen zur Analyse geben lassen. Dadurch konnten wir zumindest schon einmal eine maximale Dateigröße mit ein wenig Puffer definieren. Um die Dateien zu carven, konnten wir uns nur am Datei-Header orientieren. Dieser war bei allen Dateitypen sehr ähnlich, weshalb wir in der Konfiguration unseres Carving-Tools nur einen Bruchteil des Headers genommen haben, um “möglichst grob” erst einmal alles aus dem Dateisystem herauszuholen.\nAls Ergebnis hatten wir hunderte Dateien mit mehreren Gigabytes an Gesamtgröße. Um die Dateien nun voneinander zu unterscheiden, mussten wir vermehrt auf den Inhalt der Dateien achten. Aufgrund der Datenmenge wäre eine manuelle Überprüfung nicht effizient gewesen. Daher haben wir uns dazu entschlossen, für die unterschiedlichen Dateitypen YARA-Regeln zu schreiben, mit denen wir automatisiert die Inhalte durchsuchen und die Dateien nach Typ sortieren konnten.\nJedoch gab es das Problem, dass diese Dateien aufgrund ihrer unsauberen Wiederherstellung nicht ohne weiteres in die neu aufgesetzten Systeme importiert werden konnten. Nach einiger Recherche konnten wir ein Programm finden, was genau dieses Problem für uns gelöst hat. Der Kunde konnte die unsauberen Dateien in dieses Programm importieren, das Tool hat alles, was nichts mit den für das System wichtigen Daten zu tun hatte, ignoriert und konnte per Knopfdruck die relevanten Dateiinhalte sauber exportieren.\nDadurch war es möglich, unternehmenskritische Systeme trotz Ransomware wieder in den Betrieb zu nehmen und eine vorerst als notwendig erscheinende Zahlung der Erpressersumme abzuwenden.\nFazit\nIn diesem konkreten Fall hatten wir und der Kunde das Glück, dass große Teile der virtuellen Maschinen trotz Ransomware-Verschlüsselung noch intakte Daten enthielten. Durch das File Carving und zusätzliche freie Werkzeuge konnte ein unternehmenskritisches System wieder in Betrieb genommen und dem Kunden zumindest ein Teil seiner Arbeitsfähigkeit zurückgegeben werden.\nDennoch ist es wichtig, folgendes zu betonen: Solche Erfolge sind Ausnahmen und keine Garantie, mit dieser Methode immer erfolgreich sein zu können.\nEs ist für Unternehmen absolut wichtig, alle relevanten Systeme regelmäßig zu sichern und diese von der IT-Infrastruktur zu trennen. Hilfe für sichere Backup-Konzepte finden sich unter anderem beim BSI.\nWeiterführende Links\n\nhttps://foremost.sourceforge.net/\n\n\nhttps://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/03_CON_Konzepte_und_Vorgehensweisen/CON_3_Datensicherungskonzept_Edition_2023.pdf\n\n\nhttps://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Umsetzungshinweise/Umsetzungshinweise_2022/Umsetzungshinweis_zum_Baustein_CON_3_Datensicherungskonzept.pdf\n\n

Mit File Carving Daten aus durch Ransomware verschlüsselten VMs retten.

Daten trotz Ransomware retten

Im letzten Beitrag haben wir den Grundstein für unsere Reise zur Resilienz gelegt, indem wir geklärt haben, was Resilienz ist. Das war notwendig, um ein gemeinsames Ziel für unsere Reise zu schaffen.\nIn diesem Beitrag werden wir den Ausgangspunkt unserer Reise betrachten und diskutieren, warum es nicht mehr sinnvoll ist, dort zu verweilen.\nBeachte, dass ich eine prototypische Reise eines Unternehmens von Null zu Resilienz beschreiben werde. Der Ausgangspunkt und die Zwischenstationen sind Zustände, die ich selbst schon mehrfach erlebt habe. Dennoch handelt es sich um ein vereinfachtes Modell, was bedeutet, dass der Weg deines Unternehmens anders aussehen kann.\nVielleicht kannst du den Zustand deines Unternehmens nicht mit einem einzigen Ort in Verbindung bringen, den ich beschreiben werde. Vielleicht findest du in deinem Unternehmen eine Mischung von Eigenschaften, einige von Ort A und einige von Ort B. Das ist alles völlig in Ordnung. Die Realität ist immer verworrener als ein gutes Modell.\nDie Reise, die ich diskutieren werde, soll helfen, über den Zustand deines Unternehmens nachzudenken und über sinnvolle nächste Schritte nachzudenken. Sie liefert Erkenntnisse, die für die nächste Zwischenstation der Reise notwendig sind. Es werden typische Maßnahmen erörtert, die erforderlich sind, um zu diesem Zwischenstopp zu gelangen. Sie zeigt Abwägungen und blinde Flecken auf. All diese Dinge sind Argumentationshilfen. Nicht mehr. Aber auch nicht weniger.\nDie Metapher des Bergsteigens\nIch werde eine Bergsteiger-Metapher verwenden, um den Weg zur Resilienz zu beschreiben. Wir beginnen in einem scheinbar lieblichen Tal und erklimmen schrittweise den Gipfel, wobei wir unterwegs auf mehreren Hochebenen Rast machen.\nIch verwende diese Metapher, um zu verdeutlichen, dass die Reise zur Resilienz keine schöne und einfache Fahrt auf einer asphaltierten Straße ist, mit heruntergekurbeltem Fenster, ausgestrecktem Arm, Wind in den Haaren und einer schönen Melodie aus dem Radio.\nDas wünschen sich viele Menschen, Entscheidungsträger auf höherer Ebene ebenso wie Software-Ingenieure. Sie hätten gerne eine einfache 5-Punkte-Liste, die sie einfach abhaken können, und dann – voilà – sind sie resilient. Mission erfüllt! Juhu!\nLeider ist es nicht so einfach. Resilienz zu erlangen ist harte Arbeit, vor allem die späteren Schritte. Deshalb verwende ich die Metapher des Bergsteigens, um das zu verdeutlichen:\nEs wird nicht einfach sein.\nTeile der Reise werden anstrengend sein.\nEs wird Hindernisse auf dem Weg geben, die wir überwinden müssen.\nAber die Aussicht vom Gipfel ist atemberaubend ... ;)\n\n\n\nVeränderung als orthogonales Thema\nViele der Hindernisse, die wir überwinden müssen, haben mit der Umsetzung von Veränderungen zu tun – technische Veränderungen, Kommunikationsänderungen, Prozessänderungen und organisatorische Veränderungen. Wie ich in \nfrüheren Beiträgen\n erörtert habe, sind Veränderungen immer schwierig und chaotisch. Wie ich außerdem in meinem \nBeitrag über das Dilemma zwischen Bedarf und Wunsch\n dargelegt habe, reicht es nicht aus, die Menschen zu überzeugen (was schon schwer genug ist). Es ist auch notwendig, das übergeordnete System, die Organisation und die Art der Zusammenarbeit zu ändern.\nViele Leute fragen mich dann nach dem Patentrezept, um Veränderungen durchzusetzen. Natürlich fragen sie nicht direkt nach einem Patentrezept, aber im Grunde ist es das, was sie gerne von mir haben möchten. Die Wahrheit ist: Es gibt kein Patentrezept! Es tut mir leid, dass ich deine stillen Hoffnungen enttäuscht habe.\nEs gibt einen Grund, warum es Hunderte und Tausende von Büchern über die Umsetzung von Veränderungen gibt – und der Grund ist, dass Veränderungen schwierig sind. Wenn es ein Patentrezept gäbe und ich es kennen würde, hätte ich ein Buch darüber geschrieben und würde bequem von den Tantiemen leben.\nSelbst bekannte Experten auf dem Gebiet des Wandels wie z. B. \nJohn Kotter\n (die – im Gegensatz zu mir – recht gut von ihren Buchtantiemen leben) haben noch kein Patentrezept gefunden. Sie bieten zwar viele gute und umsetzbare Ratschläge, aber die Umsetzung von Veränderungen ist nach wie vor schwierig und chaotisch.\nInsgesamt ist das Veränderungsmanagement ein orthogonales Thema, das immer dann erforderlich ist, wenn man etwas verändern will, und daher nicht spezifisch für Resilienz. Da ich selbst kein Experte für Veränderungen bin, werde ich mich auf die erforderlichen Argumentationshilfen und Argumente beschränken, die du auf der rationalen Seite benötigst. Wenn du nach Ratschlägen suchst, wie du Veränderungen in deiner Organisation am besten umsetzen kannst, verweise ich auf die Bücher über Veränderungen, die es in Hülle und Fülle gibt. (1)\nNeben der Implementierung der Veränderung gibt es noch einige weitere Hindernisse, die wir auf dem Weg dorthin überwinden müssen. Das Gute an dieser Geschichte ist, dass wir nicht den Mount Everest besteigen müssen. Wir müssen nicht in lebensfeindliche Höhen klettern und es kaum lebendig bis zum Gipfel schaffen. Wir wollen den Berg der Resilienz erklimmen. Das ist immer noch eine Herausforderung. Aber es ist machbar.\nDas Tal der Feature-Vollständigkeit\nAlso gut, eine Bergbesteigung. Wir sind vorbereitet und bereit, unsere Reise anzutreten. Aber wo fangen wir an, und warum sollten wir den Ort, an dem wir uns gerade befinden, überhaupt verlassen? Schauen wir uns einmal um.\n\n\nIch neige dazu, den Ausgangspunkt das Tal der Feature-Vollständigkeit zu nennen. Die IT-Organisationen vieler Unternehmen, die ich kenne, befinden sich noch immer in diesem Tal. Die Kerneigenschaft einer solchen Organisation ist, dass\ndie IT-Entwicklungsabteilung (Dev) für die Bereitstellung von Features zuständig ist, während\ndie IT-Betriebsabteilung (Ops) für die Verfügbarkeit der laufenden IT-Systeme verantwortlich ist.\nDas bedeutet auch, dass die Entwicklungs- und die Betriebsabteilung getrennte Abteilungen sind, deren Anreizsysteme auf unterschiedlichen Zielen basieren. Die Entwicklungsabteilung erhält Anreize auf der Grundlage der Anzahl der implementierten Funktionen, während die Betriebsabteilung Anreize auf der Grundlage der Produktionsstabilität und der Verfügbarkeit der von ihr betriebenen IT-Systeme erhält.\nVerfügbarkeit und Zuverlässigkeit\nWenn wir uns mit Resilienz beschäftigen, müssen wir die Verfügbarkeit der Systeme betrachten. Eines der Hauptziele von Resilienz ist die Maximierung der Verfügbarkeit des jeweiligen Systems, d. h. den Zeitanteil zu maximieren, in dem das bezogene System entsprechend der Systemspezifikation agiert und auf externe Stimuli reagiert (oder zumindest sinnvolle gesetzte Erwartungen erfüllt, wenn es keine formale Spezifikation gibt). Dabei spielt es übrigens keine Rolle, ob es sich um ein technisches oder ein nichttechnisches System handelt.\nNur der Vollständigkeit halber: Im Zusammenhang mit sicherheitskritischen Systemen betrachten wir oft eher die Zuverlässigkeit (Qualitätsmerkmal Reliability) als die Verfügbarkeit (Qualitätsmerkmal Availability). Zuverlässigkeit beschreibt die Wahrscheinlichkeit, dass ein System innerhalb einer definierten Zeitspanne korrekt agiert und reagiert. Der Unterschied besteht darin, dass Verfügbarkeit den Prozentsatz der Gesamtzeit angibt, in der ein System gemäß seiner Spezifikation reagiert.\nBei einer Herz-Lungen-Maschine z. B. ist es wichtig, dass sie während einer Operation einwandfrei funktioniert. Es spielt keine Rolle, ob sie danach für drei Wochen zur Wartung geschickt wird. Es kommt nur darauf an, dass sie während der Operationen einwandfrei funktioniert, denn eine Fehlfunktion der Maschine während einer Operation würde das Leben des Patienten in Gefahr bringen.\nIm Vergleich dazu sind gelegentliche Ausfälle z. B. in einem E-Commerce-System, unkritisch, solange sie relativ selten auftreten und nicht zu lange dauern. Daher betrachten wir in nicht sicherheitskritischen Kontexten – und das sind die meisten Kontexte im Zusammenhang mit Unternehmenssoftware – eher die Verfügbarkeit als die Zuverlässigkeit. Wir interessieren uns mehr für den Gesamtprozentsatz der Zeit, in der das System seine Aufgabe ordnungsgemäß erfüllt, als für die Wahrscheinlichkeit, dass ein System innerhalb eines bestimmten Zeitrahmens nicht ausfällt.\nDa die meisten von uns in nicht sicherheitskritischen Umgebungen arbeiten, werde ich mich bei der Diskussion über den Weg zur Resilienz auf Verfügbarkeit beschränken. Bedenke jedoch, dass wir in sicherheitskritischen Umgebungen in der Regel eher an Zuverlässigkeit interessiert sind. (2)\nVerfügbarkeit als P.A.L.\nKommen wir nach diesem kurzen Exkurs zurück zum Tal der Feature-Vollständigkeit: Wir können beobachten, dass das gesamte Entwicklungsbudget für die Implementierung von Geschäftsfunktionen reserviert ist. Verfügbarkeit wird an Ops „ausgelagert“. Aus Sicht der Entwicklungsabteilung ist Verfügbarkeit kein Thema, sondern ein P.A.L. (Problem Anderer Leute).\nEvaluations-Schema\nBevor wir beurteilen, ob eine solche Trennung der Zuständigkeiten ein tragfähiges Konzept im Kontext von Resilienz ist, wollen wir zunächst eine strukturierte Bewertung des Tals der Feature-Vollständigkeit vornehmen, wobei wir uns besonders auf die Parteien jenseits von Ops konzentrieren (da Ops immer ein echtes Interesse an Resilienz – oder zumindest hoher Verfügbarkeit – haben wird). Wir werden das gleiche Bewertungsschema für alle Stationen unserer Reise verwenden und dabei die folgenden Aspekte betrachten:\nHaupttreiber – was ist das Hauptziel in Bezug auf Resilienz?\nLeitfragen – welche Fragen treiben die Maßnahmen an?\nTypische Maßnahmen – Beispiele für Maßnahmen, die zur Umsetzung des jeweiligen Resilienzniveaus verwendet werden\nTrade-offs – die Vor- und Nachteile der jeweiligen Station unserer Reise\nWann ist es sinnvoll – wann ist es in Ordnung, einen solchen Ansatz in Bezug auf Resilienz zu verwenden\nWann ist es zu vermeiden – wann wir unsere Reise nicht an der gegebenen Haltestelle stoppen dürfen\nWirkungskreis – wer und was ist von den erforderlichen resilienzbezogenen Maßnahmen betroffen\nBlinder Fleck – was der Haupttreiber übersieht und die Reise zur nächsten Station auslöst, sobald es erkannt wird\nBewertung des Tals der Feature-Vollständigkeit\nMit Hilfe dieses Bewertungsschemas können wir das Tal der Feature-Vollständigkeit auf strukturierte Weise bewerten:\nHaupttreiber\nDer Haupttreiber ist die Maximierung des Durchsatzes an Geschäftsfunktionen (Business Features).\nDie gesamte Organisation betrachtet die IT lediglich als Mittel zur Umsetzung der IT-Anteile ihrer Geschäftsideen, d. h. die IT wird in der Regel als Kostenstelle (Cost Center) betrachtet. Folglich geht es in der IT vor allem darum, so viele Funktionen wie möglich zu den geringstmöglichen Kosten zu implementieren.\nVon Ops wird erwartet, dass sie eine hohe Laufzeitverfügbarkeit der IT-Systeme garantieren, aber niemanden interessiert, wie sie das tun. Verfügbarkeit wird als P.A.L. betrachtet – oder genauer gesagt: als ein Ops-Problem.\nLeitfragen\nTypische Leitfragen sind:\nWerden die Geschäftsanforderungen korrekt umgesetzt?\nWie können wir Features schneller implementieren?\nEs geht darum, die Kosten pro Feature zu minimieren und gleichzeitig die fachliche Korrektheit zu bewahren. Die Feature-Kosten werden innerhalb der Grenzen des umgebenden Projekts minimiert, was die typische Organisationsform der Softwareentwicklung ist. Diese lokalen Optimierungen\nberücksichtigen weder die Auswirkungen der Kostenoptimierung für andere Teile der Systemlandschaft, die nicht Teil des Projekts sind\nnoch die Auswirkungen für die zukünftige Wartung und Evolution der geänderten Systemteile über das Projektende hinaus\nnoch berücksichtigen sie irgendwelche laufzeitbezogenen Eigenschaften wie Verfügbarkeit (Availability) , Betreibbarkeit (Operability), Beobachtbarkeit (Observability), Sicherheit (Security), Skalierbarkeit (Scalability), Leistung (Performance), Wiederherstellbarkeit (Recoverability), Ressourcenverbrauch (Resource Usage) und so weiter, es sei denn, sie stehen in direktem Zusammenhang mit dem jeweiligen Geschäfts-Feature.\nTypische Maßnahmen\nDie Maßnahmen in Bezug auf Resilienz – oder genauer gesagt: die Maximierung der Verfügbarkeit – finden alle auf Ops-Seite statt, da der Rest der Organisation dieses Thema ignoriert und einfach erwartet, dass sich die Ops darum kümmern. Typische Maßnahmen sind:\nBereitstellung redundanter Hardware und Infrastrukturkomponenten, einschließlich Hochverfügbarkeits-Hardware\nRedundanter Betrieb der Softwaresysteme hinter einem Load Balancer mit Failover oder innerhalb einer Clusterlösung mit Failover\nStrenge Übergaberegeln für Dev-Artefakte, da Ops (berechtigterweise) nicht darauf vertraut, was Dev „über die Mauer wirft“\nLange Testphasen vor der Produktion, um potenzielle Produktionsprobleme zu prüfen – wiederum, weil Ops (berechtigterweise) nicht darauf vertraut, was Dev „über die Mauer wirft“\n...\nInsgesamt: Alles, was Ops beeinflussen kann.\nTrade-offs\nDie grundlegenden Kompromisse einer solchen Umgebung sind:\nFür Devs ist es vergleichsweise angenehm, weil sie sich um weniger kümmern müssen. Insbesondere können sie alle relevanten Laufzeiteigenschaften der Software ignorieren und sich ausschließlich auf die Implementierung der Geschäftslogik konzentrieren (was je nach Umgebung stressig genug sein kann).\nFür Ops ist das nicht so angenehm, denn von ihnen wird erwartet, dass sie Software zuverlässig ausführen, die ohne Rücksicht auf Verfügbarkeit oder andere relevante Laufzeiteigenschaften erstellt wurde.\nResilienz ist ein Nicht-Thema. Die zugrunde liegende Annahme ist, dass alles immer unter Kontrolle ist.\nWann ist es sinnvoll\nEin solcher Ansatz ist in Ordnung, wenn du dich nicht in einem sicherheitskritischen Kontext befindest und deine IT-Systemlandschaft hauptsächlich aus monolithischen, isolierten Systemen besteht, die über Batch-Schnittstellen miteinander kommunizieren.\nIch werde diese Bewertung im nächsten Beitrag in Verbindung mit der Diskussion über den blinden Fleck dieses Ansatzes ausführlicher erörtern.\nWann ist es zu vermeiden\nEin solcher Ansatz sollte vermieden werden, wenn deine IT-Systemlandschaft aus vielen hochgradig vernetzten Systemen besteht, die über Online-Schnittstellen miteinander kommunizieren – was für heutige IT-Systemlandschaften üblich ist.\nEr ist unzureichend für Umgebungen, die intern verteilte Systeme verwenden (Stichworte: servicebasierte Architekturen, Microservices) und völlig unzureichend für sicherheitskritische Kontexte.\nAuch auf diese Bewertung werde ich im nächsten Beitrag im Zusammenhang mit der Diskussion des blinden Flecks dieses Setups näher eingehen.\nWirkungskreis\nDer Wirkungskreis der resilienzbezogenen (oder besser: verfügbarkeitsbezogenen) Maßnahmen ist auf die Ops-Abteilung und den Teil der IT-Systemlandschaft beschränkt, den Ops beeinflussen kann.\nBlinder Fleck\nKurz gesagt, aus einer Nicht-Ops-Perspektive ist der blinde Fleck dieses Aufbaus alles außer den Geschäftsfunktionen – was die Frage aufwirft, ob „blinder Fleck“ hier der richtige Begriff ist oder ob wir es eher als „blinde Fläche mit einem kleinen nicht-blinden Fleck“ bezeichnen sollten. Dieses Setup ignoriert insbesondere die Realität der heutigen Systemlandschaften. Es ignoriert auch die Resilienz und behandelt Verfügbarkeit als P.A.L. (oder besser gesagt: als Ops-Problem).\nZusammenfassung\nWenn wir uns die Bewertung des Tals der Feature-Vollständigkeit ansehen, erkennen wir, dass dieses Setup für fast alle heutigen IT-Systemlandschaften ungeeignet ist. Sie lässt Resilienz völlig außer Acht und macht Verfügbarkeit zu einem reinen Ops-Problem, während der Rest der Organisation sie völlig ignoriert. Schlimmer noch, das Verhalten der Nicht-Ops-Teile der Organisation ist in Bezug auf Verfügbarkeit oft kontraproduktiv.\nEs stellt sich die Frage, warum ein solches Setup immer noch ziemlich häufig anzutreffen ist, obwohl es für die Anforderungen der heutigen IT-Systemlandschaften nicht mehr geeignet ist.\nWir werden diese Frage im nächsten Blog Post ausführlicher diskutieren. Wir werden auch erörtern, wie die Erkenntnis, dass dieser Ansatz nicht mehr ausreicht, uns zum ersten Plateau unserer Reise führt. Und wir werden besprechen, was wir auf dem ersten Plateau finden. Bleib dran ... ;)\n\n(1) Persönlich kann ich neben den Veränderungsbüchern von dem bereits erwähnten John Kotter die Bücher „Fearless Change: Patterns for Introducing New Ideas„ und „More Fearless Change: Strategies for Making Your Ideas Happen" von Mary Lynn Manns und Linda Rising. Sie haben nützliche Veränderungspraktiken entlang eines Veränderungsprozesses mit Hilfe eines Musteransatzes schön gegliedert. ︎\n(2) Wenn ein sicherheitskritisches System rund um die Uhr funktionieren muss, wie z. B. ein Kraftwerk, sind wir an beidem interessiert, an Zuverlässigkeit und Verfügbarkeit. \nDieser Blogpost ist \nursprünglich auf Englisch\n in Uwe Friedrichsens Blog erschienen

große, grüne Wiese mit einem Teich rechts, Bäume links und Villa im Hintergrund

Erfahre in Teil 2 der Blogreihe, wie klare Ziele und strukturierte Prozesse dabei helfen, Widerstandsfähigkeit effektiv aufzubauen.

Resilienz Teil 2: Das Tal der Feature-Vollständigkeit

Der lange und steinige Weg zur Resilienz – Teil 2: Das Tal der Feature-Vollständigkeit

IT-Expertenwissen von Entwickler*innen für Entwickler*innen

CODECENTRIC BLOG

Angular 17 – Eine echte Renaissance?

Für mehr Nachhaltigkeit – CO2 sparen mit Rust

Produktstrategie als Erfolgsgrundlage: Warum du nicht mit deiner Vision starten solltest

Wie als Software-Entwickler sichtbar werden?

How to gain visibility as a software developer?

Charge your APIs Volume 26: Choosing the Right API Development Strategy: A Guide to API Design First vs. Code First Approaches

Agilität

Big Data

CI/CD

Cloud

Container

DevOps

Digitalisierung

Generative KI

IT-Security

Künstliche Intelligenz

Kubernetes

Microservices

Produktmanagement

Bei codecentric leben wir eine offene Kultur und teilen gerne unser Wissen. Tauche weiter in unsere Welt ein.

WISSENS-HUB

Der Softwerker Spezial Generative KI

Drei Personen sitzen am Tisch in einem Meetingraum mit Laptop und besprechen sich.

Leistungen

codecentric weiterhin unter den Top 25 der Lünendonk-Liste 2025

In 2025 ist codecentric erneut unter den Top 25 mittelständischen IT-Beratungsunternehmen in der Lünendonk-Liste

JOBANGEBOT

JavaScript

Java

Spring

React

Python

Scala

Kotlin

GitHub

GitLab

Azure

Google Cloud

Remote Work

Senior Agile Consultant und Developer (w/d/m) 

Logo SoftwerkerCast - der IT-Podcast von Techies für Techies

Community

Softwareentwicklung

Kultur

SoftwerkerCast

Events – codecentric mittendrin

CODECENTRIC ENTDECKEN

Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Arbeitsweise

Referenzen

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Events

Fachmedien

Softwerker

Webinare

Wissens-Hub

Deine Entwicklung

Jobs

Kultur & Karriere Podcast

Unsere Kultur

Karriere

Über uns

Aktuelles

Kontakt

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Im codecentric Blog gibt es Expertenwissen zu aktuellen IT-Themen: Agile Methoden, Softwarearchitektur, KI, Testing und vieles mehr. ► Jetzt entdecken!

Blog: IT-Wissen von Entwickler*innen für Entwickler*innen

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

codecentric Blog

IT-Expertenwissen von Entwicklerinnen für Entwicklerinnen

Themenfilter

CODECENTRIC ENTDECKEN

Der Softwerker Spezial Generative KI

Senior Agile Consultant und Developer (w/d/m)

Leistungen

SoftwerkerCast

codecentric weiterhin unter den Top 25 der Lünendonk-Liste 2025

Events – codecentric mittendrin

codecentric Blog

IT-Expertenwissen von Entwickler*innen für Entwickler*innen

Themenfilter

Bitte Themen anklicken

CODECENTRIC ENTDECKEN

Der Softwerker Spezial Generative KI

Senior Agile Consultant und Developer (w/d/m)

Leistungen

SoftwerkerCast

codecentric weiterhin unter den Top 25 der Lünendonk-Liste 2025

Events – codecentric mittendrin

Jetzt für unseren Newsletter anmelden

IT-Expertenwissen von Entwicklerinnen für Entwicklerinnen