Ja sabem què és un microservei. La pregunta natural que ve a continuació és: val la pena? La resposta honesta és "depèn", i aquesta lliçó existeix perquè aquest "depèn" deixi de ser vague. Recorrerem amb detall els avantatges que ofereix l'arquitectura i, amb la mateixa serietat, els desavantatges que porta associats. És important entendre totes dues cares perquè, com veurem, gairebé cada avantatge té un cost associat: no s'obté escalat selectiu sense assumir complexitat de xarxa, ni desplegaments independents sense gestionar contractes, ni autonomia d'equips sense invertir en automatització.

Il·lustrarem cada punt amb una situació concreta de TechCorp, la botiga online que fa de fil conductor del curs. També presentarem les cèlebres "vuit fal·làcies de la computació distribuïda", una llista de suposicions errònies que tot desenvolupador que passi d'un monòlit a serveis distribuïts acaba descobrint, sovint per les males. En aquesta lliçó encara no farem la comparació estructurada amb el monòlit (lliçó 01-03) ni donarem criteris de decisió (lliçó 01-04); aquí es tracta d'entendre bé què es guanya i què es paga.

1. Avantatges dels microserveis
2. Desavantatges dels microserveis
3. Les vuit fal·làcies de la computació distribuïda
4. Taula resum: cada avantatge i el cost que porta
5. Errors comuns i consells
6. Exercicis
7. Conclusió

En un monòlit, si una part del sistema necessita més capacitat, cal replicar tota l'aplicació. Amb microserveis s'escala només el servei que ho necessita.

Situació a TechCorp: durant el Black Friday, el trànsit de navegació pel catàleg es multiplica per vint, però el nombre de comandes "només" es triplica i les consultes de dades de client gairebé no canvien. Amb el monòlit actual, la Marta ha de contractar servidors per replicar tota la botiga, inclosos mòduls que no estan sota pressió. Amb serveis separats, s'aixequen deu instàncies de servei-cataleg i dues de servei-comandes, i la resta es queda com està. La factura d'infraestructura i el risc de sobredimensionar baixen.

Cada servei es desplega per separat. Un canvi petit en un servei no obliga a reconstruir, provar i desplegar tot el sistema, i per tant es pot desplegar més sovint i amb menys risc.

Situació a TechCorp: l'equip del Luis corregeix un error en el càlcul de les despeses d'enviament. Avui, al monòlit, aquest canvi espera el desplegament setmanal dels divendres juntament amb trenta canvis més de cinc equips; si alguna cosa falla, cal esbrinar quin dels trenta ha estat. Amb servei-comandes separat, el Luis desplega el dimarts al matí, en deu minuts, i si alguna cosa va malament sap exactament què revertir.

Cada equip és propietari d'un o diversos serveis i decideix com construir-los, quan desplegar-los i com operar-los. Es redueix la coordinació entre equips (reunions, esperes, dependències) i augmenta la velocitat.

Situació a TechCorp: avui, per afegir un camp a la taula comandes, el Luis ho ha de consultar amb l'equip de Notificacions (que llegeix aquesta taula per redactar els correus) i amb el de Pagaments (que l'actualitza en cobrar). Amb serveis separats, cadascun té les seves dades i la seva API: el Luis canvia el que vulgui per dins mentre respecti el contracte públic.

Cada servei pot fer servir la tecnologia més adequada per al seu problema: un altre llenguatge, una altra base de dades, una altra versió d'una llibreria. I es pot provar una tecnologia nova en un servei petit sense apostar-hi tot el sistema.

Situació a TechCorp: el catàleg té productes amb atributs molt variables (una samarreta té talles i colors; un portàtil, processador i memòria). A PostgreSQL això obliga a taules genèriques incòmodes. Amb servei-cataleg aïllat, l'equip pot fer servir MongoDB, els documents flexibles del qual hi encaixen molt millor, sense que comandes ni pagaments abandonin PostgreSQL. En aquest curs mantindrem Node.js a tots els serveis per simplicitat didàctica, però res no impediria que un estigués en Go o Java.

Una fallada en un servei no ha de tombar necessàriament la resta, sempre que el sistema estigui dissenyat per tolerar que una part no respongui.

