Microservices sind eine Steuer, die Startups sich nicht leisten können

• Wenn Code in frühen Startups vorschnell in Microservices aufgeteilt wird, führt das zu einem erheblichen Produktivitätsverlust im Team und zu mehr Komplexität
• Eine monolithische Architektur bietet einfache Deployments, schnelle Veröffentlichung neuer Features und optimiert das Überleben durch effiziente Zusammenarbeit
• Microservices bieten die Vorteile der Aufteilung nur dann, wenn große Skalierung, unterschiedliche Workloads oder separate Runtime-Anforderungen vorliegen
• Übermäßige Service-Aufteilung, eine Flut an Repositories, instabile lokale Entwicklungsumgebungen und ein uneinheitlicher Tech-Stack führen zu geringerem Tempo und sinkender Teammoral
• Startups sollten mit einem Monolithen beginnen und nur dann vorsichtig aufteilen, wenn klare Engpässe entstehen

---

Einleitung und Hintergrund

• Das Überleben eines Startups wird durch schnelle Iteration, die Bereitstellung neuer Features und die Schaffung von Nutzerwert bestimmt
• Die grundlegende Architektur eines Projekts, der Tech-Stack und die Wahl der Programmiersprache beeinflussen das Tempo des Teams
• Die frühe Einführung von Microservices wirkt offiziell zwar elegant, führt in der Praxis jedoch zu Produktivitätsverlust, unvollständigen Services und übermäßiger Komplexität
• Datenpunkte: Es entstehen vielfältige Entwicklungskosten durch Service-Orchestrierung, Docker-/Skript-Probleme, dupliziertes CI/CD, Kopplung zwischen Services, Observability-Kosten und verteilte Tests
• Statt vorschnell in eine komplexe Architektur zu gehen, wird die Bedeutung einer pragmatischen Architektur betont

Die Stärken des Monolithen

• Ob SaaS oder einfacher Datenbank-Wrapper: Mit der Zeit wird eine App komplexer, aber eine monolithische Architektur bleibt leichter einfach und flexibel zu halten
• Deployments sind einfach, es gibt starke Unterstützung durch populäre Frameworks (Django, ASP.Net, Nest.js usw.) und große Vorteile aus der Open-Source-Community
• Praxisbeispiel: Ein Immobilien-Startup konnte mit einem Laravel-Monolithen zahlreiche Third-Party-Integrationen und Feature-Erweiterungen problemlos umsetzen
• Ohne komplexe Infrastruktur einzuführen oder in Microservices aufzuteilen, konnte man sich auf die Erfüllung von Geschäftsanforderungen und Erwartungen konzentrieren
• Lehre: Architektonische Einfachheit hilft dem Team, sich auf Deployments zu konzentrieren; solange die interne Modularisierung nicht scheitert, ist auch Skalierung ausreichend möglich

Sind Microservices immer die beste Wahl?

• Viele Engineers halten Microservices für die Musterlösung, doch in Wirklichkeit spielen sie ihre Stärken nur bei besonderen Gründen wie Skalierung aus
• In kleinen Teams, bei kleinem Umfang und in Phasen schneller Veränderungen führen sie eher zu duplizierter Infrastruktur, langsamer lokaler Entwicklung und längeren Iterationszyklen
• Auch Unternehmen wie Segment haben einen Wechsel aufgrund ineffizienter Strukturen erlebt
• Lehre: Microservices sind ein Werkzeug zur Beseitigung von Engpässen, kein Template für die Anfangsphase

Warum Microservices besonders in der Frühphase scheitern

1. Willkürliche Service-Grenzen

• Der Versuch, Services anhand von Business-Logik aufzuteilen, indem man sich an Domain-driven Design oder Clean-Architecture-Theorien orientiert, führt dazu, dass die tatsächliche Logik und die Service-Grenzen nicht sauber zusammenpassen
• Beispiel: Die Trennung von Benutzern, Authentifizierung und Berechtigungen erhöht die Deployment-Komplexität und den Schwierigkeitsgrad der API-Entwicklung
• Eine Aufteilung in einer Phase ohne reale Engpässe macht das System instabiler und langsamer
• Es ist effektiver, mit internen Flags oder Toggles eine spätere Aufteilung zu simulieren und organisch nach sinnvollen Grenzen zu suchen, statt übereilt Infrastrukturarbeit zu betreiben
• Lehre: Entscheidungen zur Aufteilung sollten auf realen Engpässen beruhen, nicht auf Theorie

