Softwarearchitektur: Noch mehr Katastrophen aus der Welt der Microservices
Inhalt
Der Artikel ist eine Übersetzung. Das Original ist im Blog des Entwicklers João Alves erschienen.(öffnet im neuen Fenster)
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.
- Anzeige Hier geht es zum Handbuch für Softwareentwickler bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.