Vortrag auf der MicroXchg 2015

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:

• Kleine Systeme für große Architekturen
• Architekturprinzipien

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.