2. Zu viele Repositories und zu viel Infrastruktur

• Code-Stil, Tests, Konfigurationen, Dokumentation und CI/CD vervielfachen sich mit der Anzahl der Services
• Mit einer Monorepo-Struktur lässt sich alles an einem Ort verwalten, was die Code-Konsistenz und die Zusammenarbeit verbessert
• Im Node.js-Umfeld erleichtern Tools wie nx oder turborepo das Management von Abhängigkeiten und Builds zwischen internen Services
• Nachteile sind komplexe Abhängigkeitsbeziehungen, nötiges CI-Performance-Tuning und der Bedarf an schnelleren Build-Tools
• Auch im Go-Ökosystem kann man anfangs mit einem einzigen Workspace arbeiten und erst bei wachsender Größe über eine Modultrennung nachdenken
• Lehre: Kleine Teams können mit Monorepo und gemeinsamer Infrastruktur Zeit gewinnen

3. Instabile lokale Entwicklungsumgebung

• Zu lange lokale Startzeiten, komplexe Skripte und systemabhängige Abhängigkeiten führen zu verzögertem Onboarding und sinkender Produktivität
• Fehlende Dokumentation, Kompatibilitätsprobleme und OS-spezifische Hacks (z. B. macOS-only-Skripte) werden zu Hindernissen
• In einem Projekt wurde die Docker-Komplexität durch einen Node.js-Proxy reduziert, wodurch die Onboarding-Zeit für Entwickler sank
• Lehre: Wenn die App nur auf einem Betriebssystem läuft, hängt die Produktivität des Teams am Ende von der Zuverlässigkeit eines einzigen Laptops ab

4. Uneinheitlicher Tech-Stack

• Node.js und Python eignen sich gut für schnelle Iteration, aber in einer Microservice-Umgebung treten häufig Probleme durch Unterschiede bei Build und Runtime auf
• Go hat Vorteile bei statischen Binärdateien, schnellen Builds und einfacherem Betrieb
• Die Wahl des Tech-Stacks sollte früh sorgfältig getroffen werden; falls nötig, kann ein Mischbetrieb verschiedener Sprachen über Protokolle wie gRPC ermöglicht werden
• Ohne besondere Anforderungen wie ML oder ETL erhöht ein gemischter Stack meist nur die Komplexität
• Lehre: Wählt einen Stack, der zur Realität des Teams passt, nicht zu seinen Träumen

5. Versteckte Komplexität: Kommunikation und Monitoring

• Bei Microservices sind Service Discovery, API-Versionierung, verteiltes Tracing und zentrales Log-Management unverzichtbar
• Das Nachverfolgen von Bugs und Ausfällen ist im Monolithen oft nur ein Stacktrace, in verteilten Umgebungen jedoch deutlich komplexer
• Wenn man es richtig machen will, braucht man spezialisierte Tools wie OpenTelemetry und den Aufbau eines vollständigen Observability-Stacks
• Man sollte erkennen, dass verteilte Systeme eine verpflichtende Zusatzinvestition in weitere Engineering-Herausforderungen bedeuten

Wann Microservices sinnvoll sind

• Workload-Isolierung: Das Auslagern bestimmter asynchroner Aufgaben wie Bildverarbeitung oder OCR kann effizient sein
• Ungleichgewicht bei Skalierungsanforderungen: Wenn Web-API und ML-Workloads unterschiedliche Hardware- und Betriebsanforderungen haben, ist eine getrennte Aufteilung sinnvoll
• Bedarf an anderer Runtime: Komponenten wie Legacy-C++-Code, die runtime-seitig nicht zum Hauptsystem passen, können als separater Service betrieben werden
• Beispiele aus großen Engineering-Organisationen (z. B. Uber) zeigen, dass dies nur bei klarer organisatorischer Notwendigkeit und ausgereiften Betriebsfähigkeiten geeignet ist
• Selbst in kleinen Teams kann eine Trennung in seltenen Fällen praktisch sein, etwa bei externen Analyse-Services mit einfacher Verwaltung
• Lehre: Setzt Microservices nur dort ein, wo der praktische Nutzen der Aufteilung eindeutig ist

Praxisleitfaden für Startups

