Ja sabem què són els microserveis, quins avantatges i costos comporten i com es comparen amb el monòlit. Falta la pregunta més important i la que menys es respon amb rigor: quan convé adoptar-los? Massa organitzacions prenen aquesta decisió per moda, per pressió d'un proveïdor o perquè "ho fa Netflix", i acaben pagant la complexitat d'un sistema distribuït sense obtenir-ne cap dels avantatges.

Aquesta lliçó ofereix criteris concrets i verificables per decidir. Veurem els factors que de debò inclinen la balança (organització, maduresa DevOps, coneixement del domini, escalat, disponibilitat, velocitat de lliurament), l'enfocament "monolith first", els senyals que indiquen que un monòlit demana ser dividit i els que indiquen el contrari, els prerequisits mínims sense els quals no s'hauria de començar, una llista de comprovació de decisió, els costos ocults que ningú no posa a la presentació i els antipatrons més habituals. Els exercicis et demanaran decidir sobre escenaris ficticis diferents, inclosa la mateixa TechCorp. No entrarem en com s'executa una migració (lliçó 08-01) ni en la tècnica de descomposició (lliçó 02-02): aquí es tracta de decidir si, no com.

1. Els criteris que importen
2. L'enfocament "monolith first"
3. Senyals que un monòlit demana ser dividit
4. Senyals que NO convé
5. Prerequisits mínims
6. Llista de comprovació de decisió
7. Costos ocults
8. Antipatrons
9. Errors comuns i consells
10. Exercicis
11. Conclusió

El 1967, Melvin Conway va observar que les organitzacions dissenyen sistemes que reflecteixen la seva estructura de comunicació. Si tens tres equips, tindràs tres subsistemes; si els equips es comuniquen malament, les interfícies entre els seus subsistemes seran dolentes.

Aplicat a la nostra decisió:

• Un únic equip petit (diguem, menys de 8-10 persones) no obté gairebé res de l'autonomia entre equips que ofereixen els microserveis, perquè no hi ha ningú de qui independitzar-se. Sí que n'obté, en canvi, tot el cost operatiu.
• Diversos equips que es destorben treballant sobre el mateix codi i el mateix desplegament són el senyal més clar que uns límits de servei alineats amb aquests equips ajudarien.
• L'estructura importa tant com la mida: si els equips estan organitzats per capa tècnica (front-end, back-end, base de dades, sistemes), els microserveis hi encaixen malament, perquè cada servei necessitaria tots els equips. Si estan organitzats per capacitat de negoci (equip de comandes, equip de catàleg), hi encaixen de manera natural.

Hi ha fins i tot una estratègia anomenada maniobra inversa de Conway: reorganitzar primer els equips, al voltant de les capacitats de negoci desitjades, perquè l'arquitectura resultant segueixi aquesta forma. A TechCorp, avui hi ha un equip de back-end únic; part del camí consistirà que l'equip del Luis sigui de debò "l'equip de Comandes".

Els microserveis multipliquen el nombre de coses que cal construir, provar, desplegar i vigilar. Si avui el desplegament del monòlit és manual, si no hi ha proves automatitzades fiables o si ningú no sap què passa en producció fins que un client es queixa, dividir el sistema convertirà un problema en sis. Pregunta't: podem desplegar a producció amb un clic i amb confiança? Tenim mètriques i logs centralitzats? Si la resposta és no, aquesta és la primera feina, no la divisió.

Dividir un sistema en serveis significa fixar límits entre capacitats de negoci. Aquests límits són cars de moure després: canviar de lloc una responsabilitat entre dos serveis implica renegociar contractes, migrar dades i coordinar desplegaments.

• Si el domini és estable i ben conegut (una botiga online que fa anys que ven, amb àrees clares com catàleg, comandes i pagaments), els límits es poden traçar amb confiança.
• Si el domini és exploratori (una startup que encara canvia de model de negoci cada trimestre), qualsevol divisió serà prematura i s'haurà de refer. En un monòlit, moure una responsabilitat d'un mòdul a un altre és canviar uns fitxers; en microserveis, és un projecte.

Si totes les parts del sistema creixen en càrrega de manera semblant, replicar el monòlit funciona bé. L'escalat selectiu només aporta valor quan hi ha parts amb perfils de càrrega molt diferents (a TechCorp, el catàleg rep cent vegades més lectures que no pas escriptures rep pagaments) o amb necessitats de recursos molt diferents (un servei que genera informes pesants al costat d'un altre que atén peticions lleugeres).

Si una fallada en una part secundària del sistema (els correus, les estadístiques) no es pot permetre tombar la part crítica (cobrar), l'aïllament que ofereixen els serveis separats és valuós. Si tota l'aplicació té els mateixos requisits i una caiguda d'una hora és assumible, aquest argument pesa poc. Compte: els microserveis ofereixen la possibilitat d'aïllar fallades, no la garantia; cal dissenyar-la.

El ritme de lliurament està limitat per l'arquitectura? Si els equips esperen el desplegament setmanal, si un canvi petit requereix provar-ho tot, si les cues de revisió s'encallen per conflictes entre equips, l'arquitectura està frenant el lliurament. Si el ritme està limitat per altres coses (falta de persones, requisits poc clars, decisions lentes), els microserveis no l'acceleraran.

Martin Fowler i altres autors defensen des de fa anys una postura molt pragmàtica: comença amb un monòlit, fins i tot si creus que acabaràs en microserveis. Els arguments:

1. No coneixes prou el domini al principi. Els límits que tracis el primer dia seran incorrectes, i en un monòlit corregir-los és barat.
2. El cost inicial dels microserveis endarrereix el valor. Un producte nou necessita arribar al mercat, no un clúster de Kubernetes.
3. Un monòlit modular ja ben organitzat es pot dividir després amb relativa facilitat, extraient mòduls que ja tenen límits clars.
4. Gairebé tots els casos d'èxit de microserveis van començar com a monòlits que van créixer fins que van fer mal. Els intents de començar directament en microserveis tenen un historial molt pitjor.

La manera pràctica d'aplicar-ho: construeix un monòlit modular des del principi (mòduls amb API interna, cadascun propietari de les seves taules), automatitza el desplegament i l'observabilitat, i extreu un servei només quan un mòdul concret tingui una raó concreta (escalat, equip propi, tecnologia diferent, aïllament). És exactament el camí que recorrerà TechCorp al curs: partint d'un monòlit que ja fa mal, no d'un full en blanc.

Aquests senyals, sobretot si n'apareixen diversos alhora, indiquen que el monòlit ha arribat a un punt en què el seu cost supera el dels microserveis:

• Desplegaments lents, poc freqüents i temuts. El desplegament s'ha convertit en un esdeveniment (el "divendres de desplegament"), requereix finestres de manteniment i sovint es reverteix.
• Equips que es trepitgen. Conflictes constants al codi, esperes per fusionar canvis, un equip bloquejat per un altre.
• Escalat ineficient i car. Es replica tota l'aplicació per culpa d'una part; la factura d'infraestructura creix més de pressa que el negoci.
• Fallades que es propaguen. Un error en un mòdul secundari tomba funcions crítiques.
• Suites de proves de desenes de minuts que tothom intenta saltar-se.
• Temps d'incorporació de nous desenvolupadors molt llarg perquè ningú no entén el sistema sencer.
• Necessitat tecnològica real en una part (per exemple, un model de dades que a la base de dades actual és un martiri).

TechCorp presenta gairebé tots aquests senyals, com veurem a la lliçó 01-05.

Amb la mateixa claredat, situacions en què dividir seria un error:

• Un únic equip petit que treballa bé amb el monòlit.
• Un producte que encara busca el seu model de negoci; el domini canvia massa.
• Sense automatització: desplegaments manuals, sense proves fiables, sense monitoratge. Primer això.
• Càrrega baixa o uniforme: un servidor modest ho atén tot amb folgança.
• La motivació és la moda, un currículum o una presentació d'un proveïdor, no un problema concret.
• El monòlit fa mal per mala qualitat de codi, no per acoblament de desplegament. La solució és refactoritzar cap a un monòlit modular; distribuir el desordre només ho empitjora.
• L'organització no està disposada a canviar: equips per capes, un departament d'operacions que ho centralitza tot, decisions molt jeràrquiques. L'arquitectura xocarà amb l'estructura i perdrà.

