The Good, the Bad and the Ugly: Legacy mit Microservices modernisieren

Publish date:

Die Modernisierung von Anwendungslandschaften kann wie der Wilde Westen unwirtlich und fordernd sein.

Thilo Hermann, Capgemini

Die digitale Transformation ist nicht der Wilde Westen, aber auch sie kann unwirtlich und fordernd sein. Etwa dann, wenn Unternehmen Anwendungen oder gar die gesamte Anwendungslandschaft schrittweise modernisieren wollen.

Microservices sind hierfür ein geeigneter Ansatz. Doch geschäftskritische Anwendungen sind meist in sogenannten Monolithen implementiert und besitzen eine hohe fachliche- und technische Komplexität. Die damit verbundenen Anforderungen lassen mich an Sergio Leones „Zwei glorreiche Halunken“ denken, der im Original „The Good, the Bad and the Ugly“ heißt:

  • Was gut ist – Monolithen sind gar nicht so monolithisch
  • Eher schlecht ist, dass Komponenten-Schnitte sich auf Datenbankebene oft nicht widerspiegeln
  • Richtig hässlich kann es werden, wenn die guten Eigenschaften von Monolithen in die neue Welt gerettet werden müssen

Blog per E-Mail abonnieren
RSS-Feed abonnieren

Kürzere Time-to-Market durch Microservices?

Die Reduzierung der Time-to-Market für neue so wie angepasste Services ist oftmals das Ziel von Modernisierungen. Im Unterschied zu einer kompletten Neuentwicklung müssen hier produktive Anwendungen architektonisch verändert werden. Insbesondere bei komplexen geschäftskritischen Anwendungen ergeben sich Herausforderungen, da diese in Monolithen strukturiert sind. Die Microservices-Architektur verspricht hierfür eine hohe Entwicklungsgeschwindigkeit, Anpassungsfähigkeit sowie horizontale Skalierung. Sie bietet Unabhängigkeit hinsichtlich Teams und Technologien, da jeder Microservice per Definition alleine lauffähig ist. Die wichtigen Aspekte lassen sich in Anlehnung an den Westernklassiker unterteilen:

„The Good“: Schnittstellen zwischen Monolithen

Die gute Nachricht ist, dass Monolithen gar nicht so monolithisch sind: Domain Driven Design und Bounded Context gibt es nicht erst seit den Microservices. Viele Monolithen sind applikationsseitig in Komponenten unterteilt, die über Schnittstellen kommunizieren. Sie sind im ersten Schritt Kandidaten für künftige Microservices, die bei Bedarf in weitere Microservices aufgeteilt werden können.

„The Bad“: keine verteilte Datenbank

Allerdings – und das ist die schlechte Nachricht— fehlt auf der Datenbankebene häufig eine strikte Trennung in Komponenten mit expliziten Schnittstellen. Stattdessen handelt es sich um eine hoch integrierte und konsistente Datenbank für die gesamte Anwendung mit folgenden Eigenschaften:

  • Konsistente Ablage und Verwaltung aller Daten
  • referentielle Integrität über Fremdschlüsselbeziehungen
  • Lesezugriffe in Abfragen über Komponenten-Grenzen hinweg
  • transaktionale Klammern über Schnittstellenaufrufe der Komponenten hinweg
  • Datenbank-Trigger und -Prozeduren (PL SQL, SQL PL), die Daten übergreifend verändern und die Anwendungslogik aufrufen

Es ist Aufgabe des Architekten, die Datenbank derart anzupassen, dass die Auswirkungen durch wegfallende Eigenschaften in der aufzubauenden, verteilten Microservice-Architektur adressierbar sind. Die Praxis zeigt, dass dies nicht ganz so einfach ist, wie in der Abbildung dargestellt. Die Auftrennung in mehrere Datenbanken wirkt sich auf die Funktionalität aus, da genannte Eigenschaften verloren gehen.

 „And the Ugly“: Vorteile von Monolithen in die neue Welt retten

