Ihr MVP braucht keine Microservices: Ein Leitfaden für CTOs zur richtigen Dimensionierung der Architektur

In den letzten drei Jahren haben wir den Code von über 30 Start-ups geprüft. Das häufigste Muster: Eine Architektur, die für 10 Millionen Nutzer ausgelegt ist, aber nur 500 bedient.

Ein Startup ohne Umsatz mit einem Kubernetes-Cluster, 12 Microservices, einer Message-Queue, einem Service Mesh und Infrastrukturkosten von 3.000 Dollar pro Monat. Der Konkurrent? Ein Django-Monolith auf einem Server für 50 Dollar im Monat, der Funktionen viermal schneller bereitstellt.

Überdimensionierung verschwendet nicht nur Geld. Sie verschwendet auch die einzige Ressource, die Start-ups nicht kaufen können: Zeit.

Instagram bedient 300 Millionen Nutzer mit einem Django-Monolithen. Shopify läuft auf einem Rails-Monolithen. Stack Overflow bedient monatlich 100 Millionen Besucher mit einem .NET-Monolithen auf 9 Webservern.

Eine solide Monolith-Architektur mit PostgreSQL und Redis bewältigt mehr Datenverkehr, als 99 % aller Startups jemals zu bewältigen haben werden. Der Engpass liegt nicht in Ihrer Architektur – sondern in Ihren Datenbankabfragen, Ihren N+1-Problemen und Ihrer fehlenden Cache-Ebene.

Extrahieren Sie einen Dienst erst dann, wenn Sie Probleme bemerken, nicht vorher:

1. Probleme bei der Skalierung des Teams. Wenn sich mehr als 10 Entwickler bei der Arbeit an derselben Codebasis gegenseitig ins Gehege kommen, ist eine Aufteilung in zwei bis drei Dienste mit klarer Zuständigkeit sinnvoll.

2. Kopplung bei der Bereitstellung. Wenn für die Bereitstellung des Benachrichtigungssystems die Bereitstellung der gesamten App und die Ausführung aller Tests erforderlich sind, sollten Sie die Benachrichtigungsfunktion als separaten Dienst auslagern.

3. Unterschiedliche Skalierungsanforderungen. Wenn Ihre Bildverarbeitung zehnmal mehr Rechenleistung benötigt als Ihre API, können Sie durch die Auslagerung der Bildverarbeitung eine unabhängige Skalierung vornehmen.

4. Unterschiedliche Release-Rhythmen. Wenn das Abrechnungsteam wöchentliche Releases durchführt, das Kernprodukt jedoch täglich aktualisiert wird, ermöglichen separate Dienste jedem Team, in seinem eigenen Tempo zu arbeiten.

Wenn heute keiner dieser Punkte auf Sie zutrifft, brauchen Sie keine Microservices. Punkt.

Nachdem wir über 65 Produkte entwickelt haben, lautet unsere Standardempfehlung für ein MVP wie folgt:

Diese Lösung bewältigt monatlich 100.000 Nutzer, kostet weniger als 100 Dollar pro Monat und kann von einem einzigen Entwickler gewartet werden. Wenn eine Skalierung erforderlich ist, kann jede Komponente ohne Neuprogrammierung aktualisiert werden.

In den über 50 Due-Diligence-Gesprächen, die wir begleitet haben, haben Investoren nie gefragt: „Nutzt ihr Microservices?“ Sie fragten vielmehr:

1. Wie schnell könnt ihr eine neue Funktion bereitstellen? (Geschwindigkeit)

2. Was passiert, wenn Ihr leitender Entwickler kündigt? (Bus-Faktor)

3. Kann die Architektur das Zehnfache Ihrer derzeitigen Auslastung bewältigen? (Nicht das Tausendfache, sondern nur das Zehnfache)

4. Verfügen Sie über automatisierte Tests und CI/CD? (Qualität)

Ein gut getesteter Monolith schneidet bei allen Fragen besser ab als eine schlecht getestete Microservices-Architektur, die nur eine einzige Person versteht.