Abans d'extreure el primer servei, haurien d'estar raonablement resolts aquests quatre pilars. Sense ells, cada servei nou afegeix risc en lloc de restar-ne.

Un bon consell: construeix aquests pilars sobre el monòlit abans de dividir-lo. Un monòlit amb CI/CD, contenidors i bona observabilitat ja és un sistema molt millor, i si finalment es divideix, la divisió serà infinitament més segura.

Fes servir aquesta llista com a matriu. No és una fórmula matemàtica, sinó una manera d'obligar-te a mirar tots els factors. Compta les respostes afirmatives de cada bloc.

Bloc A. Raons per dividir (com més n'hi hagi, més sentit té)

• [ ] Hi ha dos o més equips que es destorben treballant al mateix codi i desplegament.
• [ ] Els equips estan (o poden estar) organitzats per capacitat de negoci.
• [ ] Hi ha parts del sistema amb necessitats d'escalat clarament diferents.
• [ ] Una fallada en parts secundàries ha tombat (o pot tombar) funcions crítiques.
• [ ] Els desplegaments són lents, poc freqüents o temuts per l'acoblament.
• [ ] El domini és estable i les seves àrees es poden anomenar sense discussió.
• [ ] Hi ha una necessitat tecnològica real en alguna part concreta.

Bloc B. Capacitat per fer-ho (totes haurien de ser sí, o estar en camí)

• [ ] Hi ha CI/CD fiable.
• [ ] Se sap construir i operar contenidors.
• [ ] Hi ha logs i mètriques centralitzats i s'està disposat a afegir traces.
• [ ] Els equips poden desplegar sense autorització externa i es responsabilitzen de l'operació.
• [ ] Hi ha pressupost i persones per operar més infraestructura (broker, gateway, orquestrador, diverses bases de dades).

Bloc C. Senyals d'alarma (un de sol hauria de fer aturar i pensar)

• [ ] La motivació principal és la moda, un proveïdor o un currículum.
• [ ] L'equip total és molt petit (menys d'unes 8-10 persones) i no hi ha previsió de créixer.
• [ ] El model de negoci o el domini canvien sovint.
• [ ] El dolor actual es deu a mala qualitat de codi, no a acoblament de desplegament.

Interpretació orientativa:

Hi ha costos que rarament apareixen a la proposta inicial i sempre apareixen a la factura:

• Infraestructura de suport que el monòlit no necessitava: broker de missatges, gateway, orquestrador, registre de contenidors, eines d'observabilitat, gestió de secrets. Cadascuna s'ha d'instal·lar, actualitzar, protegir i saber operar.
• Duplicació: codi d'utilitat, configuració, pipelines, panells de monitoratge, polítiques de seguretat... multiplicats pel nombre de serveis.
• Coordinació de contractes: temps dedicat a acordar, documentar i versionar APIs i esdeveniments, i a mantenir la compatibilitat cap enrere.
• Entorns de desenvolupament i proves més complexos: aixecar "tota la botiga" en local passa de npm start a orquestrar una dotzena de contenidors.
• Formació: l'equip ha d'aprendre a raonar sobre sistemes distribuïts (idempotència, reintents, consistència eventual), i aquesta corba és real.
• Guàrdies i suport: més serveis vol dir més alertes i més coses que poden despertar algú a les tres de la matinada.
• Cost de desfer: si la divisió resulta un error, tornar a consolidar serveis és tan costós com dividir-los.

S'adopta l'arquitectura perquè és el que fa la competència, perquè queda bé en una oferta de feina o perquè un proveïdor de núvol la recomana. No hi ha cap problema concret a resoldre. Resultat típic: un sistema més complex, més car i més lent de desenvolupar que el monòlit que va substituir, sense cap avantatge tangible.

Serveis tan petits que el seu abast no és una capacitat de negoci sinó una funció tècnica ("servei de validació de codis postals", "servei de formatació de dates"). El cost de comunicació i operació supera de molt el valor de la separació. Regla pràctica: si un servei no pot fer res d'útil sense cridar-ne tres més, probablement és massa petit.

Ja l'hem anomenat a lliçons anteriors perquè és l'antipatró més nociu: diversos processos que comparteixen base de dades, que s'han de desplegar junts perquè els seus contractes canvien de manera acoblada, o que depenen síncronament els uns dels altres de tal manera que cap no funciona si un altre cau. Té tot el cost de la xarxa i cap dels avantatges de l'autonomia. Com detectar-lo:

• Servei d'entitat: un servei per taula (servei-client, servei-adreca, servei-telefon) en lloc de per capacitat de negoci.
• Capa de serveis compartits de la qual depenen tots ("servei d'utilitats comunes"), que reintrodueix l'acoblament central.
• Big bang: reescriure tot el monòlit en microserveis de cop, en un projecte de dos anys, sense lliurar res pel camí. L'alternativa incremental s'estudia a la lliçó 08-01.

• Decidir sense dades. "El monòlit és lent" o "els equips es trepitgen" s'haurien de poder quantificar: freqüència de desplegament, temps de la suite de proves, nombre de reversions, cost d'infraestructura per comanda. Sense números, la decisió és una opinió.
• Saltar-se els prerequisits "perquè ja els posarem després". El després no arriba mai, i mentrestant s'opera un sistema distribuït a cegues.
• Dividir per capes o per taules. Els límits han de seguir capacitats de negoci; el contrari produeix nanoserveis o serveis d'entitat.
• Ignorar l'organització. Si els equips no es reorganitzen al voltant de les capacitats, la Llei de Conway retornarà el sistema a la forma de l'organització, amb la complexitat afegida.
• Tractar la decisió com a definitiva i global. No és "tot o res": es pot extreure un servei, comprovar si compensa i decidir el pas següent amb el que s'ha après.
• Consell: omple la llista de comprovació de l'apartat 6 amb almenys dues persones més i compareu respostes. Les discrepàncies són la conversa més valuosa que pots tenir abans de decidir.

A cada escenari, aplica la llista de comprovació de l'apartat 6 i pren una decisió raonada: microserveis (incrementals), monòlit modular, o "encara no". Justifica-ho amb els criteris de la lliçó.

Un antic equip de TechCorp funda una startup per vendre kits d'electrònica educativa. Són quatre persones (tres desenvolupadors i una persona de producte). Fa sis mesos que hi són; han canviat dues vegades el model de negoci (primer venda directa, després subscripció mensual, ara dubten si afegir marketplace). Despleguen a mà amb git pull en un servidor. Reben unes 300 comandes al mes. El fundador tècnic ha llegit sobre microserveis i vol "fer-ho bé des del principi".

Una asseguradora té una plataforma monolítica en Java amb dotze equips de desenvolupament organitzats per producte (llar, auto, vida, salut...) treballant sobre el mateix repositori. Els desplegaments són mensuals, requereixen una finestra nocturna i un comitè de canvis, i es reverteixen sovint. La suite de proves triga 90 minuts. Tenen CI, contenidors en preproducció i un equip de plataforma que ja opera Kubernetes per a altres sistemes. Els productes són estables (fa quinze anys que els venen). L'àrea de tarifació consumeix deu vegades més CPU que la resta i obliga a sobredimensionar-ho tot. Els equips es queixen d'esperar setmanes perquè els seus canvis arribin a producció.

Amb el que saps de TechCorp (monòlit Node.js amb una PostgreSQL, sis àrees funcionals, desplegaments setmanals temuts, caigudes en campanyes per saturació del catàleg, un equip de back-end que comença a organitzar-se per àrees amb el Luis al capdavant de Comandes, CI bàsic i contenidors en proves però sense orquestració en producció ni observabilitat més enllà dels logs del servidor), decideix què li recomanaries a la Marta i què hauria de fer abans d'extreure el primer servei.

Exercici 1: TechCorp Labs

• Bloc A: pràcticament cap casella. Un equip, càrrega mínima, sense problemes de desplegament per acoblament.
• Bloc B: no hi ha CI/CD ni observabilitat; desplegaments manuals.
• Bloc C: tres senyals d'alarma: equip molt petit, domini exploratori (dos pivots en sis mesos) i motivació per "fer-ho bé" sense cap problema concret.
• Decisió: monòlit, i ni tan sols cal que sigui gaire modular encara. El que sí que convé: automatitzar el desplegament (CI/CD senzill) i afegir monitoratge bàsic. Si d'aquí a un any el negoci s'estabilitza i l'equip creix, evolucionar cap a monòlit modular. Començar en microserveis aquí endarreriria el producte mesos i fixaria límits d'un domini que encara no existeix.

