Multirepo vs. Monorepo: Infomaniak teilt seine Erfahrungen bei der Wahl seiner Entwicklungsstrategie mit

Die Entwickler*innen von Facebook, Google und und dem Webmail-Team von Infomaniak legen ihren Code in einem einzigen Repository mit geteilten Abhängigkeiten ab (Monorepo bzw. Mono-Repository). Dagegen segmentieren AWS, Leboncoin.fr und die restlichen Infomaniak-Teams ihren Code in unabhängige Repositories mit kleinen autonomen Teams (Multirepo bzw. „Multiple Repositories“). Die Wahl der Methode für das Codemanagement ist eine strategische Entscheidung für Unternehmen – unabhängig von ihrer Grösse. Bleibt die Frage, wie die eigene Strategie festgelegt wird und welche Auswirkungen das hat. Wir zeigen in diesem Artikel anhand eines konkreten Beispiels – d. h. der Entwicklung unserer Webhosting-Dienste – auf, wie wir die jeweils optimale Entscheidung getroffen haben.

1. Von Monorepo zu Multirepo: Die Entwicklung des Webhostings von Infomaniak

Hosting V1: Das einzigartige Hosting-Angebot von Infomaniak

Ende der 1990er-Jahre wurde die Plattform Hosting V1 lanciert. Sie war das erste Hostingangebot von Infomaniak überhaupt.

Die erste Plattform basierte auf einer monolithischen Architektur. Dies bedeutet, dass die gesamte Anwendung als ein einziger Softwareblock entwickelt wird. Diese Architektur war bei ihrer Entstehung Standard in unserer aufstrebenden Branche. Sie war auf die Bedürfnisse des Entwicklungsteams zugeschnitten und eignete sich für unseren seinerzeit niedrigeren Datenverkehr, ermöglichte jedoch gleichzeitig ein angemessenes Entwicklungstempo.

Hosting V2: Das aktuelle Webhosting und WordPress

2013 lancierten wir unser aktuelles Hostingangebot mit der Plattform Hosting V2. Auch diese Plattform basiert auf einer monolithischen API, die allen Infomaniak-Produkten gemein ist.

In dieser Zeit begann der Siegeszug der Microservice-Architektur, obschon wir damals entschieden, diese neue Plattform nicht gleich zu übernehmen. Denn dies hätte massive Weiterentwicklungen unserer Verfahren vorausgesetzt:

• Der Code hätte grundlegend überarbeitet werden müssen.
• Der Ansatz für Implementierung und Beobachtbarkeit wäre zu ändern gewesen.
• Viele Prozesse hätten angepasst und zahlreiche
• Menschen entsprechend ausgebildet werden müssen.

Dieser Umschwung kam zu früh, denn damals fehlten waren die Hilfsmittel für die Umsetzung einer solchen Architektur unzureichend. Für ein Team mit der Grösse des Infomaniak-Teams verringerten sie die Komplexität nicht, sondern brachten noch mehr Komplexität mit sich.

2024 zählen wir sechsmal so viele Beschäftigte wie damals, sodass inzwischen ganz neue Perspektiven möglich sind und neue Bedürfnisse spürbar sind.

Hosting V3: Die nächste Hostingplattform von Infomaniak

Die künftige Hostingplattform befindet sich in der Entwicklung und wird auf einer Multi-Microservice-Architektur basieren.

Es handelt sich um eine ehrgeizige und komplexe Übergangsphase, die es ermöglichen wird, die Herausforderungen der Zukunft zu meistern und neue Hostingdienste zu entwickeln. Diese Weiterentwicklung knüpft an alle Bereiche an und betrifft sowohl die Schnittstelle als auch die Cloud-Architektur im Hintergrund.

Wir wollen unsere Fähigkeit bewahren, unsere Ideen rasch in Produkte für unsere Kundinnen und Kunden umzuwandeln. Die neue Architektur bietet das notwendige Tempo, um das Wachstum zu unterstützen und künftige Bedürfnisse vorwegzunehmen. Julien Viard, VP of Engineering bei Infomaniak

2. Umsetzung der Umstellung von Monorepo auf Multirepo

Von der Monorepo-Architektur mit Hosting V2…

