Von 2015 bis 2022 war "Microservices" das Lebenslauf-Buzzword der Wahl. Startups mit 5 Nutzern deploytes 20 Services ueber Kubernetes. Es war Komplexitaet um der Komplexitaet willen. Im Jahr 2026 hat sich das Pendel zurueckbewegt.
Die Falle des "Verteilten Monolithen"
Die meisten Unternehmen haben keine Microservices gebaut; sie haben einen verteilten Monolithen gebaut. Sie nahmen Funktionsaufrufe (die Nanosekunden dauern) und verwandelten sie in HTTP-Anfragen (die Millisekunden dauern) ueber ein instabiles Netzwerk.
Der "Ups"-Moment
"Wir verbrachten mehr Zeit mit dem Debuggen von Distributed Tracing und der Verwaltung von Terraform-State-Dateien als mit dem Bau von Produktfeatures." — Jeder CTO im Jahr 2024.
Der Modulare Monolith
Bei elitics.io setzen wir standardmaessig auf den Modularen Monolithen.
Einzelne Deployment-Einheit
Eine CI/CD-Pipeline. Eine Datenbank (logisch getrennt). Atomare Commits.
Strikte Grenzen
Code ist in Module organisiert (Abrechnung, Benutzer, Inventar), die ueber oeffentliche Schnittstellen interagieren, nicht ueber Hintertuer-SQL-Joins. Es erzwingt Disziplin ohne Netzwerklatenz.
Wann sollte man tatsaechlich aufteilen?
Wir extrahieren einen Service nur, wenn er ein deutlich anderes Skalierungsprofil hat.
// Guter Grund zum Aufteilen:
"Das Video-Transcoding-Modul frisst 100% CPU und crasht den API-Server." -> In Worker Service verschieben.
// Schlechter Grund zum Aufteilen:
"Wir wollen, dass das User-Profile-Team sein eigenes Repo hat." -> Verwenden Sie ein Monorepo.
Einfachheit skaliert besser als Komplexitaet. Bauen Sie nicht Googles Infrastruktur, es sei denn, Sie haben Googles Probleme (und Budget).
Hat Ihnen diese Perspektive gefallen? Teilen Sie sie mit Ihrem Team.