Wie groß darf ein Microservice sein? Und ist das überhaupt wichtig?
Im ersten Artikel unserer Microservices-Serie haben wir die Bedeutung organisatorischer Komplexität für den Software-Entwicklungsprozess beleuchtet: komplexe Situationen erfordern flexible Reaktionen. Um das zu ermöglichen, muss die Architektur schnelle Feature-Entwicklung unterstützen. Genau hier setzt eine fachlich getriebene Microservice-Architektur an, indem sie große, monolithische Anwendungen in möglichst kleine, übersichtliche und fachlich unabhängige Microservices aufteilt. Wie groß oder klein soll oder darf ein solcher Service denn nun sein? Die Debatten zum Wort "micro" im Kontext von Microservices haben schon vor Jahren eine Eigendynamik entwickelt. Martin Fowler zeigte in seinem Talk auf der GOTO2014 [1] die Bandbreite der Diskussion auf, kann aber kein klares Größenkriterium benennen. In Teil 2 unserer Microservices-Serie nehmen wir uns dieser Frage an.
Size does matter: kleine Einheiten sind flink
Sam Newman gibt vor: "Small, and Focused on Doing One Thing Well" [2]. Etwas differenzierter ausgedrückt, sollte sich die Service-Größe einerseits an einem in sich abgeschlossenen Geschäftszweck und andererseits an den Möglichkeiten eines kleinen Umsetzungsteams orientieren.
Auch wenn aufgrund der geforderten fachlichen Abgeschlossenheit "micro" kein absolut festlegbares Maß ist: Die geringe Größe von Software und Team mit deren niedrigerem Organisationsaufwand ist der wesentliche verbindende Aspekt. Laut Amazon ist die richtige Größe gerade erreicht, wenn zwei (amerikanische, also große!) Pizzen zur Team-Fütterung ausreichen.
Auch andere Veröffentlichungen zu Microservices betonen den starken Fokus auf Organisation und Technologie: Beispielsweise liefert der Architekturspicker prägnante Anhaltspunkte mittels organisatorischer, methodischer und technischer Prinzipien [3]. Die Bestandsaufnahmen von Eberhard Wolff zum Thema Microservices heben die Dekomposition in kleine kommunizierende Einheiten, die technische Unabhängigkeit und bessere Evolution der kleineren Einheiten hervor [4]. Wie bei anderen Aufgaben im Software-Design sind auch hier letztlich die beiden wesentlichen Treiber:
- Hohe Kohäsion ("Bindung") innerhalb eines Microservice
- Lose Koppelung zwischen Microservices über möglichst wenige, "dünne" Schnittstellen
Dabei ist vor allem wichtig, die Granularität der Microservices nicht zu fein zu wählen, da dies Abhängigkeiten zwischen Microservices ungewollt vergrößert und damit die Kohäsion zerstört. Die technisch-betriebliche Unabhängigkeit ist ebenfalls notwendig, reicht aber nicht aus. Fachliche Entkopplung bedeutet fachliche Eigenständigkeit des einzelnen Microservice. Das unterscheidet Microservices von technisch getriebenen Services. Den Unterschied zwischen einem fachlichen Microservice und einem technischen Service verdeutlicht die Frage, wie sich Änderungen auswirken:
- Erfordern inhaltliche Änderungen in der Regel Schnittstellenanpassungen an Nachbarsystemen, dann handelt es sich wohl nicht um einen fachlichen Microservice.
- Schlägt die Änderung von Qualitätsanforderungen wie beispielsweise eine höhere Last auf den Service auf die Nachbarsysteme durch, dann ist ebenfalls keine Eigenständigkeit zu erkennen.
Nicht auf der grünen Wiese: Leistungsgrenzen sind der Auslöser
Eine Reihe von Firmen wie Netflix, Zalando, Amazon, Spotify, Kühne + Nagel oder Otto hat für sich erfolgreich eine Microservice-Architektur eingeführt [5]. So zeigt Otto mit der gleichbleibend niedrigen Fehleranzahl, dass der Wechsel auf die neue Microservice-Architektur keine Qualitätsprobleme verursacht hat [6], s. Abb. 1 – Fehlerzahl als rote Linie, während gleichzeitig die Anzahl Deployments deutlich steigt (schwarze Linie).
Von den genannten Firmen ist zu lesen und zu hören, dass sie mit ihren ursprünglich zentralistischen, monolithischen Architekturen sowohl technisch (Leistungsfähigkeit wie Performance, Durchsatz) als auch organisatorisch (Entwicklungsdauer) an ihre Skalierungsgrenzen geraten waren: Änderungen waren langwierig und aufwändig.
Daran anschließende Dezentralisierungsmaßnahmen haben eine Microservice-Architektur ermöglicht. Die Wege dahin waren oder sind – eventuell aufgrund der Unternehmensgröße und -kultur – unterschiedlich: So führte Netflix eine Migration der bestehenden Landschaft durch und begann damit bei den sowieso im Hintergrund laufenden Batch-Jobs. Dagegen hat Otto die Neuentwicklung seines Online-Shops zum Anlass für den Wechsel auf Microservices genommen.
Martin Lehmann auf den IT-Tagen 2018
Martin Lehmann hält zwei Vorträge auf den diesjährigen IT-Tagen – der Jahreskonferenz der Informatik Aktuell.
Alle (halbe) Jahre wieder kommt das neue Java-Release!
(11.12.2018, 09:00 Uhr)
Modularity-Patterns mit dem Java-Modulsystem Jigsaw
(12.12.2018, 11:30 Uhr)
Alles geht vom Team aus
Sämtliche Berichte enthalten Hinweise auf die organisatorischen Voraussetzungen, die Microservices zum Erfolg führen: Jedes Microservice-Team soll eigenverantwortlich und unabhängig arbeiten.
Spotify nennt es "having the freedom to act independently" [5]. Zalando beschreibt eine "Radical Agility", bestehend aus den drei Prinzipien Autonomy, Purpose und Mastery [5]. Sogenannte Delivery Leads bilden die Schnittstelle zur Organisation [5]. In agilen Zeiten hört sich das heute eigentlich wie eine Selbstverständlichkeit an. Wer sich jedoch zig autonom agierende Teams vorstellt, ahnt die Herausforderungen, solch einen "Flohzirkus" zu steuern.
Doch nicht in jeder Organisation ist so eine Art von (Nicht-)Führung möglich. Geht’s auch ohne? Vermutlich nicht, ohne diese Art von Führung werden Microservices erfolglos bleiben: "Architecture does not solve organizational problems. If your organization is crap then there's nothing your architecture can do to fix those." [7]. Netflix rät deshalb: "Reconfigure teams to best support your architecture" [5].
Letztlich können wir diese Empfehlungen auf das seit 50 Jahren bekannte Conway’s Law zurückführen: "Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations." [8]
Von den Geschäftsprioritäten über die Organisation zur Architektur
Für das Netflix-Geschäft steht Innovation an allererster Stelle [5]. Die Microservice-Architektur mit über 500 Microservices muss daher in erster Linie diese Geschäftspriorität unterstützen (s. Abb. 2). Netflix‘ Priorisierung und die schiere Microservices-Anzahl der Netflix-Landschaft verdeutlichen bereits, dass die Netflix-Erfahrungen in erster Linie für Unternehmen der Größe von Netflix gelten. Kann man dennoch davon lernen?
In den genannten Berichten brechen Firmen ihre globalen Ziele von der strategischen auf die operative Ebene herunter. Nach übereinstimmender Aussage überlassen sie den einzelnen Teams größtmöglichen Gestaltungsspielraum. Im Gegensatz zu umfassenden technischen und methodischen Informationen – z. B. im Netflix-Blog – findet man leider nur spärliche Angaben darüber, wie die genannten Unternehmen vorgehen, wenn sie ihre fachlichen Features planen und herunterbrechen. Letztlich läuft es auf folgende Aspekte hinaus:
- Jedes Team arbeitet autonom und eigenverantwortlich.
- Jedes Team stimmt sich selbständig mit anderen Teams ab.
- Zur Autonomie jedes Teams gehört auch die eigenverantwortliche Entscheidung über Deployments. Häufiges Deployment ist erwünscht.
- Änderungen dürfen bestehende Schnittstellenverträge nicht brechen. Eine solche Schnittstellenstabilität wird beispielsweise mit Consumer Driven Contracts gewährleistet, den Tests aus Abnehmersicht [9]. Änderungen spielt man über eine neue Schnittstelle bzw. eine neue Schnittstellenversion aus, die alte Version lässt man nutzungsbezogen auslaufen: Sobald die Nutzer auf eine alte Schnittstelle nicht mehr zugreifen (erkennbar zum Beispiel im Monitoring), kann sie abgeschaltet werden. Das Unterstützen mehrerer Schnittstellenversionen ist eine Herausforderung für sich und dürfte autonomiebegrenzend wirken, weil ein Team sich im Zweifelsfall zwischen dem Aufwand für eine zusätzliche Version und dem abhängigen Deployment entscheiden muss.
Zusammenfassung
Halten wir also fest: Wichtige Treiber bei der Einführung von Microservices sind ein hoher Innovationsbedarf sowie der Leidensdruck bei Skalierung.
Der Leidensdruck durch Erreichen von technischen Leistungsgrenzen zwingt ab einer "gewissen" Größe von Anwendungen bzw. Anwendungslandschaften zur Dezentralisierung. Bei der Dezentralisierung sollte die Autonomie der Teams gewährleistet sein, um das Potential zur Reaktionsfähigkeit auszuspielen. Erst eine extreme, gerade auch betriebliche und organisatorische Dekomposition ermöglicht die schnelle Reaktionsfähigkeit – v. a. sinnvoll und benötigt für kurze Innovationszyklen. Dies muss mit den Geschäftsprioritäten in Einklang stehen oder gebracht werden.
Die geringe Größe eines Microservice ist letztlich sekundär. Wichtiger sind vielmehr Übersichtlichkeit von Microservices und ihren Abhängigkeiten – v. a. ihre fachliche Kohäsion, um eine einfache Handhabung durch ein kleines Team bei geringem Kommunikations- und Abstimmungsaufwand zu ermöglichen.
Es wäre sehr interessant zu erfahren, wie diese Vielzahl autonom arbeitender und gestaltender Teams am Ende ein Gesamtsystem produzieren, das die gewünschten Anforderungen insgesamt erfüllt. Geht das ganz ohne zentrale Lenkung? Reicht Vertrauen in jedes Einzelteam aus? Mit der Scrum-Sprechweise bleibt für uns also diese Frage offen: Wie viele Product Owner gibt es und wie arbeiten diese an der Gesamtlösung zusammen?
- Martin Fowler 2014: Microservices (Bandbreite der Diskussion: 15:30)
- Sam Newman, 2015: Building Microservices: Designing Fine-Grained Systems
- embarc-Architektur-Spicker Nr. 3, 2016: Microservices
- Eberhard Wolff, 2016: Microservices – eine Bestandsaufnahme
Eberhard Wolff, 2017: Microservices – der aktuelle Stand - Netflix: Josh Evans, 2016: Mastering Chaos - A Netflix Guide to Microservices (QCon 2016) (Reconfigure Teams: 51:14)
Ruslan Meshenberg, 2016: Microservices at Netflix Scale: Principles, Tradeoffs & Lessons Learned (GOTO 2016) (Innovation: 16:40)
Zalando: Rodrigue Schaefer, 2016: From monolith to microservices (microXchg 2016) (Radical Agility: 09:00; Delivery Leads: 33:00)
Amazon: Chris Munns, 2015: I Love APIs 2015: Microservices at Amazon
Spotify: Kevin Goldsmith, 2015: Microservices @Spotify (GOTO 2015) (freedom to act independently: 07:30), Folien
Kühne + Nagel: Björn Kimminich, 2016: From Monolith to Microservices
Otto: Informatik Aktuell – Guido Steinacker, 2015: Von Monolithen und Microservices - Guido Steinacker (Otto), 2016: Why Microservices? - A Completely Biased Summary of the Assets of Microservice Architectures
- Jimmy Bogard, 2016: Avoiding Microservice Megadisaster (Øredev Conference) (Organizational Problems: 40:17)
- Melvin E. Conway, 1968: How Do Committees Invent?
- Ian Robinson, 2008: Consumer-Driven Contracts: A Service Evolution Pattern
