Vortrag auf der MicroXchg 2015: „Gibt es etwas zwischen Microservices und monolithischen Architekturen?“

Trichter zur schnellen Validierung von Ideen

Abstract: „Der Trend zu Microservices in komplexen Systemumgebungen ist die architektonische Antwort auf agile Softwareentwicklung und Continuous Delivery. Kleine Systeme, die unabhängig voneinander entwickelt und separat betrieben werden können – eine Architektur als Enabler für das Business. Den Vorteilen gegenüber stehen aber die klassischen Herausforderungen der Integration. Wie sehen Integrationstests aus, wie kann der übergreifende Betrieb sichergestellt werden und wie werden fachliche Abhängigkeiten behandelt? In diesem Vortrag werde ich anhand der neuen E-Commerce Plattform von OTTO aufzeigen, wie wir den Monolithen Otto.de in vertikale Systeme aufgeteilt und dadurch ein agiles Arbeitsumfeld ermöglicht haben. Besonders für die organisatorischen Konsequenzen werde ich Lösungsansätze mit ihren Vor- und Nachteilen vorstellen. Klassische Querschnittsaspekte wie Tracking, Performance und Security haben wir in die Architektur integriert und diese damit im Laufe der Zeit kontinuierlich weiterentwickelt.“

Die MicroXchg Konferenz am 12./13. Feb. 2015 in Berlin war die erste exklusive Konferenz zum Thema Microservices. In zwei parallelen Tracks gab es verschiedene Vorträge zum Thema Microservices – national und international, aus Anwender- und Beraterperspektive, von Microservice-Pionieren und Kritikern. Dieser Artikel fasst die wesentlichen Aussagen meines Vortrags zusammen und reflektiert die Reise der Otto.de Architektur von einem klassischen Monolithen zu einer verteilten Architektur mit Microservices.

Gibt es etwas zwischen Microservices und monolithischen Architekturen? Die Antwort lautet natürlich: JA. Aber warum? Dazu blicken wir zurück ins Jahr 2011, als wir uns entschlossen haben, den Online-Shop Otto.de neu zu entwickeln. Eine agile Vorgehensweise, die Nutzung von Open-Source Technologien und eine leichtgewichtige Architektur waren die Kernziele dieses Projekts. Im Ergebnis haben wir nicht den monolithischen Shop neu entwickelt, sondern uns entschlossen, das System nach Geschäftsdomänen vertikal zu schneiden und in kleinere Systeme zu zerlegen – mehr Informationen dazu in den folgenden Beiträgen:

Nach meinen Recherchen, die keinen Anspruch auf Vollständigkeit haben, gibt es die ersten Artikel und Vorträge mit dem Begriff „Microservices“ seit Anfang 2014. Falls ihr Beiträge findet, die älter sind, gerne als Kommentar zu diesem Artikel posten. Aber genau aus diesem Grund ist die Antwort: JA. Wir nennen unsere Architektur „Vertikale Systemarchitektur“ und die Systeme „Vertikale“. Doch welche inhaltliche Antwort gibt es auf die Frage „…etwas dazwischen…“. Dazu möchte ich folgende inhaltliche Gegensätze zwischen Monolithen und Microservices anführen:

  • langsam vs. schnell
  • statisch vs. dynamisch
  • unbeweglich vs. beweglich
  • fehleranfällig vs. resilient
  • riskant vs. non-event
  • abhängig vs. unabhängig

Was ist die Definition für ein Microservice? Dazu gab es auf der Konferenz unterschiedliche Antworten. Ich habe einen Kollegen zitiert:

„Ein Microservice ist etwas, was ein Entwickler in seiner Gesamtheit verstehen kann.“

Monolithen, Microservices oder etwas dazwischen? Welche Architektur ist die Richtige? Keine Architektur darf zum Selbstzweck existieren. Klare Ziele sind Voraussetzung für die Wahl der passenden Architektur. Neben den bereits genannten Zielen fokussieren wir vor allem auf Time To Market. Wie lange dauert es, eine Idee in fertige Software zu überführen? Gute Indizien zur Leistungsfähigkeit in diesem Bereich sind folgende KPI’s:

  • Wie lange dauert es, eine Kommentarzeile Code auf das Live-System zu deployen?
  • TTFD (Time To First Deploy): Wie lange braucht ein neues Teammitglied, um seine ersten Änderungen in Produktion zu deployen?

Falls klare Ziele fehlen, empfehle ich einen Blick in den „DevOps Report 2014“. Hier wird auf Basis von Umfragen in internationalen Firmen eine Korrelation zwischen der Anwendung von DevOps Praktiken und dem wirtschaftlichen Erfolg von Unternehmen hergestellt. Demnach zeichnen sich erfolgreiche IT-Organisationen dadurch aus, dass sie in folgenden Metriken besser sind als die Konkurrenz:

  • Lead Time for changes
  • Number of Deployments
  • Mean Time To Recover (MTTR)

Diese Ziele lassen sich aber nur erreichen, wenn die Architektur die genannten Eigenschaften von Microservices aufweisen. Wenn das allerdings so offensichtlich ist, habe ich zwei Leitfragen formuliert, die sich durch den Vortrag ziehen:

  • Warum sind in den letzten Jahren eher Monolithen entstanden?
  • Was war zuerst da – der Monolith oder der Wasserfall?