Situació a TechCorp: el proveïdor d'enviament de correus electrònics pateix una caiguda i el mòdul de notificacions comença a acumular errors i a consumir memòria. Al monòlit actual, aquest mòdul comparteix procés amb tota la resta: la fuita de memòria acaba tombant també la creació de comandes, i la botiga sencera deixa de vendre per culpa dels correus. Amb servei-notificacions separat, els correus s'endarrereixen, però les comandes es continuen creant i cobrant. (Compte: aquest aïllament no és automàtic; cal dissenyar-lo, i ho veurem al mòdul 6.)

Un servei d'uns pocs milers de línies s'entén, es prova i es modifica amb molta més facilitat que un monòlit de centenars de milers. Un desenvolupador nou és productiu abans, les proves s'executen en segons i el codi "vell" es pot reescriure servei a servei.

Situació a TechCorp: un desenvolupador que s'incorpora a l'equip de Pagaments necessita avui setmanes per entendre el monòlit abans de tocar res, perquè qualsevol funció pot tenir efectes a qualsevol lloc. Amb servei-pagaments acotat, en un parell de dies coneix tota la seva base de codi i pot començar a contribuir amb confiança.

Ara, amb la mateixa honestedat, el preu.

El que abans era una crida a una funció dins del mateix procés ara és una petició per la xarxa a un altre procés, que pot estar caigut, lent o en una altra versió. Apareixen problemes que no existien: temps d'espera, reintents, idempotència, ordre dels missatges, versionat de contractes, descobriment de serveis. Hi ha més parts mòbils i més maneres que alguna cosa falli.

Situació a TechCorp: al monòlit, crearComanda crida reservarEstoc i, si falla, la comanda no es crea i punt. Amb serveis separats, servei-comandes envia una petició a servei-inventari, no rep resposta en tres segons... i no sap si l'estoc s'ha reservat o no. Reintenta i s'arrisca a reservar dues vegades? Cancel·la i s'arrisca a deixar estoc bloquejat? Cadascuna d'aquestes decisions ara s'ha de prendre explícitament.

Una crida dins del mateix procés triga nanosegons; una crida HTTP entre serveis, mil·lisegons, i a més pot fallar. Un flux que al monòlit travessava cinc funcions ara travessa cinc serveis i en suma les latències.

Situació a TechCorp: la pàgina de detall d'un producte necessita el producte (catàleg), l'estoc disponible (inventari) i les valoracions del client (clients). Tres crides de 20 ms que al monòlit eren tres consultes SQL al mateix procés ara són tres salts de xarxa, i si un d'ells triga 2 segons, la pàgina sencera triga 2 segons.

Amb una única base de dades, una transacció garanteix que "o es fa tot o no es fa res". Amb una base de dades per servei ja no hi ha transaccions que abastin diversos serveis: cal acceptar la consistència eventual i dissenyar mecanismes de compensació.

Situació a TechCorp: avui, en una sola transacció SQL, s'insereix la comanda, es descompta l'estoc i es registra el pagament; si el pagament falla, es fa rollback de tot. Amb tres bases de dades diferents, si el pagament falla després d'haver descomptat l'estoc, algú ha de retornar aquest estoc explícitament. Aquest "algú" és un patró anomenat saga, que s'estudia a la lliçó 02-05.

Provar un servei aïllat és fàcil; provar que deu serveis funcionen bé junts no ho és. I quan alguna cosa falla en producció, l'error pot ser a qualsevol dels serveis pels quals ha passat la petició, cadascun amb els seus propis logs.

Situació a TechCorp: un client es queixa que la seva comanda apareix com a "pagada" però no li ha arribat el correu de confirmació. Al monòlit, s'obre un únic fitxer de log i se segueix la petició. Amb sis serveis, cal buscar en sis llocs, correlacionar per un identificador comú i reconstruir la seqüència. Sense traçabilitat distribuïda (mòdul 6) això és un malson.

Cada servei necessita construir-se, empaquetar-se, desplegar-se, monitorar-se, escalar-se i protegir-se. Sis serveis són sis pipelines, sis panells de mètriques, sis conjunts d'alertes, sis bases de dades amb les seves còpies de seguretat. A més, calen peces noves que el monòlit no necessitava: un broker de missatges, un gateway, un orquestrador, eines d'observabilitat.