• Startet zunächst mit einem Monolithen und arbeitet mit bewährten Frameworks fokussiert an der eigentlichen Aufgabe
• Ein einziges Repository ist für frühe Teams bei Betrieb, Verwaltung und Sicherheit oft vorteilhafter
• Eine vereinfachte lokale Entwicklungsumgebung ist wichtig; wenn sie schwierig ist, sind ausführliche Anleitungen und Videos Pflicht
• Früh in CI/CD investieren, um wiederkehrende Arbeit zu automatisieren und die mentale Last im Team zu senken
• Nur bei klar auftretenden Engpässen selektiv aufteilen; sonst auf Modularisierung und bessere Tests innerhalb des Monolithen konzentrieren
• Oberstes Ziel ist der Erhalt der Entwicklungsgeschwindigkeit
• Lehre: Mit Einfachheit beginnen und passend zum tatsächlichen Bedarf an Trennung skalieren

Wenn ihr Microservices unbedingt einsetzen müsst

• Tech-Stack bewerten und in Developer-Experience-Tools investieren: Automatisierung pro Service, klare Skripte und Tools für zentrales Deployment-Management sind nötig
• Zuverlässige Service-Kommunikationsprotokolle und Standardisierung: Zusätzliche Implementierungsaspekte wie konsistente Message-Schemas, Dokumentation und Fehlerbehandlung müssen berücksichtigt werden
• Test-Infrastruktur stabilisieren: Unit-, Integrations- und E2E-Tests müssen passend zur Service-Aufteilung skalieren
• Gemeinsame Bibliotheken sorgfältig abwägen: Gemeinsamer Code für Observability und Kommunikation sollte minimal gehalten werden, um häufige Rebuilds aller Services zu vermeiden
• Observability früh einführen: Bereits grundlegende Logging-Werkzeuge wie strukturierte JSON-Logs und Correlation IDs sollten vorhanden sein
• Zusammengefasst ist es wichtig, bei akzeptierter Komplexität mit voller Konsequenz ein System zu entwerfen, das beherrschbar bleibt

Fazit

• Eine vorschnelle Einführung von Microservices hinterlässt vor allem Belastung, daher sollte Einfachheit oberste Priorität haben
• Ohne klaren Schmerzpunkt sollte man nicht aufteilen; entscheidend ist die Perspektive, nur die minimale Komplexität hinzuzufügen, die für Überleben und Wachstum nötig ist
• Erst überleben, dann skalieren

[kuil09]

Ich stimme der ursprünglichen Aussage insgesamt zu.
Ich denke, es ist eine Frage der Erfahrung innerhalb der Organisation.
Man kann es sich so vorstellen, als würde man erst Essen aus einem Foodtruck verkaufen und dann zu einem Restaurant werden.
Von Anfang an Arbeitsteilung und Spezialisierung einzuplanen, ist kaum möglich, weil den Beteiligten dafür schlicht die notwendige Erfahrung fehlt.

[dhlee0305]

Ich denke, Startups sollten Wege mit geringeren Kosten wählen, um ihre Überlebenszeit zu verlängern. Microservices sind absolut nicht billig. In der Praxis verursachen sie im realen Einsatz beträchtliche Kosten. Wenn möglich, ist es aus meiner Sicht ein Weg, mit geringeren Kosten ähnliche Effekte zu erzielen, eine Architektur zu entwerfen, die zum eigenen Service passt.
Ich sage nicht, dass Microservices schlecht sind. Es ist ein Modell, das hohe Kosten erfordert.

[mhj5730]

Ich denke, es reicht völlig, wenn man nur zwei Dinge hat: einen rein synchronen Monolithen und einen rein asynchronen Monolithen ... Die Einführung von Microservices hängt meiner Ansicht nach letztlich vom Umfang der Tabellen ab, die in der DB verwaltet werden müssen. Wenn es absurd viele und komplexe Tabellen gibt, sollte man über MSA nachdenken; wenn es einfach ist, ist ein Monolith genau richtig.

[roxie]

Wenn all diese Wellen vorübergezogen sind, wie wird die Nachwelt sich an diese Generation erinnern?

[n1ghtc4t]

Damals war es wieder die Welle jener Zeit ...

[bungker]

Ich denke, dass Microservices auch in Startups viele Vorteile haben. Vor allem die Vorteile eines Monorepos kann ich wirklich empfehlen.

