Wir führten Microservices ein, weil Netflix es tat. Wir waren vier Entwickler, die ein CRUD-Produkt bauten, das zum Launch etwa 50 täglich aktive Nutzer hatte. Wir waren nicht Netflix.

Warum wir sie wirklich gewählt haben

Jeder Grund auf unserer Liste war ein sozialer, kein architektonischer: „das macht man heute so“, die Konferenzvorträge ließen es unausweichlich wirken, und es machte sich gut im Lebenslauf. Die Fragen, die die Entscheidung hätten treiben sollen — haben Teile des Systems unabhängige Skalierungsanforderungen, haben wir mehrere Teams, die unabhängig ausliefern müssen, ist die Domäne komplex genug, um harte Grenzen zu rechtfertigen — wurden nie gestellt. Die ehrlichen Antworten wären Nein, Nein und Nein gewesen: 200 Bestellungen am Tag, ein Team, simples CRUD.

Was wir gebaut haben

  • Acht Services: API-Gateway, Auth, User, Product, Order, Notification, Analytics, Admin
  • Kafka, Redis und Elasticsearch, um sie zu verdrahten, dazu PostgreSQL
  • Zwölf CI/CD-Pipelines, eine pro Deployable
  • Infrastrukturrechnung: etwa $3.000/Monat

Ein langweiliger Django- oder Rails-Monolith auf PostgreSQL — auf einem $20/Monat-Droplet — hätte diese Last verkraftet, ohne sie zu bemerken, und wäre in zwei Wochen statt sechs Monaten ausgeliefert gewesen. Stattdessen hatten wir Netzwerkaufrufe, wo Funktionsaufrufe gereicht hätten, und verteilte Transaktionen, die wir nicht vollständig durchschauen konnten.

Die Team-Rechnung

Vier Entwickler und zwölf Deployables heißt: Jede Person „besitzt“ drei Services, und der Bus-Faktor jedes Services ist eins. Als der Entwickler, dem Auth gehörte, in den Urlaub fuhr, blieb ein Auth-Bug zwei Tage liegen, weil sonst niemand den Code kannte. Bereitschaft für alles hieß: dauerhaft in Bereitschaft. Ein einzelnes Feature berührte routinemäßig drei Services und brauchte koordinierte Deploys, also wurde „kannst du mal auf meinen Service schauen?“ zum täglichen Ritual, und das Kontextwechseln hörte nie auf.

Es gibt keine etablierte Regel für Personen pro Service, und wir erfinden auch keine. Die tatsächliche Branchenempfehlung dreht sich um kognitive Last: Ein einzelnes Team sollte eine Menge an Services besitzen, die klein genug ist, um sie wirklich zu verstehen, zu betreiben und dafür Bereitschaft zu haben. Nach diesem Maßstab besitzt ein Vier-Personen-Team ein System — vielleicht zwei — nicht zwölf.

Was wir hätten tun sollen

Mit einem gut strukturierten Monolithen mit durchgesetzten Modulgrenzen starten und einen Service erst dann herauslösen, wenn ein konkreter, gemessener Druck es verlangt — eine Komponente, die anders skaliert, oder ein Team, das unabhängig deployen muss. Unser Leitfaden dazu, wann sich Microservices-Architektur tatsächlich auszahlt, behandelt diese Auslöser, und eine Landschaft wie diese wieder zusammenzuführen ist ein eigenes, heikles Projekt — eines, das wir als vollwertiges DevOps-Engagement behandeln und nicht als Wochenend-Refactoring.

Lektion: Microservices sind eine organisatorische Skalierungsstrategie, kein technisches Upgrade. Sie lösen Koordinationsprobleme zwischen vielen Teams; wenn Sie diese Probleme nicht haben, erzeugen sie neue. Wenn Ihr ganzes Team in einen Besprechungsraum passt, brauchen Sie sie fast sicher nicht.

← Zurück zu Lessons Learned

Incidents wie dieser sind vermeidbar. Unser AWS Managed Services-Team überwacht Kundenumgebungen 24/7 mit KI-gestütztem Monitoring und Senior Engineers am Pager — damit Geschichten wie diese im Archiv bleiben.

Tags: #Microservices #Architektur #Teamgröße #Antipattern