Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren

Monorepos bei Uber: Vor- und Nachteile einer kontroversen Architekturentscheidung

Die Diskussion um Monorepos - also einzelne große Code-Repositories, die mehrere Projekte enthalten - ist in der Software-Entwicklung nach wie vor sehr aktuell. Ein besonders interessanter Einblick kommt von Uber, die kürzlich ihre Erfahrungen mit Monorepos und dem dazugehörigen Tooling veröffentlicht haben. Doch was genau sind die Vor- und Nachteile dieser Architekturentscheidung?

Was ist ein Monorepo?

Ein Monorepo ist ein zentrales Code-Repository, in dem mehrere Projekte oder Services gemeinsam verwaltet werden. Bei Uber bedeutet das konkret: Tausende von Microservices werden in wenigen großen Repositories organisiert, hauptsächlich aufgeteilt nach Programmiersprachen.

Die Vorteile von Monorepos

Die wichtigsten Vorteile dieser Architektur sind:

• Einfacheres Teilen von Code zwischen Projekten
• Koordinierte Änderungen über Komponentengrenzen hinweg
• Einheitliche Versionierung
• Atomare Änderungen über mehrere Services
• Vereinfachtes Dependency Management
• Bessere Kollaboration über Teamgrenzen hinweg

Die Herausforderungen bei Uber

Bei Uber zeigen sich aber auch Herausforderungen:

1. Sehr große Deployments: Eine einzelne Änderung kann bis zu 2000 Microservices betreffen.
2. Komplexes Deployment-Management: Uber musste ein ausgeklügeltes Kohorten-System entwickeln.
3. Blockierte Deployments: Teams müssen teilweise warten, bis zentrale Änderungen durchgeführt sind.
4. Hoher Tooling-Aufwand: Spezielle Tools für das Management großer Codemengen sind notwendig.

Der Uber-Ansatz: Kohorten-basiertes Deployment

Uber hat ein System entwickelt, das Änderungen in Kohorten ausrollt:

• Services werden nach Kritikalität gruppiert.
• Deployments erfolgen schrittweise Kohorte für Kohorte.
• Fehler werden früh erkannt durch Beta-Testing in weniger kritischen Kohorten.
• Ziel ist, dass weitere Deployments weniger als 24 Stunden gesperrt werden.

Kritische Betrachtung

Mehrere Aspekte des Uber-Ansatzes werfen Fragen auf:

1. Lose Kopplung vs. zentrale Koordination: Der Ansatz scheint dem Microservice-Prinzip der unabhängigen Deployments zu widersprechen.

2. Technische vs. fachliche Organisation: Die Aufteilung nach Programmiersprachen statt nach fachlichen Domänen erscheint fragwürdig.

3. Deployment-Abhängigkeiten: Teams werden in ihrer Deployment-Autonomie eingeschränkt.

4. Komplexität: Das System erscheint sehr komplex.

Alternative Ansätze

Google zeigt mit seinem Monorepo-Ansatz eine Alternative:

• Pull-Request basierte Änderungen
• Stärkerer Fokus auf Code Ownership
• Mehr Autonomie für einzelne Teams

Fazit

Monorepos können in bestimmten Kontexten sinnvoll sein, besonders wenn:

• Teams eng zusammenarbeiten müssen
• Zentrale Libraries häufig geändert werden

Allerdings sollte man genau abwägen:

• Ist der zusätzliche Tooling-Aufwand gerechtfertigt?
• Passen die Einschränkungen zur gewünschten Entwicklungskultur?
• Gibt es einfachere Alternativen?

Die Entscheidung für oder gegen Monorepos sollte nicht leichtfertig getroffen werden. Sie muss zur Größe der Organisation, der Entwicklungskultur und den technischen Anforderungen passen. Ubers Ansatz zeigt eindrucksvoll die Komplexität, die mit dieser Architekturentscheidung einhergehen kann.