Exercici 2: l'asseguradora

• Bloc A: dotze equips que es destorben (sí), organitzats per producte (sí, per capacitat de negoci), escalat diferenciat a tarifació (sí), desplegaments lents i temuts (sí), domini estable (sí). Cinc o sis caselles.
• Bloc B: CI sí, contenidors sí, plataforma Kubernetes operada per un equip especialitzat sí. Observabilitat probablement parcial (caldria verificar les traces). Cultura de propietat: no del tot, hi ha un comitè de canvis que aprova desplegaments; aquest és el punt a treballar.
• Bloc C: cap senyal clar d'alarma; el dolor ve de l'acoblament, no de la qualitat del codi (tot i que convé comprovar-ho).
• Decisió: adoptar microserveis de manera incremental. Candidat evident per a la primera extracció: tarifació, que té la raó d'escalat més clara i probablement un límit de domini nítid. En paral·lel, canviar la governança perquè els equips puguin desplegar sense comitè (amb controls automàtics al pipeline) i assegurar l'observabilitat distribuïda abans que hi hagi més de dos o tres serveis.

Exercici 3: TechCorp

• Bloc A: equips que es trepitgen (sí, comença a haver-n'hi diversos), organització per capacitat de negoci (en marxa), escalat diferenciat (sí, catàleg enfront de la resta), fallades que es propaguen (sí, les campanyes tomben tota la botiga), desplegaments temuts (sí), domini estable (sí, és una botiga amb àrees clares). Almenys cinc caselles.
• Bloc B: CI bàsic (parcial), contenidors només en proves (parcial), sense orquestració en producció (no), observabilitat limitada a logs (no), cultura de propietat naixent (parcial).
• Bloc C: cap senyal d'alarma; el dolor és real i d'acoblament.
• Decisió: sí als microserveis, però de manera incremental i amb deures previs. Abans d'extreure el primer servei, la Marta hauria de: consolidar CI/CD per al monòlit, portar els contenidors a producció amb un orquestrador, muntar observabilitat (logs centralitzats, mètriques i preparar traces) i consolidar els equips per àrea amb responsabilitat d'operació. Mentre es fa això, modularitzar el monòlit perquè els límits de catàleg, comandes, etc. siguin explícits. El primer candidat raonable a extreure és el catàleg, per la seva raó d'escalat claríssima i per ser majoritàriament de lectura (baix risc). Aquest és, de fet, el full de ruta que seguirà el curs, presentat a la lliçó següent.

Decidir si adoptar microserveis no és una qüestió de gustos ni de tendències, sinó de contrastar problemes concrets amb capacitats concretes. Els criteris que inclinen la balança són l'estructura de l'organització (Llei de Conway), la maduresa DevOps, l'estabilitat del domini, les necessitats d'escalat i disponibilitat diferenciades i el fre real a la velocitat de lliurament. L'enfocament "monolith first" recomana començar amb un monòlit modular i extreure serveis només quan hi hagi una raó específica; els senyals de dolor (desplegaments temuts, equips que es trepitgen, escalat ineficient, fallades que es propaguen) indiquen quan ha arribat aquest moment, i els senyals contraris (equip petit, domini canviant, sense automatització, motivació per moda) indiquen quan no. Els quatre prerequisits (CI/CD, contenidors, observabilitat i cultura de propietat) s'haurien de construir sobre el monòlit abans de dividir-lo, i la llista de comprovació de decisió obliga a mirar tots els factors alhora, inclosos els costos ocults i els antipatrons que cal evitar (moda, nanoserveis, monòlit distribuït).

Hem aplicat aquests criteris a TechCorp i la conclusió és que el seu cas justifica la migració, amb deures previs. A la lliçó següent presentarem aquest cas amb tot detall: qui és TechCorp, com és el seu monòlit avui, quins problemes pateix, quin és el flux de negoci central que ens acompanyarà durant tot el curs, el mapa de serveis que construirem i el full de ruta mòdul a mòdul.