Angesichts des Wachstums von Infomaniak, der Entwicklung neuer Produkte und der Erweiterung unserer Teams stösst die ursprünglich für Hosting V1 und Hosting V2 gewählte monolithische Architektur heute an ihre Grenzen. Sie wird unserer Organisationsstruktur und den heutigen Bedürfnissen immer weniger gerecht. Deshalb entwickeln wir die künftige Hosting-Plattform (Hosting V3) mit einer neuen Microservices-Architektur.

Mit der Monorepo-Architektur der Hosting-Plattform V2:

• Zunächst ist festzustellen, dass der Infomaniak-Manager der am Frontend eingesetzte Monolith ist. Dieser steuert den gesamten visuellen Aspekt der Verwaltung von Infomaniak-Produkten. Der Manager ist mit allen unseren APIs verbunden und ermöglicht unseren Kundinnen und Kunden, über eine einzige Schnittstelle alle ihre Dienste zu verwalten. Aufgrund der bestehenden Architektur wirkt sich jede Aktualisierung eines Hostingdienstes auf alle anderen Produkte aus. Folglich ist eine sehr strikte Update-Politik erforderlich, damit die Stabilität des gesamten Managers für die Kundinnen und Kunden gewahrt bleibt.
• Infomaniak Legacy (d. h. der „ursprüngliche“ oder „historische“ Code, der veraltet bzw. schwer zu pflegen ist) umfasst einen sehr grossen Teil des Legacy Hosting-Codes und des Infomaniak Legacy General Codes: Alle dieser Codes befinden sich derzeit im selben Projekt. Wie beim Frontend wirken sich Aktualisierungen des Hosting-Monolith-Backends auf den gesamten Legacy-Code von Infomaniak aus, der sämtliche Dienste betrifft. Das setzt das Tempo unserer Produktteams herab.
• Infomaniak Core ist ein Microservice, der mehrere bereichsübergreifende Funktionen wie den Abruf eines Nutzerprofils enthält.

Zusammenfassend lässt sich sagen, dass diese Architektur die Aktualisierung eines Teils der Dienste erschwert, ohne dass sich dies auf die Gesamtheit der Projekte auswirkt. Das wiederum beeinträchtigt die Geschwindigkeit eines Ökosystems, das viele gegenseitige Abhängigkeiten enthält. Die Weiterentwicklung der beiden grossen Monolithen Infomaniak Manager und Infomaniak Legacy ist komplex, da sie sich auf alle unsere Dienste auswirken. Doch nach der laufenden Überarbeitung (Hosting V3) werden wir mehrere Microservices haben, die einfacher zu aktualisieren sein werden.

Eine monolithische Architektur ist vergleichbar mit einem Gebäude: Wird die Heizung ausgetauscht, wirkt sich das auf das gesamte Gebäude aus. Microservices hingegen sind wie Einfamilienhäuser: Wird die Heizung ausgetauscht, bleiben die benachbarten Häuser davon unberührt. Matthieu Mabillard, Team Lead Developer

…zur Multirepo-Architektur mit Hosting V3

Hosting V3 verkörpert eine grundlegende Überarbeitung unserer Architektur. Besonderheiten der neuen Architektur:

• Zunächst ist festzustellen, dass der Frontend-Teil der Hostingdienste nunmehr vom Infomaniak Manager abgekoppelt wurde, um die Weiterentwicklung zu erleichtern.
• Hosting Legacy übernimmt und isoliert den bisherigen Code des alten Monolithen Infomaniak Legacy. Dieser Code wird in einen Microservice umgewandelt, um die Pflege zu erleichtern, aber er wird nicht komplett neu geschrieben.
• Der Proxy übersetzt die Authentifizierung der Kundin bzw. des Kunden gegenüber dem Manager, um ihr / ihm benutzerdefinierte sichere Zugriffe zu ermöglichen. Dies ist der Ausgangspunkt aller Interaktionen.
• API Hosting enthält den neuen Code der neuen Hostingplattform Hosting V3. Seine Aufgabe besteht darin, Informationen an Infomaniak Legacy General oder Legacy Hosting API weiterzuleiten, wenn er feststellt, dass die Anfragen Funktionen entsprechen, die nicht neu entwickelt wurden.
• Die Verwaltung von SSL-Zertifikaten (SSL Certificates) ist in einem Microservice isoliert, um die Weiterentwicklung und Integration in sämtliche Dienste zu vereinfachen.
• Infomaniak Legacy enthält wie bisher die Abhängigkeiten des Infomaniak-Monolithen für bereichsübergreifende Funktionen.
• Auch der Microservice für die Nutzerauthentifizierung (OAuth2.0) bleibt unverändert.
• Ebenfalls enthalten ist der Microservice Infomaniak Core, der mehrere Funktionen wie das Abrufen des Profils eine Nutzerin bzw. eines Nutzers vereint.

