Microservices sind nicht von Natur aus schlecht. Aber sie sind auch keine Lösung für alle Fälle. Tatsächlich können sie für viele Unternehmensanwendungen unnötige Komplexität erzeugen. In diesem Beitrag möchte ich Ihnen einen alternativen Architekturstil vorstellen: Self-contained Systems (SCS), ein Ansatz, der uns geholfen hat, grosse Unternehmenssysteme erfolgreich zu modernisieren – mit weniger Aufwand, weniger Abhängigkeiten und höherer Resilienz.
Ein kurzer Rückblick
Die Geschichte der Unternehmenssoftware-Architektur hat mehrere Wellen durchlaufen:
- Vor 2000: Das „wilde“ Zeitalter der Softwareentwicklung, oft Mainframes und COBOL in grossen Unternehmen.
- 2000 – 2010: Aufstieg der Monolithen, besonders in Java mit J2EE (heute Jakarta EE) und später Spring Framework, was viele erfolgreiche Greenfield-Projekte ermöglichte.
- Nach 2010: Inspiriert von Netflix wurden Microservices zum Schlagwort, oft missverstanden und falsch angewendet.
Microservices entstanden aus den Anforderungen massiv skalierender Plattformen wie Netflix. Aber wenn Sie nicht für Millionen gleichzeitiger Nutzer bauen, ist dieses Mass an architektonischer Komplexität oft nicht notwendig oder sogar unüberschaubar.
Das Problem sind nicht Monolithen, sondern der „Big Ball of Mud“
Wenn Menschen Monolithen kritisieren, meinen sie den Big Ball of Mud, ein System, das ohne klare Grenzen, starke Modularität oder wartbare Struktur gewachsen ist. Aber nicht alle Monolithen sind schlecht. Wie der Monolith des Architekten Jean Nouvel, gefüllt mit schöner Kunst, kann ein gut strukturierter Monolith elegant sein. Der Schlüssel ist Modularität.
Schon 1972 betonte David Parnas den Wert der Modularität. Und das gilt bis heute, egal ob man Monolithen, Microservices oder etwas dazwischen baut.
Der Mythos von „Micro“
Der Name „Microservices“ ist irreführend. Bei Netflix sind Microservices ziemlich gross. Die eigentliche Idee ist, Ihr System in unabhängige, klar definierte Komponenten zu unterteilen, oft ausgerichtet an Bounded Contexts aus Domain-Driven Design (DDD).
In der Praxis gehen viele Unternehmen jedoch zu klein und zu schnell. Ich habe Teams von drei Personen gesehen, die versuchten, 20 Microservices zu warten, mit fragiler Inter-Service-Kommunikation, Kaskadeneffekten und Deploy-Problemen. Zu viele Services ohne ausreichende Ressourcen erhöhen die Komplexität, statt sie zu verringern.
Modularität vs. Verteilung
Hier die zentrale Erkenntnis:
- Modularität betrifft die Struktur.
- Verteilung betrifft das Deployment.
Sie können einen modularen Monolithen bauen, eine gut strukturierte, single-deployment Anwendung mit klaren Grenzen. Sie können auch einen verteilten Big Ball of Mud bauen – ein Albtraum in der Wartung. Verteilung bringt Komplexität: Netzwerkfehler, Latenz, Wiederholungen, eventual consistency, circuit breaker usw. Martin Fowlers erste Regel für verteiltes Design gilt weiterhin: „Verteilen Sie Ihre Objekte nicht.“
Kommunikationsaufwand
Microservices leiden oft unter Kommunikationsproblemen:
- Synchrone APIs (REST, GraphQL, gRPC) koppeln Services stark.
- Asynchrone Nachrichten (Kafka, JMS) reduzieren Kopplung, bringen aber Zustellungs- und Konsistenzprobleme.
- Ereignisgesteuerte Systeme können mächtig sein, aber nur, wenn Ihre Domäne passt.
Ich habe gesehen, wie Request-Reply-Nachrichten zu doppelten Lieferungen führten, weil das ERP-Backend nicht idempotent war. Und dann gibt es noch das N+1-Problem. Lazy-Loading über HTTP ist ein Desaster im Vergleich zu Lazy-Loading über JDBC.
Vorstellung von Self-Contained Systems (SCS)
Die Self-Contained Systems-Architektur (scs-architecture.org) wurde von InnoQ eingeführt und bietet ein anderes Modell. Jedes SCS ist:
- Ein vertikaler Ausschnitt Ihres Systems.
- Enthält UI, Business-Logik und Datenhaltung.
- Autonom: unabhängig entwickelt, getestet, deployed und betrieben.
- Kommuniziert nur bei Bedarf, idealerweise asynchron, oder über die UI selbst.
Denken Sie an Amazons Checkout-Prozess. Jeder Schritt von Warenkorb zu Versand zu Bezahlung fühlt sich leicht unterschiedlich an. Das ist kein Fehler, das ist Feature. Es sind separate Systeme, die nur über Links und Datenaustausch kommunizieren.
Warum SCS?
SCS geht nicht nur darum, Microservice-Fallen zu vermeiden. Es geht darum, die richtigen Grenzen und Kopplungen zu wählen und Systeme resilient, skalierbar und evolvierbar zu machen.
Hier die wichtigsten Unterschiede:
| SCS | Microservices | |
| Grösse und Umfang | Grösser, deckt komplette Geschäftsbereiche mit UI ab | Kleiner und Fokus auf einzelne Geschäftsprozesse ohne UI |
| Unabhängigkeit | Autonomer – jedes SCS hat eigene UI, Datenbank, Business-Logik | Hängt stärker voneinander ab, um einen Use Case zu implementieren |
| Integrationsstil | Integration über Links und asynchrone Nachrichten, ohne direkte API-Aufrufe | Synchrone API-Aufrufe und Service Discovery |
| Teamstruktur | Teams betreuen die gesamte vertikale Slice eigenständig | Teams müssen oft mehr koordinieren wegen Service-Abhängigkeiten |
| Benutzeroberfläche | Eigene UI enthalten | Keine UI-Verantwortung – meist nur Backend |
| Deployment | SCS kann vollständig unabhängig deployed werden | Abhängigkeiten können Orchestrierung erfordern |
Praxisbeispiel: Modernisierung eines ERP-Systems
Ich arbeite derzeit mit einem Grosshandelsunternehmen mit über 30 Cash-&-Carry-Märkten. Ihr ERP-System ist über 20 Jahre alt, gebaut mit Eclipse RCP und Java 8. Es ist ein Monolith: stark gekoppelt, schwer zu deployen und unmöglich zu aktualisieren, ohne alles zu beeinflussen.
Wir migrieren es zu einer Menge SCS:
- Jedes SCS hat eine eigene Vaadin-basierte UI, Spring Boot Backend und Oracle-Schema.
- Read-Only-Daten werden zwischen den Systemen repliziert, um den Zugriff auf Stammdaten zu entkoppeln.
- Die Kommunikation erfolgt überwiegend über UI-Links. Zum Beispiel nutzt die Navigation von Lager zu Vertrieb ein internes Register und Metadaten zur Steuerung.
- SSO verbindet alles, sodass Nutzer die Trennung nicht bemerken.
- Ein Designsystem mit gemeinsamen Komponenten sorgt für ein einheitliches Erscheinungsbild.
Das Ergebnis? Teams können ihre Systeme unabhängig weiterentwickeln. Wir vermeiden komplexe Synchronisationsprobleme. Und am besten: Wir vermeiden die Falle des Big-Bang-Rewrites.
Wann SCS Sinn macht
SCS funktioniert am besten, wenn:
- Ihre Domäne klar in Bounded Contexts aufgeteilt werden kann.
- Sie Team-Autonomie wünschen.
- Sie lose Kopplung und unabhängige Weiterentwicklung schätzen.
Es ist nicht immer die richtige Wahl, aber oft die bessere, besonders für Unternehmensanwendungen.
Konklusio
SCS ist keine Allzwecklösung, aber ein pragmatischer und erprobter Architekturstil, der Ihre Systeme wartbarer, robuster und zukunftssicher macht.
Es geht darum, Dinge einfach zu halten, Abhängigkeiten zu reduzieren und langfristige Evolution zu ermöglichen.
Auf Wiedersehen, Microservices-Hype. Hallo, Realität der Self-contained Systems.
Quellen
- Self-contained Systems, https://scs-architecture.org
- Mein Vortrag bei den Voxxed Days Bukarest:
