De Monòlit a Microserveis: Una 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 lliurés ràpid, desplegués amb un sol pipeline i depurés amb un stack trace en comptes de rastrejar 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 necessita escalar de forma diferent al de notificacions. Un desplegament que hauria de tardar deu minuts en tarda una hora perquè cal coordinar entre equips. Un bug al mòdul de reporting bloqueja el release d'una funcionalitat de facturació que està llesta des de fa una setmana.
Aquests són senyals reals. 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:
Múltiples equips trepitjant-se entre si. Dos equips toquen el mateix codi, els PRs es bloquegen mútuament, i cada merge requereix coordinació que consumeix més temps que el desenvolupament en si. La llei de Conway comença a fer efecte: la teva arquitectura necessita reflectir la teva organització.
Necessitats d'escalat divergents. La teva API de cerca necessita escalar horitzontalment amb el tràfic d'usuaris, però el teu servei de processament d'arxius necessita màquines amb més RAM i CPU. Escales tot el monòlit per satisfer el component més exigent, pagant infraestructura que la resta no necessita.
Desplegaments massa llargs i arriscats. Un canvi de tres línies requereix desplegar tota l'aplicació. El pipeline de CI tarda 45 minuts. I cada desplegament és un esdeveniment que genera ansietat perquè qualsevol part del sistema pot trencar-se.
Una fallada ho trenca tot. Un memory leak al mòdul de reporting tira a terra l'API de clients, el dashboard d'administració i el sistema de facturació. No hi ha aïllament de fallades.
Si reconeixes dos o més d'aquests senyals, és moment de planificar la migració. Si només en veus un, probablement pots resoldre el problema amb 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 existent fins que eventualment el reemplaça per complet. El teu monòlit és l'arbre. Els nous serveis són la figuera. I la clau és que l'arbre segueix viu mentre la figuera creix.
No reescrius el monòlit. Extreus serveis un a un, gradualment, mentre el monòlit segueix funcionant en producció. Cada extracció és un pas petit i controlat. Si alguna cosa surt malament, el monòlit segueix allà 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, é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 diferent. En termes de Domain-Driven Design, estàs buscant 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 el mòdul de major dolor primer
No comencis pel mòdul més fàcil ni pel més difícil. Comença pel que més dolor causa. Normalment és el que compleix una o més d'aquestes condicions:
- Escala de forma diferent a 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 un 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 un API gateway o reverse proxy al davant
Aquí és on la màgia del Strangler Fig passa. Col·loques un API gateway (Kong, NGINX, AWS API Gateway, Traefik) davant de tot el teu sistema. Les peticions que abans anaven directes al monòlit ara passen pel gateway.
El gateway decideix: aquesta petició va al nou servei, aquesta altra segueix anant al monòlit. Pots fer el canvi gradualment — començar redirigint el 5% del tràfic al nou servei, monitoritzar, i pujar progressivament fins al 100%.
Si el nou servei falla, el gateway pot redirigir de tornada al monòlit. Migració sense risc existencial.
Pas 4: Mou les dades (la part més difícil)
Aquí és on la majoria de les migracions es compliquen. Mentre el teu nou servei segueixi llegint i escrivint a la mateixa base de dades que el monòlit, no tens un microservei real — 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 nou servei 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 events. Introdueixes un sistema d'events (Kafka, RabbitMQ, SNS/SQS) per mantenir sincronitzades les dades entre el servei i el monòlit.
- Cutover. Quan confies que el nou servei és la font de veritat, elimines l'escriptura 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 nou servei o consumeixen els seus events.
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 tardar setmanes, no mesos. Si una extracció et porta tres mesos, probablement estàs extraient un mòdul massa gran o les dependències no estaven tan clares com pensaves.
Amb cada extracció, el monòlit es fa més petit i més manejable. Eventualment, el que queda és un servei més — o es descompon en els últims dos o tres serveis de forma natural.
La infraestructura que necessites
Microserveis no són només codi en repositoris separats. Necessiten infraestructura de suport que no existia al teu món monolític:
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 lloc on tots els logs convergeixin.
Distributed tracing. Un request de l'usuari pot tocar cinc serveis. Sense tracing (Jaeger, Zipkin, Datadog APM), depurar un error és endevinar en quin servei es va originar. 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.
Monitorització 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, estàs navegant a cegues.
El que no has de fer
No extreguis tot alhora. La temptació de "fem la migració completa en un trimestre" és forta. Resisteix. Cada extracció és un risc controlat. Deu extraccions simultànies són caos.
No creïs nano-serveis. Un servei que només té un endpoint i 200 línies de codi no hauria de ser un servei. Té tot l'overhead operatiu d'un microservei sense cap benefici. Un servei ha de representar un domini de negoci amb sentit propi.
No comencis pel mòdul més acoblat. Si el mòdul d'usuaris està entrellaçat amb tot el sistema, és el pitjor candidat per a la primera extracció. Comença per alguna cosa amb menys dependències.
No oblidis el monitoratge. Cada servei que extreus sense monitoratge adequat és una caixa negra en producció. Primer observabilitat, després 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 velocitat alarmant perquè ningú se sent propietari de mantenir-los.
Cada servei necessita un equip que en sigui el propietari clar. Aquest equip decideix el seu roadmap, gestiona els seus desplegaments, respon quan falla a les tres de la matinada. No cal que sigui un equip dedicat exclusivament a aquest 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 llei de Conway invertida: dissenyes la teva arquitectura perquè reflecteixi l'estructura d'equips que vols tenir. Si vols equips autònoms que lliurin de forma independent, necessites serveis que es puguin desenvolupar i desplegar de forma independent.
La migració és un procés, no un projecte
La migració de monòlit a microserveis no té una data de fi en un Gantt chart. És un procés continu que evoluciona amb la teva organització. Extreus serveis quan el dolor ho justifica, no perquè hi hagi un pla que diu que toca.
A Conectia, treballem amb startups europees que estan exactament en aquest punt: el monòlit els va servir per arribar a product-market fit, i ara necessiten evolucionar l'arquitectura per escalar. Els enginyers senior i arquitectes de LATAM que proporcionem han guiat aquesta transició múltiples vegades — saben què extreure primer, com evitar els errors clàssics de les migracions distribuïdes, i com fer-ho sense aturar el lliurament de funcionalitats.
Perquè aquesta és la clau: el teu negoci no pot parar mentre migres. Els usuaris segueixen fent servir el producte. L'equip de producte segueix demanant funcionalitats. La migració ha de passar en paral·lel a tot això. I això requereix enginyers que ho hagin fet abans.
El teu monòlit s'està convertint en un coll d'ampolla? Parla amb un CTO — et connectem amb arquitectes senior que han guiat aquesta transició sense aturar el lliurament.
