Der Schlüssel zur Bewertung des Nutzens einer Microservices-IT-Architektur (MS) ist ein gutes Verständnis des Kundenkontextes.

Seines Geschäfts, seiner Prozesse (Betrieb, IT, Produkt- und Systemlebenszyklus usw.), seiner vorhandenen Technologien und seiner Erwartungen (langfristige Stabilität vs. hohe Dynamik, Agilität vs. langfristige Planung usw.).

Die folgende Zusammenfassung basiert auf der erfolgreichen Durchführung eines solchen Projekts (oder mehrerer verwandter Projekte), bei dem die Bereitschaft und das Engagement des Kunden, die richtige Auswahl der Hauptakteure und die Flexibilität, die in jeder Phase der Durchführung berücksichtigt werden muss, die Hauptrolle spielten.

Was sind diese Microservices?

Die IT-Architektur kann mit verschiedenen Strategien und unterschiedlichen Ansätzen aufgebaut werden. Natürlich kommt es auf den Kontext an – wer, was, wie lange sie dienen soll, wie lange der erwartete Lebenszyklus der zu erstellenden Systeme ist usw.

Microservices sind einer der Architekturstile, die auf der Idee beruhen, dass wir Systeme aus kleinen (wirklich sehr kleinen) Komponenten aufbauen, die autonom sind (so wenig wie möglich von anderen Systemen und Komponenten abhängig). Ein typischer Microservice sollte in wenigen Tagen, höchstens Wochen, programmiert werden können, über eine eigene Datenbank verfügen und mit anderen Diensten (falls erforderlich oder erwünscht) auf die „leichteste“ Weise kommunizieren – z. B. HTTP REST. Es wird viele solcher Dienste geben – da sie klein sind – und es ist daher ratsam, sie automatisch bereitzustellen und zu verwalten.

Im Gegenzug – und das ist die Hauptmotivation für die Anwendung dieses Ansatzes – gewinnen wir erhebliche Vorteile:

• saubere Architektur – „starke Grenzen“ der einzelnen Komponenten, eindeutige und klare Schnittstellen und Zuständigkeiten
• unabhängiges Deployment – wenn ich nur eine kleine Änderung (wieder) einführe, habe ich weniger Risiko, etwas anderes zu versauen
• geringere Abhängigkeit von Technologien und Anbieterbindung – solche Dienste sind unabhängig und können von verschiedenen Technologien und Anbietern bereitgestellt werden
• Skalierbarkeit – die Fähigkeit, nur die Komponenten, die den Engpass darstellen, in der Breite zu skalieren, und nichts anderes

Andererseits muss sich der IT-Architekt auch der Risiken und Nachteile eines solchen Ansatzes bewusst sein:

• Verteilt – mehr unabhängige Dienste = höherer Grad der Verteilung = komplexere Programmierung
• eventuelle Konsistenz – mehr Datenbanken = höheres Risiko, dass die Daten zu einem bestimmten Zeitpunkt (noch oder schon) nicht miteinander übereinstimmen (auch wenn nur kurz)
• komplexere betriebliche Tätigkeiten – ich liefere dem Betrieb kein „System“, sondern eine Reihe von „Komponenten“, die der Betrieb übernehmen, einsetzen und am Laufen halten muss; es ist wie bei schwedischen Möbeln – ich liefere Komponenten, die der Kunde zu dem Ganzen, das er braucht, zusammensetzen kann – aber auch muss
• Leistung – die Kommunikation zwischen Microservices ist in der Regel „teurer“ als interne Aufrufe innerhalb eines Monolithen; das Risiko wird besonders deutlich, wenn die Granularität (Größe) der Microservices unangemessen gewählt wird oder die Grenze zwischen ihnen nicht richtig gewählt wird

In jedem Fall sind die Kriterien für die Anwendung dieses Architekturansatzes klar: Ich werde ihn anwenden, wenn die Vorteile die Risiken überwiegen, die ein erfahrener IT-Architekt mit Kenntnis des Kundenkontextes abschätzen und berechnen können sollte.

