Der Microservice Trade-Off für JUG (60min Version)

Microservices sind irgendwie toll, das weiß ja inzwischen jeder. Aber vielen ist nicht bewusst,
dass man für diesen Architekturansatz auch einen Preis zahlt, der sich nicht immer lohnt.
Eines der schwierigsten Probleme in der Softwarearchitektur ist das Finden geeigneter
Schnitte zwischen Deploymenteinheiten verteilter Systeme ("Services"). Missverständnisse
und Fehlannahmen zu Architekturparadigmen wie "Microservices" führen immer wieder zu
schlechten Entscheidungen über Software-Schnitte, die schwer umzukehren sind und
schlechte Auswirkungen auf die Weiterentwicklung und Nachhaltigkeit eines Systems haben
können.
In diesem Talk werde ich versuchen, die verschiedenen Seiten des Trade-Off eines
Softwareschnitts zu beleuchten und so nah wie möglich an konkrete Lösungen für dieses
komplizierte "It depends" Problem zu kommen. Welche Probleme hole ich mir mit einem
Softwareschnitt ins Boot? Wann kann ich davon profitieren? Was sind weit verbreitete
Missverständnisse über Microservice Architektur? Welche Methoden und Heuristiken können
uns helfen, die richtige Entscheidung zu treffen? Wie hilft uns der modulithische Ansatz an
den Stellen, an denen ein Schnitt keinen Sinn macht? In welchen Situationen stehen wir vor
einer solchen Entscheidung und wie gehen wir sie an?
Neben Erkenntnissen aus Domain Driven Design und Team Topologies sowie Elementen der
Architekturansätze Microservices und Modulith enthält dieser Talk eine Menge real-life
Erfahrung aus Projekten mit verteilten Systemen. Der Talk wird die Zuhörer befähigen, bei
anstehenden Architekturentscheidungen die Schnitte ihrer Software besser abgewägt und
nachhaltiger zu wählen.

Transcript

