Da wir uns bei der innoQ regelmäßig nicht nur in Projekten sondern auch auf Konferenzen und im Rahmen von Artikeln intensiv mit den Möglichkeiten zum Aufbrechen von Monolithen auseinandersetzen war der Talk Microservices - adaptive architectures and organisations von James Lewis eine willkommene Gelegenheit Einblicke in die Erfahrungen anderer zu dem Thema zu erhalten.
Ein anschauliches Beispiel für die Gefahren von Monolithen lieferte James u.a. mit einer war story von einer Fluggesellschaft, die im Anschluss an den Ausbruch des Vulkans Eyjafjallajökull keinerlei Flugstarts mehr abwickeln konnte. Jedoch nicht weil die Flüge von der über Europa hinwegziehenden Aschewolke betroffen waren sondern weil die Retail-Website (mit Fluginformationen) der Airline wesentlich stärker frequentiert wurde als üblich. Während der Zeit nach dem Vulkanausbruch wollten sich zahlreiche Passagiere über eventuelle Ausfälle oder Verschiebungen ihres Fluges informieren. Begünstigt durch ungeduldige User und den damit verbundenen Einsatz des Refresh Buttons geriet das System zunehmend unter Last. Da die Retail-Website und die für die Abwicklung von Flugstarts zuständige Departure Control als monolithisches System implementiert waren kam es schließlich zum Totalausfall.
Als Gegenentwurf zu Monolithen sind Microservices von überschaubarer Größe, lose gekoppelt, verwenden REST zur Kommunikation und können unabhängig voneinander skaliert und deployed werden. Die Frage nach der geeigneten Größe von Microservices wurde von James mit "so groß, dass sie in seinen Kopf passen" beantwortet und in einem Blog-Post vertieft.
Zusammengefasst übertragen Microservices die Unix-Philosophie auf den Bau von Systemen in Unternehmen:
- Write programs that do one thing and do it well
- Write programs to work together
- Write programs that handle text streams, because that is a universal interface
- With pipes many programs could work together, and they could work together at distance
Der aus meiner Sicht kritischste Punkt beim Versuch einen auf Microservices basierenden Systementwurf erfolgreich in die Tat umzusetzen ist Conway's Law (Melvin Conway, 1968):
…organizations which design systems … are constrained to produce designs which are copies of the communication structure of those organizations”
Die von James in diesem Zusammenhang aufgeworfene Empfehlung ist, Teams interdisziplinär unabhängig von bestehenden Strukturen um das zu entwickelnde Produkt herum zu organisieren. Je nach Unternehmen bedarf es dazu einiger Überzeugungsarbeit und eines gewissen Maßes an Unterstützung aus dem Management.
Abgesehen davon, dass die von James empfohlene Granularität von Microservices für meinen Geschmack etwas zu klein ausfällt findet der Talk meine uneingeschränkte Zustimmung. Dementsprechend würde ich mich im Zweifel zugunsten von Microservices und gegen einen Monolithen aussprechen.