Welche Aufgabe musste der Kunde lösen?

Kürzlich haben wir einem Kunden erfolgreich geholfen, ein technologisches und strukturelles Problem in seinen Vertriebs- und Kundensystemen zu überwinden, indem wir einen schrittweisen und nahtlosen Übergang von Monolithen zu Microservices vorgenommen haben.

Auf seiner Agenda standen der Verkauf von Dienstleistungen und Waren in den Filialen im ganzen Land, der E-Shop, elektronische Dienstleistungen für Endverbraucher und alles, was zur Kundenbetreuung gehört (Selbstbetreuung, Call Center usw.).

Alle Systeme endeten (oder begannen) jedoch mit einem großen und relativ komplexen (und daher teuren) System, das zwar zuverlässig war, aber bereits an seine Grenzen stieß – teure und riskante Änderungen, Leistungsprobleme, überteuerte Betriebs- und Entwicklungskosten usw.

Die typische Motivation am Anfang war also: Wir haben ein altes, teures und langsames monolithisches System. Teure Lizenzen. Eine Steigerung der Leistung durch Skalierung war bereits praktisch unmöglich. Leistungsfähigere Hardware verbesserte die Leistung nicht mehr. Eine Änderung der Architektur der Lösung bedeutete, alles noch einmal von vorne zu beginnen.

Der Kunde war sich bewusst, dass die Abhilfe nur durch eine Änderung des Lösungsansatzes möglich war und nicht durch den Austausch einer Box durch eine andere.

Analysten und Designer haben richtig eingeschätzt, dass verschiedene Teile des Systems unterschiedliche Lebensdauern, eine unterschiedliche Änderungsdynamik, unterschiedliche Leistungsanforderungen und ein unterschiedliches Skalierungsverhalten aufweisen.

Und dass sich die IT-Welt in den letzten Jahren so verändert hat, dass Entwickler und andere Fachleute andere Erwartungen an die Technik und die Methodik ihrer Arbeit haben – das Bohren in einem Monolithen, den sie sonst nirgendwo antreffen werden, trägt nicht zum Gefühl der Sinnhaftigkeit bei.

Daher wurde beschlossen, den Monolithen schrittweise aufzulösen und durch mehrere unabhängige Anwendungen zu ersetzen, die in einer serviceorientierten Architektur organisiert sind. Die einzige verbleibende Frage war, welche Granularität sie haben sollten – einige wenige Hauptanwendungen oder viele kleine autonome Dienste.

Am Ende setzte sich die Ansicht durch, dass „so und so“, je nachdem, wie viel nützliche Leistung jeder Bereich uns bieten würde, auch welche Art der Dekomposition seiner Daten erlauben würde – denn die Verteilung monolithischer Daten (die Datenbank) ist der Prüfstein für jeden Versuch einer stark verteilten Architektur (von der MS ein Extremfall ist).

Warum haben wir dem Kunden Microservices empfohlen?

Es ist wichtig, sich von Anfang an darüber im Klaren zu sein, dass es innerhalb des Kundenkreises mehrere Gruppen gibt, die unterschiedliche Anforderungen und Erwartungen an das System haben. Betrieb, Unternehmen, Bediener und Assistenten, Call-Center oder Marketing und natürlich die Kunden in den Geschäften und Läden – alle kommen auf unterschiedliche Weise, zu unterschiedlichen Zeiten und zu unterschiedlichen Zwecken mit dem System in Kontakt. Die Befriedigung (und Beruhigung) des Verkehrs ist nicht weniger wichtig als die Erfüllung der Erwartungen des Marketings.

