Monolith ist kein Schimpfwort. Und Microservices sind kein Allheilmittel.
Monolith¶
- Einfache Entwicklung und Deployment
- Keine Netzwerk-Latenz zwischen Services
- Einfaches Debugging
- Eine Datenbank, einfache Transaktionen
- Skaliert als Ganzes
- Ein Team, ein Deploy
- Technologisch homogen
Microservices¶
- Unabhaengiges Deployment
- Skalierung pro Service
- Technologische Vielfalt
- Fehler-Isolation
- Komplexitaet verteilter Systeme
- Netzwerk-Latenz
- Verteilte Transaktionen
- DevOps-Reife erforderlich
Wann Monolith¶
- Kleines Team (<10 Entwickler)
- Fruehphasen-Startup
- Unklare Domain-Grenzen
- Schnell ausliefern wollen
Wann Microservices¶
- Grosses Team (>20 Entwickler)
- Klare Domain-Grenzen
- Unabhaengiges Deployment erforderlich
- Unterschiedliche Skalierungsanforderungen pro Service
Modularer Monolith – das Beste aus beiden Welten¶
Monolith mit klaren Modulen/Bounded Contexts. Sie koennen ihn spaeter in Microservices aufteilen, wenn noetig.
Regel¶
Starten Sie mit einem Monolithen. Teilen Sie auf, wenn es schmerzt (nicht vorher). Microservices sind kein Ziel – sie sind eine Loesung fuer ein spezifisches Problem.
Architekturmicroservicesmonolith