Whitebird
Moderator
Dabei seit: 31.03.2009
Beiträge: 5.170
Herkunft: Aus dem Nichts, Nordsee/Ecke Ossiland!!!
 |
|
 Noch mehr Katastrophen aus der Welt der Microservices |
     |
Noch mehr Katastrophen aus der Welt der Microservices
Zu den sieben Problemen mit Microservices, die ich bereits beschrieben habe, kommen vier weitere – selbst erlebt in meinem Berufsalltag.
8. April 2026 um 09:20 Uhr / Von João Alves
Der Artikel ist eine Übersetzung. Das Original ist im Blog des Entwicklers João Alves erschienen.
Als ich zum ersten Mal über Probleme mit Microservices schrieb, dachte ich noch, wir würden sie irgendwann lösen – mit besseren Tools, Frameworks und mehr betrieblicher Reife. Das ist nicht passiert. Wir haben nur gelernt, mit dem Chaos zu leben.
Verteilte Systeme überraschen uns immer wieder: Timeouts, Retries und Fallacies verschwinden nicht, sie nehmen nur andere Formen an. Vielleicht ist das die eigentliche Lektion: Bei der Softwareentwicklung geht es nicht darum, Unsicherheiten zu beseitigen, sondern darum, elegant mit ihnen umzugehen.
Als Mitglied des Runtime-Teams bei Adevinta, wo ich eine interne Kubernetes-as-a-Service-Lösung für den Rest des Unternehmens aufgebaut habe, habe ich Einblick in alles bekommen, was Softwareentwickler auf der Grundlage verteilter Systeme entwickeln – und frage mich: Kann eine Plattform überhaupt gut sein, wenn sie uns nicht überrascht durch das, was Menschen da so bauen? Ich finde: nein.
Deshalb füge ich den sechs bereits beschriebenen Problemen vier weitere hinzu, mit denen ich selbst zu tun hatte.
Problem 7: mehr Services als Entwickler
Wenn ich in ein neues Team oder einen neuen Bereich komme, bitte ich sehr schnell um eine Einführung in die Architektur. Aus Neugier, ja, aber vor allem, weil es überlebenswichtig ist. Es hilft mir, mir ein mentales Bild der Funktionen, der Komplexität, der technischen Schulden und der Grenzen des Machbaren zu machen. Es ist zudem der beste Weg, mit den Mitarbeitern (Individual Contributors, ICs) in Kontakt zu kommen und zu verstehen, wie sie das System wahrnehmen.
Dabei verblüfft mich immer wieder, wie viele Teams mehr Dienste als Entwickler haben. Nicht nur ein bisschen mehr, sondern vier oder fünf Dienste pro Person. Auf einer Präsentationsfolie liest sich das beeindruckend – "Wir haben unsere Plattform vollständig modularisiert!" -, bis man sich klarmacht, dass damit ein einziger Mensch Eigentümer, Betreiber und Ansprechpartner bei Störungen für fast ein halbes Dutzend verteilter Systeme ist.
Große Tech-Unternehmen wie Google oder Uber mit einer erstklassigen internen Plattform mögen damit zurechtkommen. Sie haben automatische Abhängigkeits-Upgrades, standardisierte Vorlagen, CI/CD-Abstraktionen, Dashboards für die Zuweisung der Verantwortung für Dienste und gut besetzte SRE-Teams (Site Reliability Engineering). Für die meisten anderen Unternehmen ist das aber selbst mit guter Automatisierung quasi eine Katastrophe in Zeitlupe.
Denn jeder neue Dienst verursacht zusätzlichen kognitiven Overhead, etwa bei neuen Pipelines, Dashboards, Warnmeldungen, Secrets, Abhängigkeiten und Laufzeitkontexten. Mit jeder Änderung wächst der Bereich, auf den sie sich auswirkt. Und wenn das Team umstrukturiert wird, was immer passiert, verwaisen diese Dienste. Niemand weiß mehr, wofür sie da sind, aber alle haben zu viel Angst, sie abzuschalten. Also laufen sie einfach weiter.
Problem 8: das Gateway zur Hölle
Eine der größten Herausforderungen bei verteilten Systemen ist die Gateway-Schicht – das Bindeglied zwischen Frontends und Microservices oder zwischen Diensten. Theoretisch handelt es sich um eine klare Abstraktion. In der Praxis ist sie jedoch oft ein Druckkessel für all die Komplexität, mit der wir uns an anderer Stelle nicht auseinandersetzen wollten.
Authentifizierung und Autorisierung sind dafür gute Beispiele. Beides klingt einfach, bis man mehrere Identitätsanbieter, fein abgestufte Berechtigungen und mandantenübergreifende Zugriffsbereiche kombinieren muss – und das alles bei gleichbleibender Sicherheit und Geschwindigkeit.
Viele Teams unterschätzen, wie ressourcenintensiv diese Vorgänge sind. Und was noch schlimmer ist: Sie überlasten ihre Gateways damit. Plötzlich wird aus einer ursprünglich als schlank konzipierten Routing-Schicht ein CPU-gebundener Monolith, der bei jeder Anfrage Krypto-Operationen und Zugriffsprüfungen durchführt.
Und dann gibt es da noch Thread-Pools und I/O-Verhalten. Gateways sind in der Regel der erste und letzte Schritt in einer Anforderungskette. Wer nicht weiß, ob seine nachgelagerten Dienste CPU- oder I/O-gebunden sind, wird Pools und Timeouts falsch konfigurieren.
Extrem häufig bedienen Gateways mit Standard-Thread-Zahlen, die von einem Spring-Boot-Starter oder einer Node.js-Vorlage übernommen wurden, Hunderte Verbindungen gleichzeitig. Das Ergebnis sind Latenzspitzen, Thread Starvation und kaskadierende Ausfälle, die sich über die gesamte Flotte ausbreiten.
Um zuverlässige Gateways zu entwickeln, braucht es mehr als YAML und gute Absichten. Man muss sich mit Backpressure, Circuit Breakers und dem Verhalten der Laufzeitumgebung unter Last auskennen. Den meisten Teams wird erst bewusst, wie anfällig ihre Konfiguration ist, wenn ein einziger falsch konfigurierter Pool die gesamte Produktionsumgebung lahmlegt.
Problem 9: technologischer Wildwuchs
Alle Unternehmen beteuern, dass sie "technische Autonomie" schätzen. Aber nur wenige wissen, was das bedeutet. Wenn man Entwicklern nur genug Zeit und Freiheit lässt, greifen sie auf jedes erdenkliche Framework, jede Laufzeitumgebung und jede Bibliothek zurück, die man sich vorstellen kann.
Hier Kotlin-Coroutinen, dort Vert.x oder Go-Services, die neben einer Rust-API laufen und die nur noch eine einzige Person versteht. Es ist, als besuche man einen Ideen-Freizeitpark – was so lange Spaß macht, bis etwas kaputtgeht und niemand mehr weiß, wie man die Attraktion neu startet.
Dieser technologische Wildwuchs entsteht nicht aus Nachlässigkeit der Entwickler, sondern weil die Führungsebene sie unter dem Deckmantel der Innovation zulässt – oder sogar fördert! Innovation ohne Verantwortlichkeit führt jedoch zu Entropie.
Jeder neue Stack bedeutet eine neue Betriebsoberfläche, einen neuen Sicherheitsvektor, neue Einführungs- und Einarbeitungskosten. Und wenn Umstrukturierungen stattfinden – Spoiler: Das tun sie immer! – werden diese "Snowflake"-Systeme zu Landminen.
Und was, wenn dann die einzige Person, die diese Probleme lösen könnte, das Unternehmen gerade verlassen hat? Dann wird das Fluktuationsrisiko vom Personal- zum Systemproblem. Mit jeder "einzigartigen" Technologie-Entscheidung wird eine Abhängigkeit zu einer einzelnen Person geschaffen. Ist die Person weg, geht auch das Systemwissen verloren.
Immerhin verbessert sich die Lage in diesem Bereich. KI-gestützte Tools zum Codeverständnis, Architektur-Reviews und interne Tech-Radare helfen Teams dabei, wieder den Überblick zu gewinnen. Sie beseitigen den Wildwuchs nicht, machen ihn aber leichter zu durchschauen. Die Unordnung zu erkennen, ist oft der erste Schritt dazu, sie zu beseitigen.
Problem 10: wenn das Organigramm zur Architektur wird
Ein weiteres Problem ist, wenn das Organigramm zur Architektur wird. Es hängt ein bisschen mit Problem 7 zusammen, hat aber einen organisatorischen Aspekt, über den ich schon oft mit Thibault gesprochen habe.
Wenn Teams anfangen, Dutzende Microservices zu entwickeln, organisieren sie sich oft nach Teamverantwortung statt nach Fachbereich. Es gibt dann also zum Beispiel ein "Zahlungsteam", ein "Wachstumsteam" und so weiter. Die Dienste werden in den Kubernetes-Namespace deployt, der Terraform-Stack wird ins AWS-Konto des Teams eingestellt und alle Dashboards und Alarme mit dem Slack-Kanal des Teams verknüpft.
Auf dem Papier sieht das ordentlich aus. Jedes Team hat seine klare Ownership, seine Autonomie und seinen Spielraum, in dem es experimentieren kann, ohne andere zu stören – bis das Organigramm sich verändert (und es verändert sich ständig).
Dann kommt ein neuer VP of Engineering, mit neuen Ideen für mehr Effizienz und bessere Abstimmung, und strukturiert um. Plötzlich wird das "Payments-Team", das für zwei klar begrenzte Kontexte zuständig war – beispielsweise "Payments" und "Subscriptions" -, in zwei Teams aufgeteilt.
Ein Team behält "Payments", das andere übernimmt "Subscriptions". Doch die gesamte Infrastruktur, die Namespaces und die IAM-Richtlinien sind nach wie vor im alten Konto verflochten.
Nun gibt es zwei Möglichkeiten:
- 1. Die Infrastruktur wird gemeinsam genutzt und damit eine neue Art von Abhängigkeitschaos geschaffen.
- 2.Es wird alles migriert – was nur eine kunstvolle Umschreibung ist für: "Herzlichen Glückwunsch, du hast dir gerade ein sechsmonatiges Migrationsprojekt eingehandelt!"
Keine der Optionen fühlt sich gut an. Die erste bremst die Teams aus und verursacht Unklarheiten bei den Zuständigkeiten ("Wer kümmert sich jetzt um diesen Alarm?"). Die zweite verschwendet Zeit und Budget für Arbeiten, die keinen Mehrwert für die Nutzer haben.
Das Problem reicht tiefer als bis zu Cloudkonten oder Namespaces. Es betrifft die Kopplung an die Organisationsstruktur. Wenn Conways Gesetz (g+) auf Umstrukturierungen trifft, kommt es zu einem architektonischen Drift. Systeme, die einst die Teamstruktur widergespiegelt haben, überdauern sie und plötzlich spiegelt die Topologie der Plattform wider, wer 2021 wem unterstellt war.
Das ist eine der teuersten Arten von technischen Schulden. Sie bleibt lange unsichtbar und verdreifacht dann plötzlich das (nicht vorhandene) Budget für Umstrukturierungen.
Die neue Normalität
Vier Jahre nach meinem ersten Text sehe ich immer noch dieselben Muster, nur verpackt in andere Frameworks, Clouds und YAML-Dialekte. Die Tools haben sich weiterentwickelt, die Grundlagen jedoch nicht: Verteilte Systeme bleiben verteilt, Menschen bleiben Menschen und die Komplexität bleibt ungebrochen.
Was als Nächstes kommt, wird das Ganze noch interessanter machen. Wir versuchen nun, KI-Agenten zu entwickeln: autonome, zustandsbehaftete Systeme, die miteinander kommunizieren, wahrscheinlichkeitsbasierte Entscheidungen treffen und auf unvorhersehbare Eingaben reagieren. Mit anderen Worten: verteilte Systeme mit eigenen Meinungen. Was kann da schon schiefgehen?
Die Trugschlüsse bleiben die gleichen, nur auf einer anderen Ebene. Weder Latenz noch Konsistenz, Beobachtbarkeit oder Determinismus verschwinden auf magische Weise, nur weil die Komponente nun "denkt".
Als Branche werden wir den gleichen Zyklus erneut durchlaufen: anfängliche Begeisterung, kreative Katastrophen, Booms von Werkzeugen und schließlich ein bisschen Demut.
Ob Microservices oder KI-Agenten: Die Geschichte ändert sich nicht grundlegend. Wir versuchen immer noch, chaotische Systeme dazu zu bringen, sich vorhersehbar zu verhalten. Und wir tun so, als könnten wir sie vollständig kontrollieren.
Die gute Nachricht ist: Wir werden weiter lernen. Die schlechte Nachricht: wahrscheinlich auf die harte Tour.
Übersetzt von Juliane Gunardono mit Unterstützung von DeepL
quelle: golem.de
__________________
Der frühe Vogel trinkt 'n Korn??? 
 Grüße von Whitebird
|
|