Diese Aufteilung in Microservices ermöglicht, Abhängigkeiten zwischen Microservices zu verringern und die technische Schuld in den Griff zu bekommen. Wir haben die volle Kontrolle über die Bereitstellung und den Lebenszyklus unseres Codes – ob der neue Code oder der Legacy Code. Dieser Ansatz ermöglicht uns, ein hybrides Modell einzusetzen, das Tempo und Skalierbarkeit in einem bietet.

Besonders geeignet ist diese Architektur für Umgebungen mit stark verteilter Ausführung. Sie bietet eine hohe Resilienz, eine hohe Redundanz und eine ausgeprägte Anpassungsfähigkeit an Lastschwankungen. Matthieu Mabillard, Team Lead Developer

Von Monorepo zu Multirepo: Gute Vorbereitung der Teams gefragt

Im Rahmen dieser Umstellung setzen wir Massnahmen um, um die Annahme gemeinsamer Standards zwischen den Teams zu fördern und den Austausch zwischen Fachleuten zu intensivieren, und zwar mit:

• Hierarchieübergreifenden Expertengruppen, die den Erfahrungsaustausch zwischen Fachleuten über die Entwicklungsebene hinweg ermöglichen. Diese sprechen über Themen wie APIs, DevOps, Laravel und Angular.
• Qualitätsrichtlinien, um die Abläufe zwischen den Teams mit standardisierten Kriterien zu harmonisieren. Dieser Aspekt hängt mit unseren Normen ISO 9001, ISO 14001 und ISO 50001 zusammen.
• Der Förderung des Verantwortungsbewusstseins der Team Leads, die die operative Leitung aller Microservices in ihrem Team haben. Dies stärkt die Eigenständigkeit und Eigenverantwortung der Teams. Die technische Leitung wird hierdurch entlastet und kann sich voll und ganz auf Strategie, Technologien, die Implementierung bewährter Praktiken, Supervision und Betreuung konzentrieren.
• Einführung von Analysetools (SonarQube, Renovate, Gitlab CI), um alle generierten Einträge im Auge zu behalten und in der Lage zu sein, den Zustand der Repositories insgesamt zu überwachen.

3. Monorepo oder Multirepo: Strategische Entscheidung für das Unternehmen

Die Methode des Codemanagements hat weitreichende Auswirkungen, die sich nur schwer rückgängig machen lassen. Folglich bedürfen Entscheidungen und Strategien reiflicher Überlegung.

Vorteile des Multirepo-Ansatzes

Im Zusammenhang mit der zukünftigen Hostingplattform ermöglicht der Multirepo-Ansatz den Einsatz neuester Technologien, ohne auf weitere Projekte des Unternehmens warten zu müssen. Auch die Rechteverwaltung ist präziser: Der Zugriff auf die Codebasis wird akkurat kontrolliert, auch beim Lesen. Es ist klar geregelt, wer was tut. Das erleichtert die Übertragung der Verantwortung für einen Microservice von einem Team auf das andere und sogar die Umstrukturierung des DEV-Bereichs.

Die Multirepo-Architektur ermöglicht den Teams, sich stärker zu spezialisieren, indem die Verantwortlichkeiten eindeutig aufgeteilt und jedem Projekt spezifische Technologien zugewiesen werden. Matthieu Mabillard, Team Lead Developer

Die Teams werden eigenständiger: Die Aufteilung der Verantwortlichkeiten erhöht die Effizienz der Teams, die sich auf ihren eigenen Microservice konzentrieren können, da ihr Repository unabhängig von anderen ist. Das bedeutet mehr Unabhängigkeit in Bezug auf:

• Lebenszyklus,
• spezifische Rekrutierung,
• Technologiewahl.

Auch das Experimentieren mit neuen Projekten ist einfacher: Multirepo beschleunigt die Entwicklung sogenannter Proofs of Concept (POC), die unabhängig von anderen Branchen entstehen können. So kann die Machbarkeit einer Idee rasch validiert werden. Das Tempo ist bei jedem Projekt anders: Jede Abteilung des Hostingteams kann ihren Entwicklungszyklus beschleunigen oder optimieren und ihre eigenen Akzeptanzkriterien festlegen, ohne von den potenziellen Auswirkungen auf andere gebremst zu werden.