1. Der Microservice Trade-Off
2. Software Engineer & Consultant Arnold Franke https://chaos.social/@indyarni https://www.linkedin.com/in/arnold-franke/ https://synyx.de/
6. Der Microservice Hype
7. Microservices sind super cool!
8. Microservices sind super cool!
9. • Unabhängig voneinander deployen • Unabhängig voneinander skalieren • Technologieunabhängigkeit untereinander • Unabhängig voneinander in verschiedenen Teams entwickeln • Resilienz und Fehlerisolierung • Leichte Ersetzbarkeit • Modularisierung – geringe Kopplung, hohe Kohäsion • Kleine, gekapselte Teile mit niedriger Komplexität • Einfach wartbar, leicht erweiterbar • Klare Abhängigkeiten mit expliziten APIs • Geringes Risiko für unerwartete Seiteneffekte • Architekturregeln enforcen • Können containerisiert werden • Einfache CI/CD Microservices sind super cool! Was versprechen Microservices?
10. • Unabhängig voneinander deployen • Unabhängig voneinander skalieren • Technologieunabhängigkeit untereinander • Unabhängig voneinander in verschiedenen Teams entwickeln • Resilienz und Fehlerisolierung • Leichte Ersetzbarkeit • Modularisierung – geringe Kopplung, hohe Kohäsion • Kleine, gekapselte Teile mit niedriger Komplexität • Einfach wartbar, leicht erweiterbar • Klare Abhängigkeiten mit expliziten APIs • Geringes Risiko für unerwartete Seiteneffekte • Architekturregeln enforcen • Können containerisiert werden • Einfache CI/CD Microservices sind super cool! Was versprechen Microservices?
11. • Unabhängig voneinander deployen • Unabhängig voneinander skalieren • Technologieunabhängigkeit untereinander • Unabhängig voneinander in verschiedenen Teams entwickeln • Resilienz und Fehlerisolierung • Leichte Ersetzbarkeit • Modularisierung – geringe Kopplung, hohe Kohäsion • Kleine, gekapselte Teile mit niedriger Komplexität • Einfach wartbar, leicht erweiterbar • Klare Abhängigkeiten mit expliziten APIs • Geringes Risiko für unerwartete Seiteneffekte • Architekturregeln enforcen • Können containerisiert werden • Einfache CI/CD Microservices sind … immer noch cool? Was versprechen Microservices? (das hier geht alles auch ohne Microservices)
12. • Unabhängig voneinander deployen • Unabhängig voneinander skalieren • Technologieunabhängigkeit untereinander • Unabhängig voneinander in verschiedenen Teams entwickeln • Resilienz und Fehlerisolierung • Leichte Ersetzbarkeit • Modularisierung – geringe Kopplung, hohe Kohäsion • Kleine, gekapselte Teile mit niedriger Komplexität • Einfach wartbar, leicht erweiterbar • Klare Abhängigkeiten mit expliziten APIs • Geringes Risiko für unerwartete Seiteneffekte • Architekturregeln enforcen • Können containerisiert werden • Einfache CI/CD Die eine Seite des Microservice Trade-Off Was versprechen Microservices? (das hier geht alles auch ohne Microservices) Potential von Microservices. Die mögliche „plus“ Seite des Trade-Off
13. Der Microservice Hype
14. Microservice Adoption Nginx 2020: O’Reilly 2020: Kong 2020:
15. Microservice Adoption Gartner 2023: Microservice Orchestration Research Paper 2021:
16. Microservice Adoption O’Reilly 2025:
17. Missverständnisse über Microservices
18. Verbreitete Missverständnisse über Microservices Missverständnisse
19. Verbreitete Missverständnisse über Microservices • Services müssen klein sein. Je kleiner desto besser. Missverständnisse
20. Verbreitete Missverständnisse über Microservices • Services müssen klein sein. Je kleiner desto besser. • Viele kleine Services sind einfacher zu warten/betreiben als ein großer Monolith Missverständnisse
21. Verbreitete Missverständnisse über Microservices • Services müssen klein sein. Je kleiner desto besser. • Viele kleine Services sind einfacher zu warten/betreiben als ein großer Service • Wenn wir gute „DevOps Automatismen“ haben, dann gibt es keinen Overhead durch mehr Microservices Missverständnisse
22. Verbreitete Missverständnisse über Microservices • Services müssen klein sein. Je kleiner desto besser. • Viele kleine Services sind einfacher zu warten/betreiben als ein großer Service • Wenn wir gute „DevOps Automatismen“ haben, dann gibt es keinen Overhead durch mehr Microservices • Microservices sind der beste Weg, seine Software zu modularisieren Missverständnisse
23. Verbreitete Missverständnisse über Microservices • Services müssen klein sein. Je kleiner desto besser. • Viele kleine Services sind einfacher zu warten/betreiben als ein großer Service • Wenn wir gute „DevOps Automatismen“ haben, dann gibt es keinen Overhead durch mehr Microservices • Microservices sind der beste Weg, seine Software zu modularisieren • Microservices lösen alle unsere Performance Probleme Missverständnisse
24. Verbreitete Missverständnisse über Microservices • Services müssen klein sein. Je kleiner desto besser. • Viele kleine Services sind einfacher zu warten/betreiben als ein großer Service • Wenn wir gute „DevOps Automatismen“ haben, dann gibt es keinen Overhead durch mehr Microservices • Microservices sind der beste Weg, seine Software zu modularisieren • Microservices lösen alle unsere Performance Probleme • Wir haben hier fünf Teams, also ist es am besten wir bauen fünf Services Missverständnisse
25. Microservices sind Doof!
26. Welche potentiellen Probleme und Risiken birgt ein Software Schnitt? Die andere Seite des Trade-Off
27. Welche potentiellen Probleme und Risiken birgt ein Service Schnitt? • Schnittstelle: Calls/Events übers Netzwerk statt innerhalb der Applikation – Protokolle (AMQP, MQTT, HTTP...) – Client/Server oder Publisher/Subscriber. Broker? Gateway? – Serialisierung/Deserialisierung – Komplizierteres Schnittstellendesign, Contract und Dokumentation – Neue Dimension an Problemen: Timeouts, Connection Probleme, Retries, Out-of-sequence delivery, At- least-once delivery, Error Handling … • Dadurch wird alles: – Langsamer – Fehleranfälliger – Aufwändiger zu bauen – Schwerer zu verstehen Die andere Seite des Trade-Off
28. Welche potentiellen Probleme und Risiken birgt ein Service Schnitt? • Build, Test und Deploy – Duplikation • Zwei Pipelines statt einer • Zweimal Testsysteme plus Infrastruktur • Zweimal die Anwendungsinfrastruktur wie z.B. Datenbanken • Zwei mal die ganze Komplexität mit Load Balancing, Instanzen, Ressourcenzuweisung, Zero-Downtime-Deployment… • Zwei Artefakte statt einem, zweimal releasen, Abhängigkeiten/Kompatibilität zwischen den Artefakten – Test Setup von integriertem Test komplexer Die andere Seite des Trade-Off
29. Welche potentiellen Probleme und Risiken birgt ein Service Schnitt? • In der Anwendung: – Duplikation • Zwei Anwendungen kon昀椀gurieren statt einer • Zwei mal dokumentieren • Updates von Dependencies an zwei Stellen statt einer – Cross cutting concerns wie Mandantenfähigkeit, Security, Monitoring, Tracing, Kon昀椀guration sind auf einmal verteilt und müssen konsistent gehalten werden – State an mehreren Stellen replizieren/synchronisieren • Im Team: – Cognitive Load des Teams steigt beträchtlich Die andere Seite des Trade-Off
30. Will man das jetzt immer noch? Die andere Seite des Trade-Off
31. Oder das? Die andere Seite des Trade-Off
32. Chancen und Probleme aus der echten Welt
33. Entwicklungsteam in der Verkehrsbranche Zustand: • Moderner Tech Stack und hoch automatisierte CI/CD Landschaft, hoch standardisierte Pipelines • Microservice Architektur mit ca. 15 Service mit mehreren Software-Artefakten pro Service • >50 Repos Auffällige Auswirkungen: • Eine Anpassung Mehrere Änderungen in mehreren Repos (manchmal in allen) → • Häu昀椀ge Probleme und Fehlschläge in der CI/CD Infrastruktur • Schwierig, den Überblick zu behalten. Cognitive Load hoch. • Nimmt Zeit und Fokus von Weiterentwicklung Beispiele für die Auswirkungen von Vorteilen und Nachteilen
34. Kundenstamm Team im Einzelhandel Situation: • Modulith, sauber strukturiert, sauberer Code • Viele Aspekte unterschiedlicher Domänen in einem Stück Software • Viele Module, die unterschiedliche Dinge tun in einem Stück Software Auffällige Auswirkungen: • Resilienzprobleme – kleine, kritische Teile nicht verfügbar, wenn es an anderer Stelle Probleme gab • Vermischung verschiedener fachlicher Domänen ungewollte Kopplung und Nebenwirkungen → • Schwierige Migration des Basisframeworks Beispiele für die Auswirkungen von Vorteilen und Nachteilen
35. Zwischenfazit
36. Es steckt viel Potential in einem Software-Schnitt Ein Schnitt ist aber ganz bestimmt nicht kostenlos und kein No-Brainer „It depends“ – es ist ein Trade-Off Zwischenfazit
37. ¯\_( ツ )_/¯ Zwischenfazit
38. Entscheidende Frage, um den Trade-Off zu bewerten: Welchen konkreten Vorteil bringt mir ein Schnitt in meiner Software, der die potentiellen Nachteile aufwiegt? Zwischenfazit
39. Heuristiken für Softwareschnitte
40. Heuristiken für Softwareschnitte – Business Domain „Align software and its boundaries to the business domain“ - Domain Driven Design
41. Heuristiken für Softwareschnitte – DDD
42. Heuristiken für Softwareschnitte – DDD
43. Heuristiken für Softwareschnitte – DDD
44. Heuristiken für Softwareschnitte – DDD
45. Heuristiken für Softwareschnitte – DDD
46. Heuristiken für Softwareschnitte – Fracture Planes Software Boundaries or „Fracture Planes“
47. Performance Isolation
48. Change Cadence
49. Heuristiken für Softwareschnitte – Team Topologies Fracture Planes Technology (existing or by choice)
50. Regulatory Compliance § Regulatory Compliance
51. Heuristiken für Softwareschnitte – Weitere Fracture Planes Criticality
52. Heuristiken für Softwareschnitte – Team Topologies Fracture Planes User Personas
53. Heuristiken für Softwareschnitte – Weitere Fracture Planes Replaceability
54. Longevity
55. Heuristiken für Softwareschnitte – Fracture Planes Common Fracture Planes • Regulatory Compliance • Performance Isolation • Technology (existing or by choice) • Criticality/Risk • User Personas • Replacability • Longevity • Change Cadence • Support Frequency • Security • ... • Individuelle Fracture Planes, die Aufwand, Komplexität oder Cognitive Load isolieren
56. Keine Heuristiken für Softwareschnitte
57. Keine Heuristiken für Softwareschnitte Größe (meistens)
58. Keine Heuristiken für Softwareschnitte Vorhandene Teamstruktur
59. Keine Heuristiken für Softwareschnitte „Gefühlte“ Performance Probleme
60. Implizite Nachteile vs. Vorteil durch Fracture Planes & Co. Trade-Off bewerten ?
61. Evolution einer Systemlandschaft
62. „Choosing Microservices 昀椀rst is dangerous. Choosing Monoliths for the long term is also dangerous." „Modules 昀椀rst, deployment last“ – Strategic Monoliths and Microservices • Keine Schnitte im Voraus planen, bis auf die völlig offensichtlichen • Mit einer Deploymenteinheit beginnen und erstmal Mehrwert liefern – deliver working Software! • Sich immer wieder fragen „Ist hier ein Schnitt sinnvoll? Welche Fracture Planes greifen hier? Lohnt sich der Trade-Off?“. • Innerhalb der Deploymenteinheit modularisieren, kapseln Modulithische Architektur → Evolution einer Systemlandschaft
63. "Choosing Microservices 昀椀rst is dangerous. Choosing Monoliths for the long term is also dangerous." „Modules 昀椀rst, deployment last“ – Strategic Monoliths and Microservices • Keine Schnitte im Voraus planen, bis auf die völlig offensichtlichen • Mit einer Deploymenteinheit beginnen und erstmal Mehrwert liefern – deliver working Software! • Sich immer wieder fragen „Ist hier ein Schnitt sinnvoll? Welche Fracture Planes greifen hier? Lohnt sich der Trade-Off?“. • Innerhalb der Deploymenteinheit modularisieren, kapseln Modulithische Architektur → Evolution einer Systemlandschaft
64. Modularer Monolith
65. • Unabhängig voneinander deployen • Unabhängig voneinander skalieren • Technologieunabhängigkeit untereinander • Unabhängig voneinander in verschiedenen Teams entwickeln • Resilienz und Fehlerisolierung • Leichte Ersetzbarkeit • Modularisierung – geringe Kopplung, hohe Kohäsion • Kleine, gekapselte Teile mit niedriger Komplexität • Einfach wartbar, leicht erweiterbar • Klare Abhängigkeiten mit expliziten APIs • Geringes Risiko für unerwartete Seiteneffekte • Architekturregeln enforcen • Können containerisiert werden • Einfache CI/CD Modularer Monolith Was versprechen Microservices? (das hier geht alles auch ohne Microservices)
66. • Unabhängig voneinander deployen • Unabhängig voneinander skalieren • Technologieunabhängigkeit untereinander • Unabhängig voneinander in verschiedenen Teams entwickeln • Resilienz und Fehlerisolierung • Leichte Ersetzbarkeit • Modularisierung – geringe Kopplung, hohe Kohäsion • Kleine, gekapselte Teile mit niedriger Komplexität • Einfach wartbar, leicht erweiterbar • Klare Abhängigkeiten mit expliziten APIs • Geringes Risiko für unerwartete Seiteneffekte • Architekturregeln enforcen • Können containerisiert werden • Einfache CI/CD Modularer Monolith Das liefern Microservices Das liefert ein Modulith
67. Evolution des Systems anhand agiler Architektur • Entscheidungen für/gegen Schnitte so spät wie sinnvoll möglich treffen. • Entscheidungen dokumentieren und vor allem gut begründen • Vergangene Entscheidungen bei Bedarf neu bewerten. Trägt die Begründung noch? • Die Architektur den aktuellen Anforderungen und Erkenntnissen anpassen Evolution einer Systemlandschaft
68. Wrap-Up
69. Legt euch nicht blind von vorne herein auf Microservices oder Monolithen fest! Start simple! Seid euch bei jedem Schnitt des Trade-Offs bewusst! Arbeitet agil – auch in der Architektur! Wrap-Up
70. Buchempfehlungen
72. LinkedIn