Monolith vs. Microservices Part 1:
Der Richtige Start ebnet den Weg zum Erfolg
„Monolith first“, „Don’t start with a monolith“ – eine Diskussion, die 2015 zu Beginn des Hypes um Microservices von Martin Fowler und Stefan Tilkov leidenschaftlich geführt wurden. Beide sind in der IT-Community anerkannte Autoren und Sprecher auf Konferenzen. Wir schreiben mittlerweile 2022. Ist der Diskurs mittlerweile gelöst?
Zusammenfassung
Wir richten uns mit dieser Blog-Serie an IT-Architekt:innen, Entwickler:innen und auch Product Owner, die sich im Vorfeld eines Projektes für eine Architektur entscheiden müssen. Es gibt selten die eine richtige Architektur. Jede Architektur hat in der Regel Vor- und Nachteile. In jedem Kontext werden aber die Vor- und Nachteile anders gewichtet. Es ist daher sinnvoll, sich anhand eines Kriterienkataloges zunächst zu überlegen, welche Ziele ich erreichen möchte und wie mich die gewählte Architektur bei jedem Ziel unterstützt. Für die Entscheidung, ob der Ansatz „Monolith first“ von Martin Fowler oder „Don’t start with a monolith“ von Stefan Tilkov, haben wir in einer Blogserie acht Kriterien definiert, die helfen können, für das eigene Projekt die richtige Wahl zu treffen. Um die Kriterien nicht nur in der Theorie zu erläutern, diskutieren zwei Protagonisten – die Gründer eines fiktiven Startups – ihre Position in jedem Kapitel. Natürlich vertritt eine Protagonist:in (Moni) den „Monolith first“-Ansatz und die zweite Protagonist:in (Michi) möchte sofort mit einer Microservice-Architektur starten.
Eine Architekturstrategie hängt immer von Kontext ab
Zu einer Frage können zwei herausragende Architekt:innen durchaus zwei unterschiedliche Antworten geben (siehe Diskurs zwischen Martin Fowler und Stefan Tilkov). In einem Projekt kann es ähnlich sein. Die eine Antwort gibt es in der Regel nicht. Meist gewichten die Architekt:innen nur Vor- und Nachteile unterschiedlich und kommen deswegen zu anderen Lösungsansätzen.
Die Entscheidung für eine Architekturstrategie hängt somit vom Kontext ab. Wir erläutern in dieser Blogserie deswegen die verschiedenen Kriterien für die Architekturentscheidung an einem fiktiven Beispiel.
Wir haben zwei Protagonist:innen: Moni und Michi. Beide haben sowohl Unternehmergeist als auch fundiertes IT-Know-how. Schon lange haben sie die Idee, eine neuartige Restaurantkette in ihrer Stadt aufzubauen. Alle Prozesse sollen von Beginn an digitalisiert sein. Reservierungen erfolgen über das Smartphone. Bereits bei der Bestellung wird der Aperitif geordert, der den Gästen beim Empfang serviert wird. Natürlich können die Menüs auch online bestellt und nach Hause geliefert werden. Die Abläufe in der Küche sind mit der Routenplanung des Fahrdienstes zu optimieren.
Beide sind überzeugt, dass ihr Geschäftsmodell ein Erfolg wird und sie bald in weitere Städte expandieren können. Die IT muss mit dieser Expansion mitwachsen können. Das Startkapital ist jedoch knapp. Das MVP (Minimum Viable Product) muss daher schnell umgesetzt werden, damit mit der ersten Restauranteröffnung das Geld für die Expansion eingenommen werden kann. Eine agile Entwicklung ist selbstverständlich. Man möchte natürlich das erste Feedback der Nutzer:innen sofort für die Verbesserung und Weiterentwicklung nutzen.
Überblick über die Blogserie
In den vergangenen sechs Jahren wurde in den Unternehmen viel Erfahrung bei der Entwicklung von Microservices gesammelt. Dogmatismus kann einer analytischen Fallbetrachtung weichen. Der richtige Architekturansatz ist von mehreren Faktoren abhängig.
In einer Blogserie möchten wir zehn Themenbereiche diskutieren, die vor einer Architekturentscheidung betrachtet werden sollten:
Teil 2/10 – Wer hat die bessere Performance?
Moni ist es wichtig, möglichst schnell das erste Restaurant zu eröffnen. Sie sieht Wettbewerbsvorteile und für Moni ist der Start mit einem Monolithen am Anfang auch aus diesem Grund die bessere Wahl.
Michi hat schon den langfristigen Ausbau im Blick und setzt von Anfang an auf eine solide, erweiterbare und serviceorientierte Architektur. Die Argumente für die eine oder andere Lösung diskutieren beide in Teil 2 „Monolith oder Microservices: wer hat die bessere Performance?“
Lies Teil 2 – Wer hat die bessere Performance?
Teil 3/10 – Der beste Trade-Off für das eigene Projekt
Michi macht sich auch schon konkret Gedanken, wie es nach dem MVP weitergehen kann: Unterschiedliche Teams, eindeutige Verantwortlichkeiten, unterschiedliche Geschwindigkeiten. Ist dies aber nicht auch mit einem Monolithen möglich? Bei welchem Ansatz ist der Aufwand für Schnittstellenabstimmung und Tests höher? Welcher Ansatz führt zu einer besseren Strukturierung? Was hat es mit der Abwärtskompatibilität bei Microservices auf sich? Dieser Fragen gehen Moni und Michi im zweiten Kapitel nach.
Lies Teil 3 – Der beste Trade-Off für das eigene Projekt
Teil 4/10 – Skalieren wie Netflix – Das richtige für mein Projekt
Bei der Betreibbarkeit machen sich beide Startup-Gründer Gedanken zur Skalierbarkeit und Verfügbarkeit. Microservices bringt man gerne mit horizontaler Skalierbarkeit zusammen. Aber haben IT-Anwendungen in der Praxis wirklich ein Skalierungsproblem, das nur mit Microservices gelöst werden kann? Bei der Verfügbarkeit können Microservices ihre Vorteile ausspielen, die jedoch mit einer höheren Komplexität gegenüber dem Monolithen erkauft werden.
Lies Teil 4 – Skalieren wie Netflix – Das richtige für mein Projekt
Teil 5/10 – Optimale Lösung ohne Kompromisse vs. „Technologie-Zoo“
Natürlich diskutieren Moni und Michi, welcher Technologie-Stack für ihre Anwendung am besten geeignet ist. Michi kann als Vertreter der Microservice-Architektur darauf verweisen, dass für jeden Anwendungsfall der optimale Technologie-Stack zum Einsatz kommt. Zum Beispiel basiert ein Microservice auf einem klassischen JEE-Stack mit relationaler Datenbank. Ein anderer Service, der den Kund:innen Menüvorschläge präsentiert, wird mit Python entwickelt, um leichter KI-Bibliotheken einzubinden. Für die Routenoptimierung erfolgt die Programmierung in GO. Moni ist dagegen dieser Wildwuchs an unterschiedlichen Technologien und einzusetzenden Frameworks zu hoch. In diesem Kapitel werden die beiden Ansätze auf die Waagschale gelegt: Optimale Lösung ohne Kompromisse vs. „Technologie-Zoo“.
Lies Teil 5 – Optimale Lösung ohne Kompromisse v. „Technologie-Zoo“
Teil 6/10 – Was schützt vor einem (verteilten) Big Ball of Mud
Moni: „Wir müssen uns noch Gedanken über Design-Richtlinien machen und Qualitätsziele definieren.“
Michi: „Die Aufgabe übernehmen wir am besten gemeinsam. Es wird übergreifende Richtlinien und Ziele geben, aber auch spezifische für die Module beziehungsweise Services.“
Design-Richtlinien und Qualitätsziele wollen beide festlegen. Man könnte meinen, dass beide zum selben Ergebnis kommen und die grundlegende Architekturfrage hier weniger eine Rolle spielt. Gutes Design ist mit beiden Architekturansätzen möglich. Aber bei welchem Ansatz kann the bigger Ball of Mud entstehen? Die Unterscheidung zwischen Macro- und Micro-Architekturentscheidungen, wie sie bei den Independent Systems Architecture Principles genannt werden, helfen, die Design-Richtlinien zu kategorisieren. Übergreifende Entscheidungen sind auch in einer Microservice-Architektur von allen Teams einzuhalten. Ein Team hat aber bei den servicespezifischen Designentscheidungen mehr Freiheitsgrade. In Teil 6 wird erläutert, warum aber dennoch die alleinige Verwendung von Microservices nicht automatisch zu einem besseren Design führen muss. Oder um es mit Simon Brown zu sagen: „If you can’t build a well-structured monolith, what makes you think microservices is the answer?“
Lies Teil 6 – Was schützt vor einem (verteilten) Big Ball of Mud
Teil 7/10 – Was sagen die Entwickler:innen?
Wie blicken aber die Entwickler:innen auf eine mögliche Architekturentscheidung? Ist das Entwickeln, Testen und Debuggen bei einem Monolithen nicht einfacher? So sieht das Moni und plädiert deswegen weiterhin für den Monolithen. Michi gibt Moni für kleine Anwendungen recht, sieht aber die Vorteile von Microservice bei größeren Projekten. Fazit ist: Bei beiden Architekturen ist ein guter Schnitt der Module beziehungsweise der Services entscheidend.
Lies Teil 7 – Was sagen die Entwickler:innen?
Teil 8/10 – Monolith first, really?
In diesem Kapitel diskutieren Moni und Michi, wie denn nun der Ansatz von Martin Fowler in der Praxis funktioniert. Fowler gibt vier Strategien vor:
- Software als Monolith, aber Schnittstellen und Persistenz bereits für eine Microservice-Architektur vorbereiten
- Mit Monolith starten und einfache, lose gekoppelte Teile heraustrennen
- Anwendung in Microservice-Architektur neu entwickeln
- Mit groben Services starten und diese teilweise und nach Bedarf zerlegen
Nach Tilkovs Sicht ist es aber in der Regel schwierig, existierende Monolithen nachträglich zu zerlegen. Er empfiehlt deswegen, zu analysieren, ob für einen Anwendungsfall ein Microservice Sinn macht, und diesen dann auch als Microservice zu implementieren.
Und wann machen nun Microservices Sinn? Hierauf gehen wir in Teil 8 ein. Skalierbarkeit, nicht-funktionale Anforderungen und Unabhängigkeit bei der Entwicklung und beim Deployment sind hierbei zu bewerten. Wenn man zu dem Schluss kommt, dass Microservices für den Anwendungsfall geeignet sind und der Nutzen den zusätzlichen Aufwand zum Meistern der Herausforderungen von verteilten Systemen übersteigt, dann sollte man auch von Anfang an auf Microservices setzen. Sollte ein Monolith für den Anwendungsfall ausreichen, so sollte auch ein Monolith gebaut werden.
Lies Teil 8 – Monolith first, really?
Teil 9/10 – Die Gretchenfrage: Konsistenz oder Verfügbarkeit?
Die Entscheidung, ob man sich für einen Monolithen oder für Microservices entscheidet, hat auch Einfluss auf die Geschäftsprozesse. Monolithen mit einer zentralen Datenbank erfüllen in der Regel für Transaktionen die ACID-Kriterien. ACID steht für englisch atomicity, consistency, isolation und durability. Die ACID-Kriterien stellen sicher, dass zu jedem Zeitpunkt die Daten konsistent in der Datenbank abgelegt sind. Eine Kundenbestellung in der Restaurant-App ist sofort in der Küche sichtbar und kann auch sofort bei der Routenplanung berücksichtigt werden.
Bei einer Microservices-Architektur hat jeder Service in der Regel seine eigene Datenablage. Der Austausch der Daten zwischen den Services und die übergreifende Konsistenz ist letztendlich durch Schnittstellen sichergestellt, aber die Konsistenz ist nicht sofort garantiert. Man spricht von Eventual Consistency. Es könnte also bei der Bestellung über die Restaurant-App passieren, dass ein angebotenes Menü nicht mehr zubereitet werden kann, da nicht mehr alle Zutaten verfügbar sind.
In Teil 9 wird die Problematik anhand des CAP-Theorems erläutert. Gemäß dem CAP-Theorem können in verteilten Systemen nur zwei der Eigenschaften Konsistenz, Verfügbarkeit und Partitionstoleranz eingehalten werden. Entscheidet man sich für Microservices mit einer verteilten Datenhaltung müssen Vorkehrungen im Geschäftsablauf getroffen werden, um mit Fehlern aufgrund von Inkonsistenzen umzugehen.
Lies Teil 9 – Die Gretchenfrage: Konsistenz oder Verfügbarkeit
Teil 10/10 – Start with a good design
Für Moni und Michi hat sich die intensive Beschäftigung mit der Architektur gelohnt. Sie konnten anhand des Themenkataloges die Vor- und Nachteile für ihr Geschäftsfeld gewichten und sind am Ende zu einer gemeinsamen Entscheidung gekommen. Die gewählte Architektur und die Gründe für diese Entscheidung erläutern wir in Teil 10.
Lies Teil 10 – Start with a good design