Multirepo vereinfacht Open-Source-Beiträge: Der Basiscode wird reduziert, und die Segmentierung der Dienste ermöglicht, bestimmte Teile des Codes zu veröffentlichen und andere nicht, etwa aus Gründen der Sicherheit oder des Schutzes des industriellen (Betriebs-)Geheimnisses.

Dies beschleunigt Entwicklungszyklen: Die Umsetzung erfolgt schneller als bei unseren Monorepo-Projekten. Beim Hosting V3 wird jede Komponente entkoppelt, während der Build des Webmail als Monorepo länger ist.

Das kann auch grossen Einfluss auf die Einstellung haben:

Attraktive Technologiestacks mit angemessener Lernkurve sind ein entscheidender Faktor, um Talente anzuziehen. Niemand begeistert sich für Unternehmen, das die technische Schuld durch Technologien erhöht, die nirgendwo gelehrt werden. Julien Viard, VP of Engineering bei Infomaniak

Die Grenzen eines Multirepo-Ansatzes

Multirepo erfordert mehr Rigorosität, um die Entwicklung eines Microservice mit anderen zu synchronisieren:

• Die Abhängigkeiten seines Projekts müssen systematisch aktualisiert werden, damit ihm die Verbesserung der Qualität des Codes der Unterprogramme oder Fehlerkorrekturen usw. zugutekommen, indem die richtige Bibliothek, der richtige Code-Abschnitt usw. verwendet wird. So muss sichergestellt sein, dass zwei APIs einen gemeinsamen Sockel behalten, wenn sie ähnlich funktionieren und denselben Microservice für die Authentifizierung nutzen.
• Die Implementierung von Integrationstests ist komplexer und erfordert Szenarien, in denen mehrere Microservices miteinander kommunizieren können. Auch wenn eine Kundin bzw. ein Kunde beispielsweise eine einzige Aktion ausführt, um eine Website zu erstellen, löst dies seitens des Hostings drei Aktionen aus: SSL-API, Vorschaubild, Hosting API.
• Da der Code segmentiert ist, sind die Rückverfolgbarkeit und ständiges Feedback in Bezug auf den gesamten Code schwieriger.
• Die Granularität erschwert die Problemerkennung, da jeder Microservice einzeln überprüft werden muss. Einfacher ist hingegen die Handhabung, da durchzuführende Korrekturen häufig besser eingegrenzt sind.
• Schliesslich erfordert die Aufrechterhaltung der Synergie zwischen Technologien, Bibliotheken und Entwicklungspraktiken mehr Fachkenntnisse.

4. Monorepo oder Multirepo: Welches ist die richtige Wahl für Ihre Entwicklerteams?

Diese Entscheidung erfordert einen internen Reflexionsprozess zu mehreren Aspekten:

• Wie sieht Ihr Firmenprofil aus? Für ein Start-up mit kurzer Time-to-Market ist es nicht einfach, eine lange Microservice-Architektur einzuführen. Oft geht es darum, ein Produkt so schnell wie möglich zu lancieren und damit in strategischer Hinsicht die Lösung zu wählen, die das höchste Entwicklungstempo ermöglicht.
• Welches Tempo brauchen Sie?
• Wie ist es um Ihre aktuellen technischen Fähigkeiten bestellt? Auch wenn das Unternehmen viele Expertinnen und Experten mit hohem technischen Niveau hat, wird es eine andere Wahl treffen als ein Unternehmen, dessen Team eher allgemein orientiert und vielseitig ist und über breitere Technologiekompetenzen verfügt.

Hier sind weitere Fragen, die bei der richtigen Entscheidung helfen können:

• Wie sollen sich Ihr Code und Ihre Entwicklungsteams mittelfristig entwickeln?
• Welches sind die internen Stärken Ihrer Organisation?
• Wie sieht es mit Ihren Bedürfnissen in puncto Ressourcen und Rekrutierung aus?
• Ist ein dediziertes Team erforderlich?

Unter Berücksichtigung der Abstimmung zwischen den Kompetenzen, den Mitteln und der Phase, in der sich Ihr Unternehmen befindet, sollten Sie nun mehr Klarheit bei der Wahl der bestmöglichen Architektur für Ihre Weiterentwicklung haben. Diskutieren Sie mit uns auf X oder Linkedin und beziehen Sie sich auf diesen Artikel.