• Wenn die Produktausrichtung geändert wird, sind bei Microservices die anzupassenden Teile klarer abgegrenzt und weniger zahlreich als bei einem Monolithen. Ich halte das für einen wirklich großen Vorteil.
• Im Zeitalter der KI-gestützten Entwicklung lassen sich die kleinen Einheiten von Microservices mithilfe von KI leichter entwickeln. (Das heißt nicht, dass es bei einem Monolithen nicht geht.)
• Die Belastung durch CI/CD erkenne ich an, aber es gibt auch Services, die schon in der Phase eingestellt werden, in der man noch die Richtung festlegt. Selbst wenn man sie erst aufbaut, nachdem die endgültige Richtung feststeht, ist das fast ein reines Copy-and-paste-Niveau und innerhalb einer Woche umsetzbar.
• Es gibt klar erkennbare Open-Source-Stärken je nach Sprache. Security und Business-Logik in Java, KI in Python – in einer Microservice-Architektur kann man so möglichst viel Open Source nutzen.

[andone]

Ich stimme zu, dass es im Zeitalter der KI-Entwicklung unverzichtbar ist, in kleinen Einheiten mit klar abgegrenzter Verantwortung zu implementieren.

[bus710]

Das wurde in den Kommentaren schon kurz angesprochen, aber die Beam/OTP-Welt wirkt in dieser Hinsicht ziemlich flexibel und gut. Im Fall von Gleam ist durch die Kombination der guten Syntax von Go und Rust mit der Stabilität von Beam eine ziemlich beeindruckende Sprache entstanden. Ich würde sie nach und nach gern einmal in kleineren Projekten einsetzen.

[ndrgrd]

Wenn man Teams wahllos aufteilt, wird schon das Zusammenkommen, um Meinungen auszutauschen, zu einer enormen Aufgabe.

[GN⁺]

Hacker-News-Kommentare

