découpe du monolithe
Du monolithe aux microservices : premier service en ligne au jour 20
Quatre cents tables dans un seul schéma, et un train de livraison qui part une fois par trimestre parce que personne ne peut déployer une partie seule. Des ingénieurs avec 25+ ans de production le découpent : premier service au jour 20, le reste au jour 30.
Envoyez la taille du dépôt et le rythme de livraison aujourd'hui. En 48 heures, vous savez où sont les coutures et ce que ça coûte.
Un dépôt, un schéma, une livraison par trimestre, et des imports qui tournent en rond.
- one deployable11 years of commits
- shared schema400+ tables
- release trainquarterly
- circular importscycles
Premier service au jour 20, découpe terminée au jour 30
Des services avec leur propre schéma et leur pipeline, une petite bibliothèque partagée, des déploiements dès qu'une équipe est prête.
- billingGo · own schema
- catalogueGo · own schema
- shared kernellibrary
- deploysper service
Le schéma se sépare d'abord, le code bouge ensuite
- 01jours 1–4
Trouver les coutures dans les données
Les journaux de requêtes montrent quelles tables sont lues ensemble dans la même requête. C'est là que sont les frontières, quoi qu'en dise l'arborescence des packages.
- 02jours 3–9
Séparer le schéma d'abord
Les tables se séparent et les jointures qui traversent les frontières disparaissent tant que tout est encore un seul déployable. L'essentiel du risque vit dans cette étape, et ici elle est encore réversible.
- 03jours 8–20
Extraire le premier service
Nous prenons celui qui a le moins de dépendances entrantes, rarement celui qui agace le plus. Il tourne en production derrière la même interface au jour 20.
- 04jours 18–30
Son propre pipeline, puis le suivant
Le service reçoit son dépôt, son déploiement et son tour d'astreinte. Les suivants vont plus vite avec la même méthode, et à partir du jour 30, vos équipes livrent sans attendre de train.
La plateforme mesure, les ingénieurs choisissent la découpe
Cartographier les accès croisés aux tables et le couplage des modules
Plateforme
À partir des journaux de requêtes et du graphe d'appels, sur une période assez longue pour inclure une fin de mois.
Proposer les coutures
Les deux
La plateforme classe les candidates. Un ingénieur vérifie chacune contre les frontières de vos équipes.
Casser les jointures entre frontières
Plateforme
Du travail mécanique, relu en pull requests, livré par petits morceaux que votre équipe peut suivre.
Choisir le service qui part en premier
Ingénieur
La propriété des équipes en décide plus souvent que le code.
Frontières transactionnelles
Ingénieur
Là où une transaction traversait la couture, nous décidons de ce qui se passe en cas d'échec et nous l'écrivons.
Pipelines, déploiements et astreinte
Les deux
Nous construisons chaque pipeline et chaque tour d'astreinte avec votre équipe, qui fait tourner les services dès le premier déploiement.
Une couture est juste quand la plupart des changements après la découpe ne touchent qu'un côté. Nous le mesurons avant de déclarer le travail terminé.
Ceux qui taillent la couture
Nos ingénieurs livrent du code en production depuis plus de 25 ans, et pour cette découpe vous ne trouverez pas mieux. Monolithes Rails, Django, Spring, .NET, Node, PHP et Go, schémas de quatre cents tables et dix ans de jointures entre frontières : des dizaines de migrations. La couture n'est jamais là où la place le schéma d'architecture, et ils trouvent la vraie.
Prix ferme avant la découpe, et le jour où le premier service se déploie seul entre au contrat. Un service qui ne reproduit pas le monolithe sur votre trafic n'est pas accepté.
Ce que demandent les leads techniques avant une découpe
Combien de services devrions-nous avoir à la fin ?
Autant que vous avez d'équipes pour les porter, soit moins que ce que montre la présentation d'architecture. Nous extrayons le premier, le faisons tourner en production, et les données montrent où passe la découpe suivante. Envoyez le dépôt aujourd'hui et recevez la carte des coutures chiffrée en 48 heures.
Faut-il tout réécrire en Go ?
Seulement là où ça rapporte. Extraire et réécrire sont deux décisions séparées, et beaucoup de services restent dans leur langage d'origine. Là où le monolithe brûle de la mémoire en Java ou en Python, une réécriture en Go réduit la facture d'instances dans le même calendrier. Dites-nous quels modules coûtent le plus cher à faire tourner.
Pouvons-nous continuer à livrer pendant la découpe ?
Oui. L'étape que nous protégeons est la séparation du schéma, jours 3–9, et nous calons votre calendrier de livraison autour avec vous. Tout le reste avance pendant que votre équipe livre. Envoyez votre rythme de livraison et nous y ajustons le plan.
Et la base partagée contre laquelle tout le monde met en garde ?
C'est pour ça que le schéma se sépare en premier. Deux services sur un même schéma forment un monolithe distribué qui casse de pires façons que ce que vous aviez au départ, et nous n'en livrons jamais. Demandez un devis et voyez le plan du schéma avant que le code bouge.
Que devient le code partagé ?
Il devient une bibliothèque versionnée avec une petite surface. Si elle grossit à chaque sprint, la couture est au mauvais endroit, et nous la déplaçons pendant le projet, tant que ça coûte peu. Envoyez le dépôt, nous vous montrons les coutures en 48 heures.
Sortez votre premier service
Indiquez-nous la taille du dépôt, le rythme de livraison et ce qui force le changement. En 48 heures, vous avez les coutures, un prix ferme et une date. Au jour 20, le premier service se déploie seul.
Un ingénieur avec 25+ ans de production lit le formulaire. Sa première question porte sur votre rythme de livraison.