Situació a TechCorp: avui la Marta té un servidor d'aplicacions i una base de dades. Demà tindrà un clúster de Kubernetes, RabbitMQ, cinc bases de dades, Prometheus, Grafana, Loki, Jaeger i un gateway. Algú ha de saber operar tot això, i no és gratis ni en diners ni en persones.

Els microserveis pressuposen equips autònoms amb responsabilitat de cap a cap. Si l'organització no hi està preparada (equips per capa tècnica, un únic equip d'operacions a qui cal demanar permís, decisions molt centralitzades), l'arquitectura xoca amb l'estructura i hi surt perdent l'arquitectura.

Situació a TechCorp: avui hi ha "l'equip de back-end", "l'equip de front-end" i "l'equip de sistemes". Si es divideixen els serveis però es manté aquesta estructura, cada desplegament de servei-comandes continuarà necessitant l'aprovació de sistemes i la coordinació amb front-end, i l'autonomia promesa no apareixerà.

És el pitjor dels mons: la complexitat d'un sistema distribuït sense els avantatges de l'autonomia. Passa quan els serveis comparteixen base de dades, quan cal desplegar-los tots alhora perquè els seus contractes canvien de manera acoblada, o quan un no pot funcionar sense cridar síncronament cinc més.

Situació a TechCorp: un intent precipitat de "fer microserveis" separa el codi en sis processos, però tots continuen connectats a la mateixa base de dades PostgreSQL. Resultat: cada canvi d'esquema exigeix coordinar sis desplegaments, la xarxa afegeix latència i fallades que abans no existien... i no s'ha guanyat res. Aquest risc és tan important que hi tornarem a la lliçó 01-04.

