Warum Microservices scheitern

Gianna ist bei Avidoo Inc., einer Produktivitätsplattform, als Senior Software Engineer eingestiegen. In einem Kick-off-Meeting mit dem Rest ihres Teams spricht sie das Thema Microservices an und fragt, ob das Team sie in irgendeiner Weise übernommen hat. Sie erhält sofort eine heftige Reaktion. "Wir haben versucht, Microservices einzuführen, aber sie funktionieren nicht", sagt Byron. "Es wurde ein furchtbares Durcheinander!", fügt Kary hinzu. Gianna blinzelte dreimal mit den Augen und erwartete irgendeine Erklärung, aber es kam keine. Nach einem unbehaglichen Schweigen fragt Gianna: "Und was ist passiert?" "Zuerst war es großartig. Jedes Mal, wenn wir gebeten wurden, etwas Neues zu erstellen, hatten wir die Möglichkeit, einen Dienst hinzuzufügen und beliebige Sprachen und Frameworks zu verwenden, mit denen wir experimentieren wollten. Wir stellten REST-APIs auf Systemen zur Verfügung, mit denen wir zusammenarbeiten mussten, oder arbeiteten direkt mit ihren Datenbanken. Aber nach einer Weile begannen die Dinge immer häufiger zu scheitern und die Entwicklung verlangsamte sich" Gianna seufzt. Für sie klingt das so, als hätte ihr Team einen verteilten Monolithen gebaut, während sie eigentlich Microservices entwickeln wollten.

Verteilte Monolithen und andere Monstrositäten

Was Gianna bei Avidoo Inc. erlebt hat, das natürlich ein fiktives Unternehmen ist, ist leider nur allzu häufig. Angezogen von der Vorstellung, dass Microservices ein Allheilmittel sind, neigen IT-Manager und -Ingenieure dazu, nicht zu ermitteln, welche Vorteile für ihr Unternehmen von Vorteil sind. Die Leute vergessen, dass es so etwas wie ein kostenloses Mittagessen nicht gibt. Gut aufgebaute Microservices-Architekturen bieten nicht nur Vorteile, sondern auch Kompromisse. Es gibt keine "falschen" Microservices, sondern nur Microservices, die nicht die Vorteile bieten, für die sie entwickelt wurden, oder die aufgrund ihrer Nachteile inakzeptable Risiken darstellen.

Vorteile

Wenn Sie sich für die Einführung von Microservices entscheiden, sollten Sie zunächst entscheiden, welche der Vorteile für Ihr Unternehmen in Frage kommen. Ich werde hier auf einige dieser Vorteile eingehen und in einer Zusammenfassung darlegen, warum sie nicht funktionieren. Bitte bleiben Sie bis zu meinem nächsten Beitrag dran, um die Details zu erfahren.

Größere Autonomie des Teams

Viele Unternehmen organisieren ihre Teams nach den Fachgebieten oder Komponenten ihrer Mitglieder. Bei der Schaffung von echtem Kundennutzen erfordert dies einen hohen Koordinationsaufwand zwischen den Teams und macht es nahezu unmöglich, parallel an einer Funktion zu arbeiten. [caption id="attachment_24662" align="aligncenter" width="272"] Wertschöpfung mit einem einzigen disziplinären Team[/caption] Microservices erleichtern die Autonomie, indem sie eine einzige Funktion abdecken. Daher kann ein Team die Funktion vollständig übernehmen, anstatt dass sie von mehreren Teams übernommen werden muss. Dies trägt dazu bei, die teamübergreifende Koordination zu reduzieren. [caption id="attachment_24663" align="aligncenter" width="274"] Wertschöpfung mit einem multidisziplinären Team[/caption]

Größere Fehlertoleranz