• Mir wurde klar, dass Microservices ohne echte Skalierungsprobleme, große Teams oder Domänen, die sich unabhängig weiterentwickeln müssen, nur Kosten verursachen und keinen Nutzen bringen; tatsächlich hat auch Segment aus genau diesem Grund die Aufteilung in Microservices wieder zurückgenommen. Es ist eher ein Organisationsmuster als eine technische Entscheidung. Meist betreibt man zunächst einen einzelnen Monolithen und lagert dann nur Frontend, Backend oder lang laufende Jobs wie etwa PDF-Erzeugung als separate Services aus. Wenn danach die Zahl der Services wächst, beginnt man über Standardisierung und Architektur nachzudenken. Bei weniger als 200 Engineers ist der Produktivitätsverlust oft sogar größer. Man überlebt nicht wegen der Microservices, sondern trotz ihnen.
  • Manche Entwickler neigen dazu, Microservices einzuführen, um später einen Lebenslauf für einen zukünftigen Großkonzern vorweisen zu können. Einem echten Startup hilft das meist kaum. Um so etwas zu verhindern, braucht es wirklich kluge technische Führung.
  • Ich habe ein Startup mit rund 50 Engineers erlebt, das in Dutzende Services zerlegt wurde. Neue Leute brauchten mindestens sechs Monate, um das System zu verstehen. Es gab nur einige Hundert Nutzer, aber eine enorme Komplexität. Man verbrannte $50 Millionen VC-Geld und scheiterte am Ende. Das Produkt war innovativ und gut entworfen, aber das spielte keine Rolle.
  • Beim Aufteilen in Services gibt es auch den Ansatz, den Code nicht zu trennen, sondern einen gewöhnlichen Monolithen nur über Rollen-Flags getrennt zu deployen. Selbst Background-Worker können zusammen mit dem Webserver laufen, während Health Checks und Metriken genutzt werden und der Load Balancer den Traffic je nach Rolle verteilt.
  • Wie beim Fall von Khan Academy kann man erst dann anhand von Erfahrung sinnvoll Service-Grenzen bestimmen, wenn man einen Monolithen weit genug skaliert hat. Dann ist die Einführung von Microservices passend.
  • Es gibt zwar technische Gründe für eine Trennung, aber Services sind grundsätzlich eine schwierige Sache. Wenn man sie braucht, ist die Bereitschaft wichtig, das nötige Können aufzubauen. Man sollte sie nicht nur deshalb ablehnen, weil sie einmal ein Trend waren, sondern die Trade-offs abwägen.
  • Nur weil es „mehrere Teams“ gibt, muss man die Organisation nicht aufspalten. Es gibt tatsächlich Directors, die einen Monolithen trennen wollen, sobald zwei kleine Squads entstanden sind. Wenn Teams häufig umgebaut werden, etwa alle neun Monate, ist es eher eine Katastrophe, Architekturgrenzen zu früh festzulegen. Erst wenn man prüfen konnte, ob ein Team mindestens etwa 18 Monate stabil als Einheit arbeiten kann, taugt das als Architekturgrenze.
  • Die Definition von Microservices zielte ursprünglich ohnehin auf „Domänen, die sich unabhängig weiterentwickeln können“, daher wirkt das alles nicht besonders neu.
  • Bei einem sehr speziellen URL-Pfad unterschieden sich Traffic- und Speicheranforderungen so stark, dass er auf dem PHP-Server ungeeignet war; deshalb wurde nur ein einzelner zusätzlicher Server in einer anderen Sprache ergänzt. Das brachte eine 1000-fache Verbesserung bei Performance und Kosten. Vielleicht sollte man das Service-Konzept im Stil von Java/Spring/Guava auch einmal als „außerhalb des Prozesses“ oder „innerhalb des Prozesses“ betrachten. Wenn man Tech-Stack, Versionen und Serialisierung gut standardisiert, kann die Produktivität sogar steigen; fehlt diese Standardisierung, führt das zu Kommunikationsfehlern, Kompatibilitätsproblemen und allgemeinem Chaos.
  • Conway's Law, also dass die Codestruktur die Organisationsstruktur widerspiegelt, stimmt in der Praxis tatsächlich.
  • Ein Service ist etwas, das von Menschen bereitgestellt wird; ein Microservice ist ein Service in der internen Ökonomie eines Unternehmens.
  • Eine Erfahrung von vor 15 Jahren: Ein kleines Team konnte eine einzelne Lösung leicht betreiben, aber nach der Einführung von Microservices musste man jeden Service starten und koordinieren und hatte große Mühe damit. Dabei habe ich gelernt, wie wichtig YAGNI ist: nichts bauen, bevor es wirklich gebraucht wird.
  • Es gibt viele technische Gründe für eine Trennung, etwa hohen Traffic oder kritische Pfade. In kleinen Organisationen ist das meist nicht wünschenswert, aber wenn man nur stark belastete Pfade herausschneidet, kann das auch in Startups großen Nutzen bringen.
  • Tatsächlich liegt der Hauptvorteil von Microservices darin, kleinen Gruppen unabhängiges Arbeiten ohne gegenseitige Störungen zu ermöglichen. Aber wenn mehrere Teams jeweils eigene Microservices besitzen, enden Standardisierungsrunden nie, und statt Zusammenarbeit wird Diplomatie nach dem Muster „kümmere dich um deinen Kram“ wichtiger, sobald externe Services im Spiel sind.
• In einem Team mit 2–3 Entwicklern wurde trotz des Hinweises, dass Microservices nur cool wirken, ihre Einführung durchgesetzt. Erst zwei Jahre später wurde der bestehende Code neu aufgebaut, und selbst drei Jahre danach sind Deployment- und andere Probleme noch nicht gelöst. Hätte man den Rat nicht ignoriert und stattdessen einen modularen Monolithen gewählt, wären diese Probleme nicht entstanden. Ich stimme diesem Beitrag zu.
  • Wenn jemand nur ein schillerndes Tech-/Projektprofil hinterlässt und dann schnell den Job wechselt, müssen andere die Folgen ausbaden.
  • Microservices taugen erst dann wirklich etwas, wenn jedes Team genau einen Service betreut. Ich habe noch kein gutes Beispiel gesehen, in dem ein Team mehrere Services gleichzeitig pflegt.
  • Viele Probleme entstehen daraus, dass Teammitglieder Microservices weiterhin als ein einziges System, also wie einen Monolithen, betrachten. Von Design bis Deployment erzeugt das Reibung. Erfolgreich wird das nur, wenn die ganze Organisation das ausreichend mitträgt. Wenn man ein bestehendes System in Microservices umbaut, gibt es viel internen Widerstand.
  • Am Ende wirkt es so, als würden Startups alle einen ähnlichen Leidensweg durchmachen.
  • Sogar bei einem internen UI-Projekt mit 8–12 Microservices gab es in Wirklichkeit nur 5–10 Nutzer, und die unnötige Komplexität wurde nur größer. Ich verstehe bis heute nicht, warum.
  • Ich habe dank Thoughtworks-Beratung einmal Microservices + Java eingeführt. Die Beratung verdiente ihr Geld und zog weiter, während die Organisation damit kämpfte, einen funktionsreichen Monolithen als verteilte Microservices neu umzusetzen. Das Projekt scheiterte am Ende, und die Firma verschwand. Seitdem misstraue ich großen Beratungsfirmen.
