Microservices: "Ohne Automatisierung und DevOps ist ein Scheitern vorprogrammiert"

  • Erstellt von DOAG Online
  • Methodik & Architektur

In den letzten Jahren haben sich Microservices in der modernen Softwarearchitektur einen Namen gemacht. Dabei werden Dienste aus einem großen, monolithischen Anwendungssystem abgekapselt und können unabhängig voneinander verwaltet werden. So liefern Microservices eine erhöhte Flexibilität und Agilität. Der Experte Carsten Wiesbaum verrät im Interview mit DOAG Online mehr über Microservices, ihre Anwendungsbereiche und kulturelle, technische aber auch organisatorische Risiken. Diese Thematik wird er auch im Expertenseminar "Microservices in der Praxis" am 23. und 24. Mai in Berlin behandeln. 

1. Was genau sind Microservices und wofür sind sie sinnvoll?
Microservices beschreibt zumeist einen Softwarearchitekturansatz, durch den sich große und komplexe Systeme in eine Anzahl von kleinen und autonomen Serviceapplikationen (Microservice) zerlegen lässt. Jeder Microservice selbst ist eine eigenständige Applikation, die einen fachlichen Bereich des Gesamtsystems umsetzt. Mit der Aufteilung des Gesamtsystems in kleine isolierte Services, wird primär versucht, die Komplexität einer auslieferbaren Einheit möglichst gering zu halten. Das Ziel soll sein, dass ein Entwicklerteam die autonomen Serviceapplikationen in Gänze verstehen, betreuen und zur Not neu implementieren kann.

2. Welchen Herausforderungen müssen sich Unternehmen stellen, die zu einem System mit
Microservices wechseln? Welche Rolle spielen DevOps, Continuous Delivery und Cloud dabei?
Das kommt natürlich stark auf das jeweilige Unternehmen und seine Adaption bezüglich moderner Techniken der Softwareentwicklung an. Fakt ist, dass durch die Lösung eines großen und komplexen Problems mit Hilfe der Implementation vieler Microservices die einzelnen Services zwar simpler und einfacher zu verstehen sind, der Betrieb eines solchen Schwarms jedoch sehr komplex werden kann. Ohne einen hohen Grad an Automatisierung (Auslieferung sowie Tests) und eine etablierte und gelebte DevOps-Kultur, ist ein Scheitern vorprogrammiert. Moderne Techniken und Methodiken in den Bereichen DevOps, Continuous Delivery und Cloud sind daher ganz klar das, was eine erfolgreiche Microservice-Strategie erst ermöglicht.

3. Welche Anforderungen und Best Practices an gute Microservice-Architekturen gibt es?

Betrachtet man das Thema Microservices, gibt es viele gute Leitfäden. Einen Überblick über erstrebenswerte Charakteristiken gab Martin Fowler bereits 2014 in seinem Artikel “Microservices, a definition of this new architectural term”. Darunter befinden sich technische Punkte wie der Betrieb von Microservices in einem eigenen Prozessraum, intelligente Endpunkte und dumme Integrationsstrecken, dezentralisiertes Datenmanagement. Auch sollte bei der Entwicklung auf hohe Fehlertoleranz geachtet werden. Von einer technischen Sichtweise sind sicherlich auch die Prinzipien der “Twelve Factor App” erstrebenswert. Hier finden sich auch einige Überschneidungen zu den gängigen Microservice-Prinzipien. Was viele , gerade technisch fokussierte Spezialisten, gerne vergessen ist jedoch, dass Microservices nicht nur ein reiner Architekturstil ist. Neben den stark technisch orientierten Gesichtspunkten, setzt die erfolgreiche Umsetzung auch viele Punkte hinsichtlich der Firmenstruktur, Teamzusammensetzung und Rollenverteilung voraus. Gerade diese Aspekte sind meiner Meinung nach die wichtigsten Punkte.

4. Im Expertenseminar behandeln Sie auch den Zusammenhang zwischen Microservices und kulturellem Wandel? Wieso ist dieser so bedeutsam?

Nach meiner Erfahrung scheitern Projekte und Produktentwicklungen selten auf Grund der gewählten Technologie. Mit dem richtigen Team und Know-how kann jedes Problem mit jeder Technologie gelöst werden. Eine nicht optimale Wahl kann natürlich Probleme in der Entwicklung und dem späteren Betrieb hervorrufen, aber irgendwie bekommt man Anforderungen immer umgesetzt. Viel häufiger sind die Ursachen für das Scheitern von Projekten methodische und menschliche Herausforderungen sowie Fehler. Innerhalb der Microservice-Methodik, ich nenne sie an dieser Stelle bewusst so, gibt es neben vielen technischen Aspekten auch organisatorische Empfehlungen. So sollen einzelne Microservices als Produkte und nicht als Projekte eines Teams angesehen werden. Ganz nach dem Prinzip “You build it, you run it” ist ein Team nicht mehr nur noch für die Entwicklung von etwas das zur Deadline übergeben werden muss zuständig, sondern auch für den anschließenden Betrieb. Durch diese Fokusänderung entsteht allein schon eine ganz andere Motivation und ein DevOps-Gedanke, denn Entwickler werden alles dafür tun, damit das entstehende Produkt nachher gut und mit möglichst wenig Aufwand zu betreiben ist. Wenn ich den Produktteams jedoch diese Rolle gebe, sollten sie auch selbst über die verwendeten Technologien entscheiden können, was ein weiterer wichtiger Punkt des Kulturwandels darstellt. Viele Spezialisten sowie Entscheider vergessen diese Aspekte der Microservice-Methodik leider und erzeugen dadurch starke und unnötige Reibungspunkte bei der Umsetzung einer Microservice-Strategie. Genau deshalb ist es mir wichtig, diese Punkte innerhalb des Expertenseminars anzusprechen.