Wo es eine Autonomie des Teams gibt, sollte es auch eine Autonomie der Funktion geben, wie im vorherigen Abschnitt erläutert. Funktionen hängen oft voneinander ab. In den meisten Umgebungen erfolgt die Kommunikation nach Bedarf und auf Pull-Basis, oft über eine REST-Schnittstelle. Wenn diese Interaktion unternehmenskritisch ist, muss der Dienst, der von dieser Kommunikation abhängt, entweder über eine vernünftige Ausweichmöglichkeit verfügen oder er wird seinerseits ausfallen. Dieses ungesunde Muster wird häufig durch Systemprüfungen veranschaulicht, die fehlschlagen, wenn eine der Abhängigkeiten ungesund ist. Dies führt nicht nur dazu, dass die Bereitstellungsreihenfolge schwer zu verwalten ist, sondern ist auch ein Beispiel für eine harte Systemabhängigkeit. [caption id="attachment_24664" align="aligncenter" width="274"] Laufzeitabhängigkeiten[/caption] Mit den richtigen Softwarearchitekturen wie Event Sourcing, möglicherweise ergänzt durch CQRS, ist es möglich, die Laufzeitabhängigkeit zwischen den meisten Funktionen vollständig zu beseitigen. Dies ist vor allem auf den Übergang von einem Pull-basierten System zu einem Push-basierten System zurückzuführen.

Detaillierte Verwaltung des Software-Lebenszyklus

Ein weit verbreiteter Wunsch ist es, eine bestimmte Funktion innerhalb einer Anwendung durch eine glänzende neue zu ersetzen. Entweder weil die Anforderungen so weit abgewichen sind, dass eine Neufassung erforderlich ist, oder weil die Entwicklungsgeschwindigkeit durch technische Schulden, die durch die strengen Time-to-Market-Anforderungen entstanden sind, in den Keller gegangen ist. Man könnte naiverweise annehmen, dass diese Funktionen genauso schnell ersetzt werden können, wie sie ursprünglich geschrieben wurden, aber das ist meistens nicht der Fall. Allzu oft führt das Ersetzen einer Funktion dazu, dass viele Systeme, von denen sie abhängt, geändert werden müssen oder umgekehrt. [caption id="attachment_24666" align="aligncenter" width="480"] Fehlendes granulares Software-Lebenszyklus-Management[/caption] Durch die hochgradige Regulierung der Kommunikation zwischen den Systemen ist es möglich, eine oder mehrere Funktionen komplett auszutauschen, ohne eines der abhängigen Systeme berühren zu müssen.

Flexible Technologie-Auswahl

Zugegebenermaßen ist dies ein heikles Thema. Das Onboarding und die Schulung der Mitarbeiter für die Umstellung auf eine gemeinsame Technologie hilft bei der Mobilität zwischen den Teams, die durch Nachfrage oder persönliches Interesse bedingt ist. Aber die Umstellung von Mitarbeitern aus verschiedenen Abteilungen, die unterschiedliche Technologiepakete verwenden, von denen sie offen gesagt ziemlich überzeugt sind, kann zu Massenabwanderungen führen. [caption id="attachment_24665" align="aligncenter" width="480"] Erzwingen von Technologieentscheidungen[/caption] Solange die Technologien in Ihren automatisierten Test- und Bereitstellungs-Workflow integriert werden können, kann ein Team seine eigenen Technologieentscheidungen treffen. Warum sollte ein erfolgreiches Team, das sich in seiner Liebe für alles, was mit C# zu tun hat, einig ist, geändert werden, solange es ein Artefakt produziert, das die Überwachungs-, Protokollierungs- und Kommunikationsregeln Ihrer Plattform einhält?

Warum scheitern sie also?

Es gibt nicht den einen Weg, Microservices zu realisieren. Die Einführung von Microservices scheitert nicht daran, dass die Leute nicht wissen, wie sie es machen sollen, sondern daran, dass sie sich nicht mehr daran erinnern, welche Probleme sie ursprünglich gelöst haben. Wie bei jeder anderen Entscheidung hat auch die Übernahme bestimmter Aspekte von Microservices ihren Preis. Softwarearchitekten neigen dazu zu vergessen, dass sie ihrem Arbeitgeber nicht bei der Einführung von Microservices helfen sollten, sondern bei der Lösung echter Geschäftsprobleme. Das richtige Abwägen von Kosten und Nutzen dieser Aspekte gegenüber den Bedürfnissen eines Unternehmens ist von entscheidender Bedeutung. Nichtsdestotrotz gibt es eine Reihe von Standardoptionen, die eine vernünftige Ausgangsbasis für dieses kühne Abenteuer bilden können. Mehr dazu in der nächsten Folge!

An der Präsentation zu diesem Thema teilnehmen

Möchten Sie an der alle zwei Wochen stattfindenden Konferenz von Xebia teilnehmen und an einer Präsentation und einem Workshop zu diesem Thema teilnehmen? Präsentation und Workshop besuchen