Ein Ziel der Digitalisierung ist neben der Fokussierung auf Business Value und digitale Wertschöpfungsketten die Verkürzung von Softwarereleasezyklen, um die Time to Market zu reduzieren. Microservices können einen wichtigen Beitrag leisten, wenn sie mit DevOps-Methoden kombiniert werden.

Automatisierung

Microservices sind autonom hinsichtlich Entwicklung, Änderung und Deployment. Deshalb lassen sie sich gut in einem automatisierten Continuous-Delivery-Prozess einbinden. Das Ziel ist, neue und geänderte Features schneller produktiv zu nehmen, ohne hierbei auf andere Services Rücksicht nehmen zu müssen. Weiterhin sollen zeitaufwändige, manuelle Prozesse vermieden werden. Die Automatisierung ist also der Schlüssel zur Reduzierung der Time to Market.

Bei Microservices DevOps wird der Betrieb (Operations) explizit mit einbezogen, wie im folgenden Schaubild dargestellt.

Der DevOps-Zyklus hat grob folgende Bestandteile:

• Continuous Integration (CI), d. h. automatisierte Builds und Unit Tests. Dies sollte in Softwareentwicklungsprojekten bereits zum Standard gehören. Ob der CI-Build ein potentielles Release generiert oder z. B. ein separater Nightly oder ein manueller Ad-Hoc-Build verwendet wird, ist dem Team überlassen.
• Testing: Automatisches Deployment des Release Candidates auf Test-Hostingumgebung(en)
  • Automatische Ausführung von Acceptance Tests. Abhängigkeiten zu anderen Microservices werden durch Service Stubs ersetzt.
  • Automatische Ausführung von Integration Tests. Hierbei wird ein Microservice nach erfolgreichem Durchlaufen aller Acceptance Tests und vor jedem Release im Zusammenspiel mit anderen Microservices im produktionsnahen Betrieb getestet.
• Release: Automatisches Ausrollen in den Produktionsbetrieb nach erfolgreichem Durchlaufen aller Tests.

Alle Bestandteile befinden sich in einer automatisierten Continuous Delivery Pipeline, die man z. B. mit Visual Studio Team Services abbilden kann.

Organisatorische Konstellationen

Je nachdem, wie ein Unternehmen aufgestellt ist, kann Microservices DevOps unterschiedlich ausgestaltet sein. Die im Folgenden beschriebenen Ansätze sind aufsteigend sortiert nach dem Grad der Gesamtverantwortung des Microservice-Teams.

Getrenntes Operations-Team

In großen Unternehmen ist das Betriebsteam in der Regel von der Entwicklung getrennt. Dies hat oft regulatorische oder historische Gründe. Es lohnt sich, diese Konstellation grundsätzlich in Frage zu stellen, wenn eine Umstellung auf Microservices angestrebt wird. Allerdings impliziert dies einschneidende, organisatorische Maßnahmen, die sich nicht auf die Schnelle umsetzen lassen.

Microservice können auch mit einem separaten Operations-Team betrieben werden, wenn man mit gewissen Einschränkungen hinsichtlich Time to Market und Effizienz leben kann. Praktisch könnte dies über Vereinbarungen geschehen, die zwischen Microservice-Teams und dem Betrieb getroffen werden. Die Zielsetzung ist hierbei, eine Automatisierung bestmöglich zu unterstützen:

• Buildprozess, dessen Ergebnis einfach auszurollende Deployment-Pakete sind
• Automatische Tests
• Skriptbasiertes Deployment und Servicekonfiguration
• Steuerung: automatisierbare Mechanismen zum Starten, Beenden und Anhalten von Services
• Zentrales Logging, um das Monitoring im Betrieb zu ermöglichen und zu erleichtern

Idealerweise gibt der Betrieb das Deployment nur noch frei und der Rest geschieht vollautomatisch. Nicht festgelegt werden sollten Implementierungsdetails, z. B. zu verwendende Technologien und Frameworks. Diese liegen im Verantwortungsbereich des Microservices-Teams.

Platform as a Service (PaaS)

Bei diesem Ansatz stellt der Betrieb den Microservice-Teams eine Hosting- und Managementplattform bereit. Diese gibt die meisten der im vorherigen Abschnitt genannten Kriterien explizit vor bzw. standardisiert diese. Das Operations-Team regelt nur Zugriffswege und Berechtigungen der einzelnen Teams sowie ggf. die dem Service zugewiesenen Ressourcen. Es führt auch kontinuierliches Plattform-Monitoring und Wartungsaufgaben durch (z. B. Einspielen von Plattform-Softwareupdates etc.). Alles weitere, darunter fällt insbesondere auch das Deployment, liegt in der Verantwortung des jeweiligen Microservice-Teams.

Ich persönlich finde diesen Ansatz am elegantesten, da er den beteiligten Personen Entscheidungen abnimmt, die Einhaltung grundlegender Regeln erzwingt und je nach Plattform stark auf Automatisierung ausgerichtet ist. Der Nachteil ist, dass man sich mit der Wahl einer Plattform zusätzlich einschränkt, deswegen sollte diese wohlüberlegt sein.

Beispiele für Microservice-PaaS sind Azure Service Fabric (auch on-premise einsetzbar), Docker als Containerization-Plattform und Kubernetes.

You Build it, You Run it

Dieser Ansatz geht am weitesten in Bezug auf die individuelle Verantwortung jedes einzelnen Microservice-Teams. Von außen gibt es keine konkreten Vorgaben hinsichtlich Betrieb der Microservices, sondern nur Empfehlungen. Das Team trifft alle Entscheidungen, wählt die Infrastruktur und/oder Plattform aus und ist selbst für das Hosting verantwortlich.

In großen Unternehmen mit vielen Microservices und großem Regulierungsdruck (Compliance) ist dieser Ansatz problematisch und schwer umsetzbar.

Fazit

Auf dem Weg hin zu Microservices DevOps müssen zunächst organisatorische Entscheidungen getroffen werden, die auf Automatisierung ausgerichtet sind. Dabei kann es sinnvoll sein, eine strikte Trennung zwischen Operations und Entwicklung aufzulösen. Am erfolgversprechendsten scheint die Verwendung von PaaS-Lösungen, bei dem sich der Betrieb auf die Bereitstellung der Microservices-Plattform beschränkt und alles weitere in der Verantwortung des jeweiligen Microservice-Teams liegt.