Monolith-Aufteilung
Monolith zu Microservices: der erste Service live bis Tag 20
Vierhundert Tabellen in einem Schema und ein Release-Zug, der einmal im Quartal abfährt, weil niemand einen Teil allein deployen kann. Ingenieure mit über 25 Jahren Praxis teilen ihn auf: der erste Service live bis Tag 20, der Rest bis Tag 30.
Schicken Sie heute Repo-Größe und Release-Takt. Nach 48 Stunden wissen Sie, wo die Nähte liegen und was es kostet.
Ein Repository, ein Schema, ein Release pro Quartal und Imports, die im Kreis laufen.
- one deployable11 years of commits
- shared schema400+ tables
- release trainquarterly
- circular importscycles
Erster Service bis Tag 20, Aufteilung fertig bis Tag 30
Services mit eigenen Schemas und Pipelines, eine kleine gemeinsame Bibliothek, Deploys, wann immer ein Team bereit ist.
- billingGo · own schema
- catalogueGo · own schema
- shared kernellibrary
- deploysper service
Erst wird das Schema geteilt, dann zieht der Code um
- 01Tag 1–4
Die Nähte in den Daten finden
Abfragelogs zeigen, welche Tabellen in derselben Anfrage zusammen gelesen werden. Dort liegen die Grenzen, egal was die Paketstruktur behauptet.
- 02Tag 3–9
Zuerst das Schema teilen
Tabellen werden getrennt und Joins über Grenzen hinweg entfernt, solange alles noch ein Deployable ist. Das meiste Risiko steckt in diesem Schritt, und hier lässt er sich noch umkehren.
- 03Tag 8–20
Den ersten Service herauslösen
Wir nehmen den mit den wenigsten eingehenden Abhängigkeiten, und das ist selten der, der am meisten nervt. Bis Tag 20 läuft er produktiv hinter derselben Schnittstelle.
- 04Tag 18–30
Eigene Pipeline, dann der nächste
Der Service bekommt eigenes Repository, eigenes Deployment und eigene Rufbereitschaft. Die nächsten folgen nach derselben Methode schneller, und ab Tag 30 releasen Ihre Teams, ohne auf einen Zug zu warten.
Die Plattform misst, Ingenieure wählen den Schnitt
Gemeinsame Tabellenzugriffe und Modulkopplung kartieren
Plattform
Aus Abfragelogs und Aufrufgraph, über einen Zeitraum, der lang genug ist, um das Monatsende einzuschließen.
Die Nähte vorschlagen
Gemeinsam
Die Plattform sortiert die Kandidaten. Ein Ingenieur prüft jeden gegen Ihre Teamgrenzen.
Joins über Grenzen hinweg auflösen
Plattform
Mechanische Arbeit, geprüft als Pull Requests, ausgeliefert in kleinen Stücken, denen Ihr Team folgen kann.
Wählen, welcher Service zuerst geht
Ingenieur
Das entscheidet häufiger die Teamzuständigkeit als der Code.
Transaktionsgrenzen
Ingenieur
Wo früher eine Transaktion über die Naht lief, legen wir fest, was bei einem Fehler passiert, und schreiben es auf.
Pipelines, Deploys und Rufbereitschaft
Gemeinsam
Jede Pipeline und jeden Dienstplan bauen wir mit Ihrem Team, damit es die Services ab dem ersten Deploy selbst betreibt.
Eine Naht sitzt richtig, wenn die meisten Änderungen nach der Aufteilung nur eine Seite berühren. Das messen wir, bevor wir die Arbeit für erledigt erklären.
Die Leute, die die Naht schneiden
Unsere Ingenieure liefern seit mehr als 25 Jahren Produktivcode, und für diese Aufteilung finden Sie keine besseren. Monolithen in Rails, Django, Spring, .NET, Node, PHP und Go, Schemas mit vierhundert Tabellen und einem Jahrzehnt an Joins über Grenzen hinweg: Dutzende Migrationen. Die Naht liegt nie da, wo das Architekturdiagramm sie einzeichnet, und sie finden die echte.
Festpreis vor dem ersten Schnitt, und der Tag, an dem der erste Service eigenständig deployt, steht im Vertrag. Ein Service, der auf Ihrem Traffic nicht dasselbe liefert wie der Monolith, wird nicht abgenommen.
Was Engineering-Leads vor einer Aufteilung fragen
Wie viele Services sollten wir am Ende haben?
So viele, wie Sie Teams haben, die sie verantworten, und das sind weniger, als das Architektur-Deck zeigt. Wir lösen den ersten heraus, betreiben ihn produktiv, und die Daten zeigen, wo der nächste Schnitt hingehört. Schicken Sie heute das Repo, und in 48 Stunden haben Sie die Nahtkarte mit Preis.
Müssen wir in Go neu schreiben?
Nur wo es sich rechnet. Herauslösen und Neuschreiben sind getrennte Entscheidungen, und viele Services bleiben in ihrer ursprünglichen Sprache. Wo der Monolith auf Java oder Python Speicher verbrennt, senkt eine Go-Neuschreibung die Instanzrechnung im selben Zeitplan. Sagen Sie uns, welche Module im Betrieb am meisten kosten.
Können wir während der Aufteilung weiter Features liefern?
Ja. Der Schritt, den wir schützen, ist die Schematrennung an Tag 3–9, und Ihren Release-Kalender planen wir gemeinsam darum herum. Alles andere bewegt sich, während Ihr Team ausliefert. Schicken Sie Ihren Release-Takt, und wir passen den Plan daran an.
Und die gemeinsame Datenbank, vor der alle warnen?
Genau deshalb wird zuerst das Schema geteilt. Zwei Services auf einem Schema sind ein verteilter Monolith, der schlimmer ausfällt als das, womit Sie angefangen haben, und so etwas liefern wir nie aus. Fordern Sie ein Angebot an und sehen Sie den Schemaplan, bevor Code umzieht.
Was wird aus gemeinsam genutztem Code?
Er wird eine versionierte Bibliothek mit kleiner Oberfläche. Wächst diese Bibliothek mit jedem Sprint, sitzt die Naht an der falschen Stelle, und wir verschieben sie noch im Projekt, solange es billig ist. Schicken Sie das Repo, und wir zeigen Ihnen in 48 Stunden die Nähte.
Bringen Sie Ihren ersten Service raus
Geben Sie uns Repo-Größe, Release-Takt und das, was die Änderung erzwingt. Nach 48 Stunden haben Sie die Nähte, einen Festpreis und einen Termin. Bis Tag 20 deployt der erste Service eigenständig.
Ein Ingenieur mit über 25 Jahren Produktionserfahrung liest das Formular. Die erste Frage betrifft Ihren Release-Takt.