Daher haben wir alle Auswirkungen des neu vorgeschlagenen Konzepts (der Architektur) berücksichtigt – von der Entwicklung und Weiterentwicklung des Systems über seine Bereitstellung für Tests und Betrieb bis hin zu seiner Ausmusterung oder schrittweisen Ersetzung. Es ist auch klar, dass keine Anforderung endgültig ist, dass in einigen Monaten und Jahren alles anders sein kann, dass das System sich anpassen muss – verschiedene Teile davon, mit unterschiedlicher Geschwindigkeit und in mehreren Dimensionen – funktionell, leistungsmäßig, benutzerbezogen.

Daher erklärten wir die Hauptvorteile der vorgeschlagenen Microservice-Architektur (für den größten Teil des Systems) zu sein:

⦁ Sequenzierung und Kontinuität = das System wird sequentiell, stückweise, im laufenden Betrieb, d.h. neben dem „business-as-usual“ geliefert. Kein BigBang, den niemand riskieren wird. Umfang und Geschwindigkeit der Lieferung können laufend reguliert werden, je nach Entwicklungskapazität und Kundenprioritäten.
⦁ Skalierbarkeit = kleine autonome Dienste sind ideal für die Skalierung, dieser Aspekt wird von anderen Architekturansätzen kaum erreicht
⦁ Unabhängigkeit = Flexibilität. Keine Bindung an einen Anbieter oder eine Technologie. Jeder Microservice oder jede Mikroanwendung kann innerhalb weniger Wochen (in der Größenordnung von Wochen) und unabhängig von Technologie, Framework und Anbieter ersetzt (neu implementiert) werden, da MS autonom sind. Die einzige Bedingung ist, dass die Integrationsschnittstellen eingehalten werden.
⦁ Stabilität = ein möglicher Fehler, Ausfall oder eine andere Unzulänglichkeit in einem Teil des Systems (einem Mikrodienst) wirkt sich in viel geringerem Maße auf das Ganze aus als bei einem Monolithen (der entweder läuft oder stillsteht), aber auch als „geschichtete“ dienstorientierte Architektur (bei der sich Probleme innerhalb einer einzigen Schicht über mehrere Bereiche ausbreiten können)
⦁ Geringe Kosten für kleine und mittlere Änderungen = es ist einfach zu verstehen, wie einzelne Microservices funktionieren, und eine Änderung/Reparatur vorzunehmen, ohne das Risiko einzugehen, etwas zu beschädigen, von dem ich nicht einmal weiß, dass es existiert. Das ist eine direkte Auswirkung der Unabhängigkeit – ich muss mich nicht direkt mit nicht verwandten Teilen des Systems befassen, da alle möglichen Verbindungen und Zusammenhänge explizit sind (über Schnittstellen).

Wie lange hat die Umsetzung gedauert?

Das Maß für ein erfolgreiches Projekt ist unter anderem die Dauer der Umsetzung, denn Zeit ist Geld und ein Projekt zu verlängern, bedeutet, es teurer zu machen. Aber die scheinbar einfache Kennzahl – wie lange das Projekt dauert und wie die Meilensteine gesetzt wurden – hat ihre Tücken. In diesem Fall wurde die Umstellung von einem monolithischen System auf eine MS-Architektur auf 3 Jahre geschätzt. Es war jedoch klar, dass das Implementierungsteam in dieser Zeit eine nicht unerhebliche Anzahl von Änderungen und Arbeiten übernehmen musste, die nicht im Plan vorgesehen waren:

• Veränderungen im Marketing und in der Wirtschaft (die Welt verändert sich und die Wirtschaft muss dies widerspiegeln, denn der Verkauf darf nicht aufhören)
• Rechtliche Notwendigkeit – eine Änderung der Gesetzgebung wird nicht im Voraus angekündigt und kann nicht verschoben werden. Wir haben GDPR, eCash und eine Reihe anderer Änderungen erlebt, die als Teil der Umgestaltung integriert werden mussten, ohne sie zu verschieben, zu stornieren oder zurückzudrängen.
• Lizenzierung und technische Beschränkungen – im Laufe des Projekts haben sich die Geschäfts- und Lizenzbedingungen, die Versionen der verwendeten Tools und Frameworks, die Unterstützung für bestehende und geplante Komponenten, neue Sicherheitsbedrohungen und die Empfehlungen zu ihrer Beseitigung geändert. Aber das sind die Risiken eines jeden nicht ganz so kurzen Projekts.