• Im Stil eines grug-Gehirns gefragt: Warum sollte man absichtlich den schwierigeren Weg wählen, ein System aufzuteilen und noch Netzwerkaufrufe hinzuzufügen?
  • Es fühlt sich an, als würde man einer Sprache wie Python dort eine „Monkeypatch“-Funktion hinzufügen, wo sie sie eigentlich nicht hat.
  • Eine Meinung dazu ist, dass Netzwerkaufrufe Regeln in Gesetze verwandeln.
  • Mit grug-Humor gesagt: Wenn es nur genug grugs mit grug-Gehirn gäbe, würden manche Overgroups wohl glauben, neun grugs könnten in einem Monat ein Baby-grug machen.
• Microservices sind in großen Organisationen wirksam, um personelle Probleme zu lösen, bürokratische Hürden abzubauen und Entwicklern Autonomie zu geben. Für kleine Startups ist der tatsächliche Nutzen meist gering. Wenn sich in einer bestimmten Domäne aber Tech-Stacks mischen, etwa Elixir zusammen mit Python/Go, kann eine solche Trennung nötig sein.
  • Wenn verschiedene Teile einer App sehr unterschiedliche Last- oder Ressourcenanforderungen haben, ist ein separater Service auch in kleinen Startups vorteilhaft. Der Großteil der Business-Logik bleibt dann im Monolithen, und nur spezielle Arbeiten wie GPU-lastige Tasks werden ausgelagert. Man sollte aber vermeiden, dass dieses Muster in die Pflege von 100 Services ausartet. Grundsätzlich ist ein Monolith vorzuziehen; trennen sollte man nur bei Bedarf.
  • Microservices schaffen eher neue organisatorische Abhängigkeiten und zusätzlichen Abstimmungsbedarf. Zum Beispiel erhöht eine Politik nach dem Motto „nimm einfach irgendeinen Service und nutze ihn“ den Wartungsaufwand stark, weil dann alle alles lernen müssen, damit der Betrieb funktioniert. Am Ende verbringt man viel Zeit damit, Leute zu finden.
  • Wenn Teams miteinander im Konflikt stehen oder Arbeit doppelt machen, wächst die Ineffizienz.
• Microservices ähneln in der Softwarearchitektur Conway's Law, also der Idee, dass die Organisationsstruktur die Codestruktur beeinflusst. An jeder Teamgrenze entsteht auch eine Grenze, die überquert werden muss, und große Architekturgrenzen künstlich innerhalb eines Systems zu schaffen, ist meistens unproduktiv. Stattdessen kann man mit Dependency Injection, sauber gestalteten Modulgrenzen oder dem Actor Model einen modularen Monolithen pflegen. Wenn später wirklich Bedarf entsteht, lässt sich die Trennung in Services dann leichter vornehmen. Für mich hatte dieser Ansatz das beste Kosten-Nutzen-Verhältnis. Ich habe Monolithen selbst 3–4 Mal erfolgreich auseinandergeschnitten.
  • Conway's Law ist ein Gesetz über Kommunikation, also über Grenzen in der Abstimmung. Es ist nicht nötig, jede Teamgrenze direkt zu spiegeln. Stattdessen muss man die Organisation sogar passend zur Software umgestalten; das hieße, bei jeder Architekturänderung wäre auch eine Reorganisation der Firma nötig. So etwas vertieft nur die Entkopplung zwischen Team und Geschäftszielen. Man sollte das Amazon-Modell nicht blind verehren.
