Microservices im Zusammenspiel mit Continuous Delivery, Teil 1 – die Theorie

Deep-dive & Fazit

Die Microservices können zum Beispiel mit REST miteinander kommunizieren. Da sie Oberflächen anbieten, können Services Links auf andere Services anbieten und so miteinander integriert werden. Um Microservices vollständig umzusetzen, sind noch einige Punkte zu beachten: Idealerweise sollten sie getrennte Datenbestände und Datenbanken haben. Nur dann sind die Microservices wirklich unabhängig voneinander. Wenn zwei Services dieselbe Datenbank nutzen, kann man die Datenstrukturen und das Schema nicht mehr ändern, was die weitere Entwicklung einschränkt. Eine Replikation von Daten aus anderen Microservices ist denkbar.

Die Schnittstellen müssen rückwärtskompatibel sein. Sonst sind bei der Softwareverteilung einer neuen Serviceversion auch alle abhängigen Services neu zu deployen. Ebenso sollten sie zustandslos sein. Beim Neustart eines Microservice geht so kein Zustand verloren. Natürlich lässt sich in einer Datenbank der Zustand speichern. Schließlich hat jeder Microservices Schnittstellen zu anderen Microservices. Ihr Aufruf kann fehlschlagen – beispielsweise weil sie gerade nicht laufen oder ein Problem im Netzwerk aufgetreten ist. Daher sind bei solchen Aufrufen entsprechende Vorkehrungen zu treffen.

Durch Microservices entstehen weitere Herausforderungen: Die Aufteilung der Anwendung in einzelne Komponenten wird technisch als eine Aufteilung in verschiedene Microservices implementiert. Um die tatsächlich umgesetzte Architektur zu verstehen, müssen also die Kommunikationsbeziehungen zwischen den Services bekannt sein – das kann aber in der Praxis nur schwer nachvollziehbar sein. Ebenso ist es schwierig, Funktionen von einem Microservice in einen anderen zu verschieben. Im Extremfall sind die Microservice noch nicht einmal in derselben Programmiersprache geschrieben, sodass die zu verschiebende Funktion neu zu implementieren ist. In einem Monolithen, der in einer Programmiersprache implementiert ist, sind solche Umstrukturierungen viel einfacher.

Ein wichtiger Hinweis noch: Dieser Artikel fokussiert auf die Vorteile von Microservices in Bezug auf Continuous Delivery – aber es gibt viele weitere Gründe für Microservices, auf die nur kurz eingegangen sei. Da sich Microservices unabhängig voneinander verteilen lassen, ist es kein Problem, jeden für sich weiterzuentwickeln. Dadurch kann man neue Features unabhängig voneinander schreiben. Wenn für jeden Microservice ein Team zuständig ist, kann es ein neues Feature schnell und produktiv umsetzen.

Weil Microservices so strikt getrennt voneinander sind, können sich auf Code-Ebene keine Abhängigkeiten einschleichen. Dadurch ist sichergestellt, dass sie auch langfristig wartbar bleiben. Wer schon einmal die Architektur eines größeren Systems analysiert hat, kennt das Phänomen: Innerhalb einer Deployment-Einheit kann die Architektur schnell chaotische Zustände annehmen, wenn kein aktives Architektur-Management betrieben wird. Zyklische und andere unerwünschte Abhängigkeiten sind keine Seltenheit. Zwischen den Deployment-Einheiten sind die Abhängigkeiten aber immer relativ sauber. Genau deshalb kann man auch erwarten, dass die Abhängigkeiten zwischen den Microservices immer relativ klar sein werden.

Eine Continuous Delivery Pipeline steht für die Optimierung der Deployment-Prozesse – und damit dem Fokus auf der Automatisierung. Auf den ersten Blick scheint dieses Vorgehen keine Auswirkungen auf die Software und die Softwarearchitektur zu haben. Bei genauerer Betrachtung wird aber offensichtlich, dass Feature Toggles zum Ein- und Ausschalten bestimmter Features praktisch eine Notwendigkeit für Continuous Delivery sind. Sonst führt das Deployment einer neuen Version automatisch dazu, dass neue Features zur Verfügung stehen, die vielleicht noch gar nicht live sein sollen.

Um die Continuous Delivery Pipelines einfach zu halten und schnelles Feedback zu ermöglichen, sollten für Continuous Delivery die einzelnen Deployment-Einheiten nicht zu groß sein. Dazu bieten sich Microservices an. Sie bringen auf der einen Seite einige neue Herausforderungen mit, bieten aber gleichzeitig den Vorteil einer besseren Produktivität durch unabhängige Softwareverteilung und eine klare Trennung der Komponenten.

Im zweiten Teil geht es darum, wie sich Microservices konkret technisch ausrollen lassen – immerhin entsteht eine Vielzahl an einzelnen Prozessen, die konfiguriert und mit einer Ablaufumgebung versehen werden müssen. (ane)

Eberhard Wolff (@ewolff)
arbeitet als freiberuflicher Architekt und Berater. Außerdem ist er Java Champion und Leiter des Technologie-Beirats der adesso AG. Sein Schwerpunkt liegt auf modernen Softwarearchitekturen.

  1. Eberhard Wolff; Continuous Delivery; dpunkt.verlag 2014
  2. Jez Humble, David Farley; Continuous Delivery; Reliable Software Releases through Build, Test, and Deployment Automation; Addison-Wesley 2010