Ich glaube, dass die Antwort auf die erste Frage etwas mit Overhead beim Aufsetzen neuer Systeme zu hat. Folgende Aussage habe ich schon häufig gehört:

„Wenn wir das Projekt als Microservice oder separates System und nicht in das bestehende System bauen, kostet das x PT und y € Infrastruktur mehr und erzeugt mehr Abhängigkeiten.“

Dieser Umstand und ein mangelndes Bewusstsein für Conway’s Law haben in den letzten Jahren dazu geführt, dass Systeme immer größer geworden sind. Damit haben diese Systeme in sich bereits hohe Abhängigkeiten und sind weiterhin eng an andere große Systeme gekoppelt. Da Änderungen an diesen Systemen immer aufwändiger werden und die Sicherheit verloren geht, schnell Änderungen ohne Seiteneffekte in Produktion zu nehmen, entstehen Wasserfall-Prozesse in der Konzeption von Anforderungen und beim Testen der Umsetzungen.

Klassischer Wasserfallprozess
Klassischer Wasserfallprozess

Zwischen diesen Schritten entstehen Quality Gates, Checklisten, Übergabedokumente und Abstimmungen, die zu langen Entwicklungsprozessen und damit einer schlechten Time To Market führen. Die Otto.de Architektur skaliert sowohl organisatorisch als auch technisch horizontal. Doch im Laufe der letzten 1,5 Jahre haben wir neue Herausforderungen identifiziert, die eine Ergänzung der Architektur um Microservices erforderlich gemacht haben. Der Zulauf von Anforderungen, die Priorisierung von Projekten und das Umsetzen strategischer Initiativen erzeugen Hot Spots in der Organisation und haben damit Konsequenzen auf die Architektur.

Der Fokus auf bestimmte Themen und Projekte führt zu einer ungleichen Auslastung der Teams
Der Fokus auf bestimmte Themen und Projekte führt zu einer ungleichen Auslastung der Teams (oranger Kasten)
Strategische Initiativen wie die Umstellung auf Responsive Webdesign erzeugen an anderen Stellen Engpässe
Strategische Initiativen wie die Umstellung auf Responsive Webdesign erzeugen an anderen Stellen Engpässe (roter Kasten)

Die Vertikalen sind mittlerweile auch größer geworden und laufen irgendwann Gefahr, die positiven Eigenschaften zu verlieren. Daher haben wir uns vor einer Weile entschieden, die vertikale Architektur durch Microservices zu ergänzen. Im dem Beitrag „Scaling with Microservices and Vertical Decomposition“ könnt ihr weitere Details dazu lesen. Doch bei der Einführung von Microservices gelangt man immer wieder an neue Hürden, die die Umsetzung eines Features als Microservice aufwändiger werden lassen als das Feature in ein bestehendes System einzubauen. Daher empfehle ich 2 Strategien für die Umsetzung:

  1. Das Ziel einer Microservice-Architektur muss in der Organisation verankert sein. Dann kann in jedem Sprint, bei jeder Anforderung und bei jedem Projekt ein Beitrag zu diesem Ziel geleistet werden. Eine enge Zusammenarbeit mit Operations (Devops) ist kritisch für den Erfolg.
  2. Das schnelle Aufsetzen kleiner Teams zur Umsetzung von neuen Themen oder Prototypen führt durch Conway’s Law zu kleinen neuen Systemen, die meist einen sehr spitzen fachlichen Fokus haben. Dies ist besonders für Themen geeignet, bei denen das Potenzial noch unklar ist. Falls sich die Themen als wenig wertvoll erweisen, können diese Systeme auch schnell wieder abgeschaltet werden.
Trichter zur schnellen Validierung von Ideen
Trichter zur schnellen Validierung von Ideen

Auf diese Weise entstehen viele wertvolle Lösungen, die sich zu Standards der Plattform entwickeln. Gerade die Integration in die Plattform ist für einen Online-Shop wie Otto.de essentiell, da viele hohe nicht-funktionale und betriebliche Anforderungen existieren. Beispiele für solche Lösungen sind unser Open Source Projekt tesla-microservice, das eine Basis für Otto.de Microservices in Clojure bietet und das Projekt edison-microservice für unsere Microservices auf Basis von Spring Boot. Zusammenfassend kann man sagen, dass im Operativen immer wieder Hürden existieren, eine Architektur so konsequent umzusetzen. Um jedoch die o.g. Ziele zu erreichen und zukünftige Herausforderungen mit einer flexiblen Skalierbarkeit sowohl in der Infrastruktur als auch in der Organisation zu erreichen, ist diese Konsequenz absolut notwendig.

„Es gibt 100 gute Gründe, keinen Microservice zu bauen, aber es gibt noch viel mehr Gründe, keine neuen Monolithen aufzubauen.“

Daher verfolgen wir bei Otto.de die Vision:

Das Aufsetzen neuer Systeme ist ein Standard der Plattform, der eigenständig und voll automatisiert von den Featureteams durchgeführt werden kann.