• Technisch passen Microservices in Startups nur in wenigen Fällen: (1) wenn neben der Core-App zwingend eine andere Sprache nötig ist, etwa Rails + R, (2) wenn nur manche Services ganz andere Skalierungsanforderungen haben, oder (3) wenn bestimmte Daten ganz andere Sicherheits- oder Lebenszyklusanforderungen haben, etwa Gesundheitsdaten. Darüber hinaus gibt es kaum Gründe für eine starke Zerteilung, und für kleine Organisationen ist sie eher nachteilig.
  • Ein paar neue Service-Aufteilungen sind nicht dasselbe wie echte Microservices. Echte Microservices bedeuten, dass selbst Dinge getrennt werden, die man in einer normalen Anwendung eher als Module behandeln würde.
  • Nicht nur Skalierung, auch extrem unterschiedliche Anforderungen an Zuverlässigkeit und Verfügbarkeit können eine Trennung in eigene Services sinnvoll machen. Durch die Trennung von Zuständigkeiten zur Einhaltung von SLAs erwartet man weniger Risiko und schnellere Deployments.
  • Selbst in solchen Fällen unterscheidet sich das aus meiner Sicht kaum davon, einfach nur einen DB-Server separat zu betreiben.
• Der eigentliche Erfolg von Microservices liegt auf organisatorischer Ebene: Probleme werden zerlegt, jedes Team besitzt ein Teilstück vollständig und ist bis zur End-to-End-Auslieferung verantwortlich, sodass Spezialisierung möglich wird. Änderungen erfolgen grundsätzlich inkrementell, und APIs sind der einzige Interaktionsweg. Es gibt keine gemeinsam genutzte einzelne Datenbank, kein gemeinsames Dateisystem und keine gemeinsam verwendete API. Stattdessen sind Standardisierung und Verwaltungs-Tooling wichtig, einschließlich Monitoring, Tests und CI/CD. Ein Stück weit braucht man das aber unabhängig davon, ob man einen Monolithen oder etwas anderes betreibt.
  • Infrastruktur, Logging und Auth können paketiert oder über gRPC, Message Queues usw. verwaltet werden. Neue Services lassen sich schnell anlegen, und selbst Merge Requests innerhalb eines Teams werden kleiner, wodurch Konflikte sinken und die Produktivität steigt. Bei Teams von 5–10 Personen gab es mit Monolithen häufig Konflikte, Deployment-Probleme und Release-Themen, nach der Umstellung auf Microservices verbesserten sich Produktivität und Zusammenarbeit spürbar. Wichtig waren dabei allerdings klare Regeln für Tests, Dokumentation und Endpoints.
  • Auch im Hinblick auf Performance, etwa durch getrennte Datenbanken, kann es technische Gründe für eine Trennung geben, aber in typischen Startups ist das eher selten.
• Die Stärke des BEAM/OTP-Ökosystems (Erlang, Elixir) besteht darin, dass man einen Monolithen beibehalten und dabei trotzdem ein „microservice-artiges“ Design üben kann, um später bei echtem Bedarf leicht umzusteigen. In kleinem Maßstab hat man die Vorteile des Monolithen, und beim Wachsen kann man zugleich Skalierung und Unabhängigkeit gewinnen. Dafür muss man allerdings Unveränderlichkeit von Objekten, nebenläufige Kommunikation und Fehlermanagement lernen, und auch die Personalsuche kann schwieriger sein.
• Ich stimme größtenteils zu. In Startups ist es fast unmöglich, sinnvolle Service-Grenzen zu ziehen. Es gibt aber Fälle, in denen Microservices auch für kleine Teams wegen externer APIs oder komplexer Abhängigkeiten vorteilhaft sind. In solchen Fällen ist eine Netzwerkgrenze ohnehin zwingend nötig, sodass ein eigener Service die Komplexität nicht wesentlich erhöht. Auch bei Build- oder Deployment-Komplexität kann eine Aufteilung den Monolithen vereinfachen.
• Microservices sind nur sinnvoll bei sehr großer Skalierung oder wenn Team-Micromanagement nötig wird. Auf klare Modulgrenzen sollte man jedoch niemals verzichten. Mit objektorientiertem Design im Stil von Message Passing kann man die Vorteile von Microservices auch innerhalb eines Monolithen nutzen. Man muss trainieren, nicht direkt auf die DB zuzugreifen. In Sprachen wie Java kann man Modulgrenzen, DB-Schema-Namespaces und minimal freigegebene Interfaces verwenden, dazu unabhängige Tests und Monitoring. So wird auch das gleichzeitige Deployment mehrerer Services einfacher.
  • Wenn man logische Grenzen gut genug versteht, kann man sie auch mit Tools wie ArchUnit erzwingen.