Als anys 90, enginyers de Sun Microsystems (Peter Deutsch i d'altres) van enumerar una sèrie de suposicions falses que els programadors tendeixen a fer quan comencen a construir sistemes distribuïts. Dècades després continuen igual de vigents, i són la raó de fons de gairebé tots els desavantatges que acabem de veure.

La lliçó que deixen és senzilla d'enunciar i difícil d'interioritzar: en passar a microserveis, la xarxa deixa de ser un detall i es converteix en part del disseny. Cada crida entre serveis s'ha de dissenyar assumint que pot fallar, trigar o arribar duplicada.

Aquesta taula és probablement el més útil que et pots endur de la lliçó. Cada fila enfronta un avantatge amb el preu que cal pagar per obtenir-lo de debò.

Si t'hi fixes, la columna de la dreta descriu en bona mesura el contingut de la resta del curs. Els mòduls 3 a 7 existeixen per pagar, de manera ordenada, els costos de la columna central.

• Comptar només els avantatges. És l'error més freqüent en presentacions a direcció: es promet velocitat i escalat i es calla el cost d'operar quinze serveis. Després la realitat passa factura. Presenta sempre la taula completa.
• Creure que l'aïllament de fallades és automàtic. Separar processos no evita que un servei caigut arrossegui els que en depenen si aquests n'esperen indefinidament la resposta. Cal dissenyar-ho.
• Subestimar la consistència eventual. "Les dades se sincronitzaran en uns segons" sona inofensiu fins que un client veu la seva comanda pagada i el seu estoc no reservat. Cal pensar cada flux amb aquesta possibilitat al cap.
• Adoptar heterogeneïtat tecnològica sense necessitat. Que es pugui fer servir un llenguatge per servei no vol dir que s'hagi de fer. Cada tecnologia afegida és un cost permanent.
• Oblidar les vuit fal·làcies. Cada vegada que escriguis una crida entre serveis, repassa-les mentalment: què passa si no respon? I si triga 10 segons? I si arriba dues vegades?
• Consell: quan algú proposi "treure X a un microservei", demana-li que digui quin avantatge concret de la llista busca i quin cost concret assumeix. Si no pot anomenar tots dos, la proposta no està madura.

Per a cada situació, indica quin avantatge dels microserveis ajudaria a resoldre-la i quin desavantatge o cost caldria assumir a canvi.

1. A la campanya de rebaixes de gener, la botiga sencera s'alenteix perquè milers d'usuaris naveguen pel catàleg, tot i que en compren pocs.
2. L'equip de Notificacions vol provar un nou proveïdor d'enviament de SMS, però li fa por tocar el monòlit perquè qualsevol fallada afecta la venda.
3. Un desplegament de divendres va introduir un error a pagaments i es va haver de revertir tota l'aplicació, incloses millores del catàleg que funcionaven bé.

Llegeix aquest fragment (simplificat i en pseudocodi) de com un desenvolupador de TechCorp podria implementar la creació d'una comanda cridant altres serveis, i identifica almenys tres fal·làcies de la computació distribuïda que està ignorant.

La Marta ha de decidir si TechCorp inicia la transició a microserveis. Redacta, en cinc o sis línies, un paràgraf equilibrat que li presenti dos avantatges i dos costos concrets per a TechCorp, fent servir situacions reals de la botiga.

Exercici 1

1. Avantatge: escalat selectiu (replicar només servei-cataleg). Cost: operar més instàncies, necessitar orquestrador i balanceig; i acceptar que el catàleg, en ser un servei a part, es consulta per xarxa des de comandes (latència).
2. Avantatge: aïllament de fallades i desplegament independent (provar el nou proveïdor a servei-notificacions sense arriscar la venda), a més d'heterogeneïtat tecnològica si el proveïdor requereix una llibreria diferent. Cost: cal dissenyar què passa a comandes si notificacions falla, i mantenir un pipeline i un monitoratge propis per a aquest servei.
3. Avantatge: desplegaments independents (revertir només servei-pagaments). Cost: contractes versionats entre comandes i pagaments perquè la reversió de l'un no trenqui l'altre; més pipelines de desplegament.

Exercici 2

• La xarxa és fiable: no hi ha gestió d'errors; si qualsevol fetch falla, la funció llança una excepció i l'estat queda inconsistent (per exemple, estoc reservat sense cobrament).
• La latència és zero: tres crides síncrones encadenades; el temps total és la suma, i no hi ha temps màxim d'espera.
• La topologia no canvia: les adreces IP estan escrites a foc; tan bon punt una instància es mogui, tot falla.
• La xarxa és segura: HTTP sense xifrar ni autenticació entre serveis.
• A més, retorna CONFIRMADA sense comprovar les respostes, i si el client reintenta, es reserva i es cobra dues vegades (falta idempotència, conseqüència de la fal·làcia 1).

Exercici 3 (una redacció possible)

Dividir la botiga en serveis ens permetria, d'una banda, escalar només el catàleg en campanyes com el Black Friday en lloc de replicar tota l'aplicació, i de l'altra, que l'equip de Comandes desplegui les seves correccions quan estiguin llestes sense esperar el desplegament setmanal ni arriscar la resta de la botiga. A canvi, hauríem d'assumir dos costos clars: la creació d'una comanda passaria a dependre de crides per xarxa a inventari i pagaments, amb la latència i les fallades que això implica i sense una transacció única que ho desfaci tot si alguna cosa falla; i necessitaríem invertir en infraestructura i coneixement que avui no tenim (orquestració, missatgeria, observabilitat) per operar sis serveis en lloc d'un.

En aquesta lliçó hem vist que els microserveis ofereixen avantatges reals (escalat selectiu, desplegaments independents, autonomia d'equips, llibertat tecnològica, aïllament de fallades i bases de codi manejables), però que cadascun ve amb un cost igualment real: la complexitat d'un sistema distribuït, la latència i les fallades de xarxa, la pèrdua de transaccions globals, la dificultat de provar i depurar, el cost operatiu, les exigències organitzatives i el risc d'acabar amb un monòlit distribuït. Les vuit fal·làcies de la computació distribuïda resumeixen per què aquests costos són inevitables: la xarxa no és fiable, ni instantània, ni segura, ni estàtica. La taula d'avantatge enfront de cost hauria d'acompanyar-te en qualsevol discussió d'arquitectura.

Amb les dues cares de la moneda clares, a la lliçó següent farem una comparació estructurada, dimensió a dimensió, entre l'arquitectura de microserveis i la monolítica, i seguirem un mateix canvi funcional a TechCorp a través de totes dues per veure'n les diferències a la pràctica.