IT-Trends-Blog

IT-Trends-Blog

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Der Weg zu Microservices

Kategorie: Trend-Wende

Microservices sind einer der Haupttrends unter IT-Architekten. Dabei wird unter anderem eine Frage sehr kontrovers diskutiert: Wie kommt man zu Microservices? Hierauf gibt es zwei unterschiedliche Antworten: Monolith-First (von Martin Fowler) und Skip the Monolith, Start with Microservices (von Stefan Tilkov). Oft scheinen mir Architekten eher von dem zweiten Weg überzeugt. Doch ist dies wirklich der Richtige?

Ein Hauptargument gegen den Monolith-First-Ansatz ist die enge Kopplung bei einem Monolithen, die eine nachträgliche Unterteilung in einzelne Services schier unmöglich macht. Auch Fowler kritisiert dies. Er wirft hier die Frage auf, ob es nicht zu viel Disziplin erfordere einen Monolithen modular auf Microservices vorzubereiten. Aber ist das tatsächlich der Fall? Für mich ist dies eine Frage des richtigen Architektur-Managements, denn gerade bei großen, komplexen Systemen muss eine lose Kopplung von Subsystemen aktiv gesteuert werden.

Abbildung 1 zeigt einen typischen Architektur-Management-Prozess: Im ersten Schritt ist es im Hinblick auf Microservices enorm wichtig, eine Architektur mit Raum zur Entwicklung und losen Kopplung von Subsystemen zu entwerfen. Das meint:

  1. Kein gemeinsames Domänenmodell
  2. Zugriff zwischen Subsystemen nur über Facaden-Schnittstellen, die eine API mit einem selbständigen Datenmodell bereitstellen.

Dies ist allerdings nur der Startpunkt, an den sich weitere wichtige Phasen anschließen:

  • Ein frühzeitiger Wissenstransfer der Zielarchitektur an die Entwickler, damit die Regeln beachtet werden. Hierbei spielt die Vermittlung der Motivation für die Architektur eine wichtige Rolle, damit diese von den Entwicklern akzeptiert und umgesetzt wird.
  • Ein möglichst automatisches Monitoring dient als Sicherheitsnetz, das Regelverletzungen identifiziert. Hier helfen Tools wie Sonargraph, um etwa die lose Kopplung abbilden und überwachen zu können.
  • Der Prozess schließt mit der Problembehebung, bei der Fehlentwicklungen in der Architektur korrigiert und die lose Kopplung wieder hergestellt werden. Aber auch eine Anpassung der Architektur ist wichtig. Ich bin der Meinung, dass man bei komplexen Systemen und trotz gutem Domänenwissen nur sehr selten direkt im ersten Wurf die richtige Architektur findet. Stattdessen sind Refactorings bzgl. Service- und Komponentenschnitt nötig. Diese sind in einem Monolithen schlicht einfacher umsetzbar, da man nicht durch die Komplexität eines verteilten Systems behindert wird.

Durch einen solchen Prozess kann das System in Subsysteme mit geringer Kopplung unterteilt werden. Somit könnenauch in einem Monolithen mehrere Teams parallel und unabhängig entwickeln. Dennoch: Der nächste Schritt zu Microservices, bei denen diese Subsysteme zusätzlich unabhängig voneinander deployed werden können, bedeutet immer noch einiges an Arbeit.

Folgende Aufgaben gilt es zu lösen:

  • Den bereits im Monolithen existierenden gemeinsamen Transaktions-Kontext aufbrechen und durch verteilte Transaktionen ersetzen,
  • das Prinzip der Eventual Consistency berücksichtigen,
  • Failover-Strategien für den Ausfall von Subsystemen entwerfen und implementieren.

Dies sind für mich die Nachteile des Monolith-First-Ansatzes. Hier stellt sich die schwierige Frage, ob es ein größerer Aufwand ist, im Nachhinein hierfür Lösungen auf Basis lose gekoppelter Subsysteme zu finden oder ob der anfänglich höhere Refactoring-Aufwand beim direkten Microservices-Ansatz teurer zu Buche schlägt. Was denken Sie?

Der Monolith ist schon da?

Doch welche Möglichkeiten hat man, wenn das System schon als Monolith mit großen, eng gekoppelten Modulen existiert? Auch hier können Architektur-Management-Tools wie Sonargraph helfen. Sie unterstützen bei der Definition der idealen Zielarchitektur und dem Abgleich mit dem Ist-Zustand. Virtuelle Refactorings auf Modellbasis helfen bei der Planung von Arbeitspaketen zur Zerteilung des Monolithen. Dies ermöglicht ein kontrolliertes Refactoring im Monolithen und späteres Aufbrechen in richtige Microservices. Zumindest den ersten Teil habe ich in Großprojekten mehrfach erfolgreich durchführen können (s. Abbildung 2).

Abbildung 2: Methodisches Refactoring eines Monolithen

In Summe spricht für mich durchaus vieles für den Monolith-First-Ansatz, sofern man diesen von Beginn an durch ein aktives Architektur-Management untermauert. Letzteres bedeutet nur einen überschaubaren Zusatzaufwand und hat den Vorteil, die Qualität der Architektur des Monolithen im Griff zu haben. Für die restlichen Herausforderungen beim Aufbrechen in Microservices wird man Lösungen finden. Was ist Ihre Meinung? Haben Sie den Monolith-First-Ansatz schon einmal erfolgreich erprobt? Oder lagen Ihre Probleme eher im fehlenden Architektur-Management?

Über den Autor

Tim Lüecke
Tim Lüecke
Ich unterstütze meine Kunden bei der Konzeption und dem Management von Systemarchitekturen großer, komplexer Systeme. Hierbei setze ich auf das Wissen aus unseren Capgemini Architektur Best Practices und versuche dies im kundenspezifischen Kontext anzuwenden.

Kommentar hinterlassen

Ihre E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit einem * gekennzeichnet.