Ich bin kein ausgewiesener DevOps-Experte, aber ich kann Ihnen sagen, dass wir bei CodePen wieder auf ein Monorepo umstellen und dass dies viele Vorteile gegenüber einem System mit vielen kleineren Repos birgt. *Für uns*, versteht sich. Es ist sehr wahrscheinlich, dass Sie ganz andere Herausforderungen haben und bei sich zu ganz anderen Schlussfolgerungen gekommen sind. 🤙
Ich dachte darüber nach, nachdem ich Ben Nadels „Warum ich Microservices bei InVision wieder in den Monolithen zurückgeführt habe.“ gelesen hatte. Obwohl unsere Schlussfolgerungen ähnlich sind, kann ich sagen, dass er mit ganz anderen Problemen konfrontiert ist.
Microservices lösen sowohl technische als auch menschliche Probleme
Ein technisches Problem ist eines, bei dem ein Aspekt der Anwendung die Infrastruktur übermäßig belastet; was wiederum wahrscheinlich zu einer schlechten Benutzererfahrung (UX) führt. Zum Beispiel erfordert die Bildverarbeitung viel CPU-Leistung. Wenn diese CPU-Auslastung zu hoch wird, kann dies den Rest der Anwendung von den Verarbeitungsressourcen absaugen. Dies könnte die Systemlatenz beeinflussen. Und wenn es schlimm genug wird, könnte es die Systemverfügbarkeit beeinträchtigen.
Ein menschliches Problem hingegen hat wenig mit der Anwendung selbst zu tun, sondern viel damit, wie Ihr Team organisiert ist. Je mehr Leute an einem bestimmten Teil der Anwendung arbeiten, desto langsamer und fehleranfälliger werden Entwicklung und Bereitstellung. Wenn zum Beispiel 30 Ingenieure darum wetteifern, denselben Dienst „kontinuierlich bereitzustellen“ (CD), kommt es zu viel Stau; das bedeutet, dass viele Ingenieure, die andernfalls Produkt versenden könnten, tatsächlich herumsitzen und auf ihre Bereitstellung warten.
Vorteile des Monorepos (für uns)
- Ein Ring, sie alle zu knechten. Sie führen
git pullin *einem* Repo aus und sind 100% auf dem neuesten Stand mit allen anderen und haben alles, was Sie für eine vollständige Entwicklungsumgebung benötigen. - Keine verirrten Welpen. Es gibt keine Verwirrung darüber, wo die Aktion auf GitHub stattfindet. Sie erstellen Pull-Requests gegen das Monorepo. Sie öffnen Issues im Monorepo. Dies vermeidet verstreute Aktivitäten, die verloren gehen.
- Kumbaya. Sie können Code teilen. Es kann besonders hilfreich sein, Dienstprogramme oder Komponenten überall in der Codebasis zu teilen. Wir haben Ideen wie das Veröffentlichen von gemeinsam genutzten Teilen für npm, die von anderen Repos verwendet werden können, in Betracht gezogen, aber dieser Workflow war umständlich, verglichen damit, den Code an einem Ort zusammenzuhaben.
- Gemeinsam alt werden. Es gibt keine alten und vernachlässigten Repos, denn es ist nur eins. Für unser kleines Team bedeutete die Haltung von Dutzenden von Repos, dass einige von ihnen veraltete Abhängigkeiten, alte Node-Versionen, Linting- und Formatierungsregeln hatten, die nicht mit anderen Repos synchronisiert waren usw.
Nachteile des Monorepos (für uns)
- Tückische Bereitstellung. Ich denke, der Hauptgrund, warum wir ursprünglich Repos aufgeteilt haben, war, dass der Code in diesen Repos an einzigartige Orte gelangen musste. Sie repräsentierten möglicherweise eine einzelne Lambda oder einen einzelnen Dienst auf einem anderen Server. Ein einzelnes Repo macht es einfacher, Dinge anzuhängen, die für diesen Server/Dienst einzigartig sind, wie CI/CD.
Ja, ich verstehe, dass das umstritten ist.
Ich kümmere mich tatsächlich nicht *so* sehr darum. Ich werde nicht so intensiv darüber reden wie Leute, die Heißluftfritteusen lieben, und CrossFit-Fanatiker. Hier ist ein leidenschaftliches Plädoyer *gegen* Monorepos von Matt Klein.
Ich sage nur: Für uns war es eindeutig nützlich. Ich kann sehen, wie sich die Dinge für andere Unternehmen anders entwickeln. Ich kann mir vorstellen, dass ein Unternehmen, das mit Auftragnehmern zusammenarbeitet, deren Zugriff auf etwas weniger als ein ganzes Monorepo beschränken möchte. Ich kann mir vorstellen, dass ein Git-Repo unhandlich und groß wird. Das sind für uns bei CodePen im Moment keine Probleme, daher überwiegen die Vorteile eines Monorepos.
Es ist wirklich interessant, dass Sie den Unterschied in den Vorteilen eines Monorepos hervorheben. Ich benutze seit über 3 Jahren ein Monorepo als Solo-Entwickler und möchte nie zurück. Der Hauptvorteil für mich war die Geschwindigkeit, mit der ich ein neues Projekt starten konnte. Ich hatte so viele Ideen, aber ich bevorzuge einen sehr spezifischen Workflow, der sich ständig weiterentwickelt. Jedes Mal alles neu einzurichten und die Qualität des Engineerings aus dem Gleichgewicht zu bringen, war ein Albtraum, wenn man zu Projekten zurückkehrte.
Wie Sie jedoch erwähnt haben, sind unterschiedliche Projekttypen wahrscheinlich die schwierigsten Probleme, die es zu lösen gilt. Als ich mein Monorepo startete, schrieb ich mein eigenes CI/CD-Tool, das auf der Struktur basierend erkennen konnte, um welchen Projekttyp es sich handelte, und es je nach Struktur unterschiedlich bauen und bereitstellen konnte. Es berücksichtigt auch, wie jedes Projekt von Abhängigkeiten her miteinander verbunden ist. Es verwendet ein Plugin-System, sodass ich, wenn ich einen neuen Projekttyp abdecken möchte, ein Plugin dafür schreiben kann.
Es war eine ziemliche Erfahrung, das Monorepo zu nutzen und enorme Gewinne bei der schnellen Erstellung von Projekten und insbesondere bei der Refaktorierung zu erzielen. Ich glaube nicht, dass ich jemals zurückgehen werde. Es ist so schön, wenn mein Tool bemerkt, wenn ich ein einzelnes Modul ändere, das eine Abhängigkeit von sagen wir 4 anderen ist, und es jedes dieser automatisch bereitstellt. Das macht Refaktorierung zu einer nicht so beängstigenden Aufgabe, da ich nie wissen muss, was betroffen ist. Der Schlüssel liegt darin, gute Testpraktiken beizubehalten. Daran arbeite ich im Laufe der Zeit weiterhin.
Wirklich eine großartige Lektüre und Perspektive, besonders von anderen Oregoniern.
Ich mag die Unterscheidung zwischen der Verwendung von Microservices zur Lösung technischer Probleme und der Verwendung von Microservices zur Lösung menschlicher Probleme. Ich persönlich sehe die Verwendung von Microservices zur Lösung menschlicher Probleme als den glücklichen Weg und die Verwendung von Microservices zur Lösung technischer Probleme eher als einen Sonderfall. Ich habe jedoch den Eindruck, dass die Erfahrungen der meisten Entwickler das Gegenteil sind.
Monorepo war auch für uns sehr hilfreich, alles wurde so vereinfacht und schnell.
Außerdem haben wir das Bereitstellungsproblem gelöst, indem wir während des Builds ein separates Binärverzeichnis für jeden Microservice erstellt haben und dann ein Bereitstellungsskript verwendet haben, das n Bereitstellungen anstelle von 1 während des CD durchführt.
Ich bin neugierig, warum Sie die Versionsverwaltung von Abhängigkeiten nicht erwähnen. Das wird normalerweise als Hauptvorteil des Monorepos angepriesen: Es gibt keinen Bedarf, Versionen zu verwalten (Versionen hochzählen, Abhängigkeiten aktualisieren usw.). Hat sich in dieser Hinsicht etwas für Sie geändert?
Es fühlt sich an, als wäre das manchmal eine Ursache für Schmerzen. Zum Beispiel haben wir Lerna verwendet, um Dinge über Unterprojekte hinweg zu teilen. Aber das verursachte Probleme mit Abhängigkeiten, die seltsame Konflikte hatten. Wie eine React-Komponente in einer Designsystem-Bibliothek, die eine bestimmte React-Version verwendet, und dann ein Unterprojekt in Next.js, das eine andere React-Version verwendet und es schwer nachzuverfolgen war. Yarn Workspaces hat einen Teil davon gelöst. Aber ja, ich würde sagen, insgesamt ist es irgendwie schön, ein Repo zu haben, in dem man sich um das Hochzählen von Chore-Versionen kümmert.