Trotz dieser Einflüsse gelang es, das Projekt pünktlich in seine endgültige Form zu bringen (die Abweichung betrug nur wenige Tage).

Warum lohnen sich Microservices-Unternehmen?

Ein Unternehmen, das ein System für sein Kerngeschäft baut (oder bauen lässt), hat in der Regel ganz bestimmte Erwartungen in Bezug auf seine Funktionalität und Zuverlässigkeit sowie die Kosten für die Beschaffung.

Aber die Gesamtkosten für den Besitz dieses Systems, seine Nutzung, seine Wartung und seine schrittweise oder stufenweise Ersetzung oder Modifizierung – hier sind die Schätzungen sehr ungenau (und dafür gibt es objektive Gründe). Tatsächlich erfordert die Entscheidung für ein neues System oder eine größere Änderung an einem alten System eine Vorhersage darüber, wie sich das Unternehmen, seine Kunden und sein Geschäft in Zukunft entwickeln werden. Monolithische Systeme führen in der Regel dazu, dass Entscheidungen für eine lange Zeit getroffen werden – wenn ich mich dafür entscheide, dann für eine lange Zeit und eine Änderung der Entscheidung wird teuer werden. Der Aufbau eines Systems aus kleineren – aber zusammenarbeitenden – Teilen birgt Risiken (ich muss ständig Entscheidungen treffen und abwägen, was als Nächstes zu tun ist), aber ich kann jede Entscheidung relativ kostengünstig und schnell ändern oder korrigieren. Je größer die Unsicherheit ist, die ich in meine Pläne einbeziehen muss, desto mehr lohnt es sich für mich, in eine skalierbare, anpassungsfähige Architektur für meine Systeme zu investieren.

Hochdynamische Branchen wie Telekommunikation, Energie, Medien und alles, was mit dem Internet zu tun hat, gehen heute keine Risiken mehr ein und entscheiden sich für einen Ansatz, bei dem alles bis zum nächsten Steuerjahr geändert und ersetzt werden kann.

Microservices – ist das die Zukunft?

Die heutige Welt – in der sich alles um Technologie dreht – ist sehr schnell. Ideen werden recycelt, aber ihre Nutzung ist so schnell und billig geworden, dass sich die Grundprinzipien des Aufbaus eines Unternehmens verändert haben – nicht nur im Bereich der Technologie oder IT.

Die Realität drängt darauf, dass Änderungen heute vorgenommen, morgen ausprobiert und behoben oder verworfen werden müssen. MS als architektonischer Ansatz kommt dieser Philosophie entgegen – etwas schnell, wenn auch einfach, zu tun und es kurzfristig zu ändern (oder sogar komplett neu zu entwerfen), wenn es nicht gut läuft. Und umgekehrt – wenn es gut genug ist, sollte man nicht daran herumpfuschen (keine zusätzliche Arbeit machen = keine Zeit verschwenden).

Alle oben beschriebenen Vorteile von MS – maximale Flexibilität, einfache Skalierbarkeit, Portabilität (=Unabhängigkeit) – ermöglichen es dem Unternehmen, diese Änderungen schnell und mit geringem Risiko vorzunehmen und auf Veränderungen der externen Bedingungen (Markt, Technologie, Lieferanten), aber auch der internen Bedürfnisse und Erwartungen zu reagieren (Wechsel in die Cloud oder Vervielfachung der Ressourcen um eine Größenordnung oder Änderung des Umfangs Ihres Unternehmens usw.).

Also ja, Microservices sind die Zukunft und bereits die Gegenwart .

Wenn Sie Fragen haben oder den Einsatz von Microservices in Ihrem Unternehmen erwägen, zögern Sie bitte nicht, uns zu kontaktieren.

Rastislav Senderák, Architekt