Continuous Delivery benötigt Microservices
Das Ziel von Continuous Delivery ist es, einen konstanten Strom neuer Features in Produktion zu bringen. Der Code wird in den Phasen der Continuous-Delivery-Pipeline auf Herz und Nieren geprüft: Zu den Tests zählen Unit-Tests genauso wie Kapazitätstests oder Akzeptanztests. Alle diese Tests sollten automatisiert sein. Manuelle Tests gibt es nur als explorative Tests. Am Ende der Pipeline bringt ein automatisiertes Deployment die Software schließlich in Produktion.
Viele große Systeme sind Deployment-Monolithen, die nur als ganzes in Produktion gebracht werden können. Für einen Deployment-Monolith ist der Aufbau der Continuous-Delivery-Pipeline aufwändig:
- Der Durchlauf durch die Pipeline dauert sehr lange, weil sehr viele Tests notwendig sind. Die gesamte Funktionalität des Deployment-Monolithen muss getestet werden. Nur so können Regressionen vermieden werden.
- Die Infrastruktur für die Tests ist komplex. Ein ausreichend dimensioniertes System muss bereitgestellt werden. Auch die Drittsysteme müssen für Tests geeignet nachgebildet werden.
- Das Risiko beim Deployment in die Produktion ist hoch. Bei einem Fehler kann das gesamte System still stehen.
- Maßnahmen zur Reduktion des Risikos sind aufwändig. Canary Releasing installiert die Software zunächst auf einem Server, bevor der gesamte Cluster auf die neue Version gehoben wird. Dazu sind ein ausreichend dimensionierter Server und ein zuverlässiges Deployment-Verfahren notwendig. Bei Blue/Green-Deployment wird eine weitere komplette Umgebung aufgebaut. So muss nur auf die neue Umgebung umgeschwenkt werden, wenn die Anwendung in Produktion gehen soll. Das ist alles mit erheblichen Aufwänden verbunden.
Im Gegensatz zum Deployment-Monolithen sind Microservices kleine Deployment-Einheiten, die unabhängig voneinander in Produktion gebracht werden können. Microservices machen Continuous Delivery sehr einfach: Die Continuous-Delivery-Pipeline ist schnell, weil viel weniger getestet werden muss. Die Infrastruktur ist überschaubar, weil die Microservices so klein sind. Das Risiko ist gering, weil bei einem Fehlschlag viel weniger Funktionalität ausfällt. Microservices sollten so konstruiert sein, dass sie den Ausfall anderer Microservices tolerieren können. Wenn also ein Microservice wegen eines Problems beim Deployment nicht mehr zur Verfügung steht, ist der Ausfall auf diesen Microservice begrenzt. Schließlich sind Canary Releasing oder Blue/Green-Deployment viel einfacher, weil der Aufbau der Umgebungen viel einfacher ist. So helfen Microservices bei den zentralen Herausforderungen von Continuous Delivery.
Microservices benötigen Continuous Delivery
Man kann sogar sagen: Microservices erfordern Continuous Delivery. Microservice-Systeme bestehen in der Regel aus sehr vielen Microservices - 50 oder 100 sind keine Seltenheit. Jeder Microservice kann einen anderen Technologie-Stack nutzen. So viele heterogene Services sind nur beherrschbar, wenn sie automatisch in Produktion gebracht werden können und auch das Monitoring und die Log-Analyse einheitlich gehandhabt werden. Sonst sind die Aufwände für das System einfach zu hoch. Ein manueller Schritt im Deployment eines Deployment-Monolithen kann noch akzeptabel sein - bei 50 oder 100 Microservices ist das nicht mehr machbar.
Microservices & Continuous Delivery - Ist der Schritt zu groß?
Weil Continuous Delivery mit Microservices besonders einfach ist und Microservices Continuous Delivery benötigen, sollten beide Ansätze zusammen eingeführt werden. Zwei grundlegende Änderungen gleichzeitig vorzunehmen, ist allerdings sehr risikoreich. Hier hilft eine weitere Eigenschaft von Microservices: Sie können andere Systeme ergänzen, indem sie beispielsweise nur bestimmte Anfragen bearbeiten und alle anderen Anfragen an das alte System weiterleiten. So können bestimmte Funktionalitäten mit Microservices umgesetzt und die Vorteile des Ansatzes ausgenutzt werden - also zum Beispiel die gute Unterstützung von Continuous Delivery.
Die Probleme von Continuous Delivery mit Deployment-Monolithen sind ein wesentlicher Grund für die Nutzung von Microservices. Das häufigste Szenario für die Einführung von Microservices ist die Ergänzung eines Deployment-Monolithen, um so Continuous Delivery zu ermöglichen.
Fazit
Microservices vereinfachen Continuous Delivery, weil die Deployment-Einheiten viel kleiner sind. Gleichzeitig sind Microservices ohne die Automatisierung von Continuous Delivery kaum denkbar. Diese Kombination ist eine Synergie - Microservices können zur Ergänzung vorhandener Systeme eingeführt werden. Das bietet nicht nur einen Einstieg in eine flexible Architektur, sondern auch eine gute Basis für Continuous Delivery.
Microservices in der Praxis – Workshop mit Eberhard Wolff und Stefan Tilkov
Am 26.-27. Oktober findet in Offenbach ein Praxis-Training statt, dass sich mit den architekturellen Ansätzen, Vor- und Nachteile sowie Technologien für die Entwicklung und den Betrieb von Microservices beschäftigt. Weitere Informationen zur Agenda finden Sie hier.