De monòlit a microserveis: guia pràctica per a CTOs de startups en creixement
El teu monòlit t'ha portat fins aquí. Va permetre que un equip petit anés per feina: desplegar amb un sol pipeline i depurar amb un stack trace en lloc de resseguir logs per cinc serveis diferents. Va funcionar. I si vas seguir els principis d'un monòlit modular ben dissenyat, et va donar una base sòlida.
Però ara alguna cosa ha canviat. Tens tres equips treballant sobre el mateix repositori i els conflictes de merge són constants. El mòdul de processament de pagaments no escala igual que el de notificacions. Un desplegament que hauria de tardar deu minuts en tarda una hora perquè demana coordinació entre equips. Un bug al mòdul de reporting bloqueja el release d'una funcionalitat de facturació que fa una setmana que és a punt.
Aquests senyals són reals — els he vist tots, un per un, en equips de producció. I la resposta no és «reescrivim-ho tot en microserveis aquest trimestre». La resposta és evolucionar gradualment.
Quan és realment el moment de migrar
No migres perquè els microserveis estiguin de moda. Migres perquè el monòlit s'ha convertit en un coll d'ampolla per al teu negoci. Aquests són els senyals concrets:
Diversos equips que es trepitgen. Dos equips toquen el mateix codi, els PRs es bloquegen els uns als altres, i cada merge demana una coordinació que costa més que el desenvolupament mateix. Aquí entra la llei de Conway: la teva arquitectura ha d'acabar reflectint la teva organització.
Necessitats d'escalat divergents. L'API de cerca ha d'escalar horitzontalment amb el tràfic d'usuaris, però el servei de processament de fitxers necessita màquines amb més RAM i CPU. Escales tot el monòlit per satisfer el component més exigent, i pagues una infraestructura que la resta no necessita.
Desplegaments massa llargs i massa arriscats. Un canvi de tres línies obliga a desplegar tota l'aplicació. El pipeline de CI tarda 45 minuts. I cada desplegament es viu amb angoixa, perquè qualsevol part del sistema es pot trencar.
Una fallada ho fa caure tot. Un memory leak al mòdul de reporting s'endú per davant l'API de clients, el dashboard d'administració i el sistema de facturació. No hi ha aïllament de fallades.
Si d'aquests senyals en reconeixes dos o més, és hora de planificar la migració. Si només en veus un, probablement pots resoldre el problema amb una millor modularització interna.
El Strangler Fig Pattern: no reescriguis, extreu
La metàfora ve de la figuera escanyadora, una planta que creix al voltant d'un arbre fins que acaba substituint-lo del tot. El teu monòlit és l'arbre. Els serveis nous són la figuera. I la clau és que l'arbre continua viu mentre la figuera creix.
No reescrius el monòlit. Extreus serveis d'un en un, gradualment, amb el monòlit encara funcionant en producció. Cada extracció és un pas petit i controlat. Si alguna cosa va malament, el monòlit continua sent-hi com a fallback.
Pas 1: Identifica els límits
Abans d'extreure res, necessites un mapa clar dels mòduls del teu monòlit i les seves dependències. Si vas dissenyar un monòlit modular amb bounded contexts ben definits, aquesta part és més senzilla. Si no, ara és el moment de fer-ho.
Busca les costures naturals: mòduls que es comuniquen amb la resta a través d'interfícies clares, que tenen el seu propi model de dades, que representen un domini de negoci propi. En termes de Domain-Driven Design, el que busques són bounded contexts.
Dibuixa el graf de dependències. Identifica quins mòduls depenen de quins. Els que tenen menys dependències entrants i sortints són els candidats més fàcils per a l'extracció.
Pas 2: Extreu primer el mòdul que fa més mal
No comencis pel mòdul més fàcil ni pel més difícil. Comença pel que fa més mal. Normalment és el que compleix una o més d'aquestes condicions:
- No escala igual que la resta del sistema.
- Canvia amb molta freqüència i genera conflictes amb altres equips.
- Té requisits tecnològics diferents (necessita GPUs, una base de dades diferent, un runtime específic).
- Les seves fallades afecten desproporcionadament la resta del sistema.
Extreu aquest mòdul com a servei independent. Desplega'l per separat. Dona-li el seu propi pipeline de CI/CD. Assigna-li un equip que en sigui el propietari.
Pas 3: Posa-hi un API gateway o un reverse proxy al davant
Aquí és on actua la màgia del Strangler Fig. Col·loques un API gateway (Kong, NGINX, AWS API Gateway, Traefik) davant de tot el sistema. Les peticions que abans anaven directes al monòlit ara passen pel gateway.
El gateway decideix: aquesta petició va al servei nou, aquesta altra continua anant al monòlit. Pots fer el canvi gradualment — comences enviant el 5% del tràfic al servei nou, monitores, i puges progressivament fins al 100%.
Si el servei nou falla, el gateway pot tornar a enviar el tràfic al monòlit. Migració sense risc existencial.
Pas 4: Mou les dades (la part més difícil)
Aquí és on es compliquen la majoria de migracions. Mentre el servei nou continuï llegint i escrivint a la mateixa base de dades que el monòlit, no tens un microservei de debò — tens un monòlit distribuït, que és el pitjor dels dos mons.
L'objectiu és que cada servei tingui la seva pròpia base de dades. El camí per arribar-hi:
- Dual writes. El servei nou escriu a la seva pròpia base de dades I a la del monòlit durant un període de transició. Verifiques que les dades són consistents.
- Sincronització per esdeveniments. Introdueixes un sistema d'esdeveniments (Kafka, RabbitMQ, SNS/SQS) per mantenir sincronitzades les dades entre el servei i el monòlit.
- Cutover. Quan confies que el servei nou és la font de veritat, deixes d'escriure a la base de dades del monòlit. Els altres mòduls que necessitin aquestes dades les obtenen a través de l'API del servei nou o en consumeixen els esdeveniments.
Accepta que hi haurà un període d'eventual consistency. No intentis mantenir transaccions ACID entre serveis — aquest camí porta a distributed transactions i two-phase commits, que són fràgils i lents.
Pas 5: Repeteix
Extreu el servei següent. I el següent. Cada extracció hauria de ser cosa de setmanes, no de mesos. Si una extracció se t'allarga tres mesos, probablement estàs extraient un mòdul massa gran, o les dependències no eren tan netes com et pensaves.
Amb cada extracció, el monòlit es fa més petit i més manejable. Al final, el que queda és un servei més — o es descompon de manera natural en els últims dos o tres serveis.
Els microserveis comporten un impost d'infraestructura
Els microserveis no són només codi en repositoris separats. Necessiten una infraestructura de suport que al teu món monolític no existia:
Service discovery. Els serveis necessiten trobar-se entre si. Consul, DNS intern de Kubernetes, o el service discovery del teu cloud provider.
Logging centralitzat. Amb deu serveis, no pots fer SSH a cada màquina per llegir logs. Necessites ELK Stack, Datadog, Grafana Loki — un únic lloc on convergeixin tots els logs.
Distributed tracing. Una sola petició d'usuari pot tocar cinc serveis. Sense tracing (Jaeger, Zipkin, Datadog APM), depurar un error és jugar a endevinar quin servei l'ha causat. Implementa OpenTelemetry des del primer servei.
CI/CD per servei. Cada servei té el seu propi pipeline. Canvies el servei de pagaments, només es desplega el servei de pagaments. GitHub Actions, GitLab CI o l'eina que facis servir, però independent per servei.
Monitoratge i alertes. Health checks, mètriques de latència, taxes d'error, saturació de recursos — per servei. Si no pots veure l'estat de cada servei en un dashboard, navegues a cegues.
Els errors que converteixen una migració en una reescriptura
No ho extreguis tot alhora. La temptació de «fer la migració completa en un trimestre» és forta. Resisteix-la. Cada extracció és un risc controlat. Deu extraccions simultànies són el caos.
No creïs nano-serveis. Un servei amb un sol endpoint i 200 línies de codi no hauria de ser un servei. Té tot l'overhead operatiu d'un microservei i cap dels beneficis. Un servei ha de representar un domini de negoci que s'aguanti sol.
No comencis pel mòdul més acoblat. Si el mòdul d'usuaris està entortolligat amb tot el sistema, és el pitjor candidat per a la primera extracció. Comença per un mòdul amb menys dependències.
No t'oblidis del monitoratge. Cada servei que extreus sense un monitoratge com cal és una caixa negra en producció. Primer l'observabilitat; després, l'extracció.
Estructura d'equips: cada servei necessita un propietari
Un microservei sense equip responsable és un servei orfe. I els serveis orfes acumulen deute tècnic a un ritme alarmant, perquè ningú no se'n sent responsable.
Cada servei necessita un equip que en sigui el propietari clar. Aquest equip en decideix el roadmap, en gestiona els desplegaments i respon quan el servei cau a les tres de la matinada. No cal que sigui un equip dedicat exclusivament a aquell servei — un equip pot ser propietari de dos o tres serveis relacionats. Però la propietat ha de ser explícita.
Això és exactament el que descriu la maniobra inversa de Conway: dissenyes l'arquitectura perquè reflecteixi l'estructura d'equips que vols tenir. Si vols equips autònoms que despleguin pel seu compte, necessites serveis que es puguin desenvolupar i desplegar de manera independent.
La migració és un procés, no un projecte
La migració de monòlit a microserveis no té data de finalització en cap diagrama de Gantt. És un procés continu que evoluciona amb la teva organització. Extreus serveis quan el dolor ho justifica, no perquè un pla digui que toca.
A Conectia treballem amb startups europees que són exactament en aquest punt: el monòlit els ha servit per arribar al product-market fit, i ara necessiten fer evolucionar l'arquitectura per escalar. Els enginyers sèniors i els arquitectes de LATAM que posem als seus equips han guiat aquesta transició unes quantes vegades — saben què cal extreure primer, com esquivar els errors clàssics de les migracions distribuïdes i com fer-ho tot sense aturar el lliurament de funcionalitats.
Perquè aquesta és la clau: el teu negoci no es pot aturar mentre migres. Els usuaris continuen fent servir el producte. L'equip de producte continua demanant funcionalitats. La migració ha de conviure amb tot això. I això demana enginyers que ja ho hagin fet abans.
El teu monòlit s'està convertint en un coll d'ampolla? Parla amb un CTO — et connectem amb arquitectes sèniors que han guiat aquesta transició sense aturar el lliurament.