Kommen wir zum „hässlichen“ Teil der Modernisierung: Optimierte Monolithen haben positive Eigenschaften, die Anwendern lieb und vertraut sind. Um Vorteile hinsichtlich Entwicklungsgeschwindigkeit, Skalierbarkeit und Flexibilität zu erhalten, muss man sich von einem Teil trennen.
Monolithen sind per Definition in sich konsistent. Die bekannten ACID-Eigenschaften (atomar, konsistent, isoliert und dauerhaft) gelten in einem verteilten System mit mehreren Microservices nicht. Stattdessen entsteht „Eventual Consistency“ und dies hat fachliche Auswirkungen. Die theoretischen Grundlagen dafür sind das CAP Theorem und der implizite Umstieg von ACID zu BASE (Basic Availability, Soft State und Eventual Consistency). Der neue, fachliche Schnitt der Microservices ist daher entscheidend, damit auch in der neuen, verteilten Architektur die fachlichen Anforderungen an die Konsistenz erfüllt sind! Die bestehenden fachlichen Komponenten sind zwar ein guter Startpunkt aber meist nicht eins-zu-eins mit den neuen Microservices gleich zu setzen. Eine intensive Zusammenarbeit mit den fachlichen Experten beim Schneiden ist entscheidend für den Erfolg.

Skalierbarkeit ist nicht gleich Performance

Weiterhin lassen sich einzelne Service-Aufrufe am schnellsten durch einen Monolithen bearbeiten.  Skalierbarkeit bedeutet nicht unbedingt Performance. Letztere wird negativ beeinflusst, da Microservice-Architekturen interne Schnittstellen zu externen umwandeln. Um trotzdem zügig ein Ergebnis zu erhalten, kann beispielsweise eine Command-Query-Responsibility-Segregation (CQRS) zur Trennung der schreibenden und lesenden Zugriffe eingesetzt werden. Sie stellt die Basis für ein Caching auf Anwendungsebene für performante, lesende Zugriffe zwischen Microservices dar. Alternativ ist eine Daten-Replikation als Pattern für performante, lesende Datenbank-Abfragen innerhalb eines Microservices möglich.

Nicht zuletzt muss die Resilienz für auf Microservices basierende Anwendungen explizit designt und implementiert werden. Asynchronität und nicht Verfügbarkeit von Services erfordern zudem fast immer Änderungen an fachlichen Prozessen. Auf technischer Seite sind Patterns wie Retry, Circuit Breaker, Bulkhead zusätzlich umzusetzen, um eine stabile Architektur (antifragile) zu gewährleisten. Hier empfiehlt es sich vorhandene Open-Source-Bibliotheken bzw. -Frameworks einzusetzen.

Fazit

Die Modernisierung mittels Microservices ist kein rein technisches Thema, sondern eben auch ein sehr fachliches. Mit der Einführung einer Microservices-Architektur sollten daher fachliche Prozesse und Transaktionen hinterfragt und bei Bedarf angepasst werden. Anders als im Western gilt hierbei nicht das Recht des Stärkeren. Stattdessen gewinnt ein vorausschauendes wie kooperatives Konzept, indem Architekten die Herausforderungen holistisch betrachten und diese gemeinsam mit dem Kunden lösen.

Sie möchten ihre IT-Architektur modernisieren und denken über den Einsatz von Microservices nach? Kontaktieren Sie mich!

Weitere Posts

Doppik

Update Buchhaltung: Hybride Software-Architekturen für Doppik

Jakob Boos
Date icon März 8, 2019

Mit EPSAS führt auch für Bund und Länder an der doppelten Buchführung (Doppik) kein Weg...

Aviation

Lufthansa: Wie der Turmbau zu Babel weltweit gelingt

Eldar Sultanow
Date icon März 1, 2019

Unsere Software Referenzarchitektur bringt die Luftfahrtbranche voran

IT-Trends

IT-Trends 2019: Nutzung intelligenter Technologien überraschend weit verbreitet

Thomas Heimann
Date icon Februar 22, 2019

Viele Unternehmen stecken noch mitten in der Digitalisierung, da kommt die nächste große...

cookies.

Mit dem Fortsetzen des Besuchs dieser Website akzeptieren Sie die Verwendung von Cookies.

Für mehr Informationen und zur Änderungen der Cookie-Einstellungen auf Ihrem Computer, lesen Sie bitte Privacy Policy.

Schließen

Cookie Information schließen