Per entendre bé què aporten els microserveis cal entendre igual de bé allò amb què es comparen: l'arquitectura monolítica. És la manera més habitual de construir programari, la que fa servir avui TechCorp i, probablement, la que has utilitzat a la majoria dels teus projectes. Lluny de ser una relíquia, el monòlit té virtuts importants i, ben construït (l'anomenat monòlit modular), és una opció excel·lent per a moltíssims sistemes.

En aquesta lliçó definirem què és un monòlit i les seves variants, compararem totes dues arquitectures dimensió a dimensió amb una taula i diagrames, i seguirem pas a pas el cicle de vida d'un mateix canvi funcional ("afegir cupons de descompte a la botiga de TechCorp") en cadascuna d'elles per veure on són les diferències reals. Acabarem desmuntant el mite que el monòlit és sempre l'opció dolenta. Aquí encara no decidirem quan convé l'una o l'altra (això arriba a la lliçó 01-04) ni veurem la tècnica de dividir un monòlit (lliçó 02-02).

1. Què és un monòlit
2. El monòlit modular: un punt intermedi
3. Comparativa dimensió a dimensió
4. Els dos sistemes en diagrames
5. Un mateix canvi, dos cicles de vida: cupons de descompte a TechCorp
6. Altres alternatives: SOA i monòlit modular com a destinació
7. El mite que el monòlit és sempre dolent
8. Errors comuns i consells
9. Exercicis
10. Conclusió

Un monòlit és una aplicació construïda i desplegada com una única unitat: un sol procés (o un sol artefacte que s'executa en diversos processos idèntics), habitualment un sol repositori de codi, i gairebé sempre una sola base de dades. Tota la funcionalitat (interfície, lògica de negoci, accés a dades) viu al mateix desplegament.

Característiques típiques:

• Una unitat de desplegament: es compila o s'empaqueta tot junt i es puja tot junt. A TechCorp, techcorp-shop és un únic projecte Node.js que s'arrenca amb node servidor.js i serveix tota la botiga.
• Crides internes en memòria: quan el mòdul de comandes necessita comprovar l'estoc, crida una funció del mòdul d'inventari al mateix procés. Res no viatja per la xarxa.
• Una base de dades compartida: totes les taules (clients, productes, estoc, comandes, pagaments, notificacions) són al mateix PostgreSQL i qualsevol mòdul pot consultar qualsevol taula. Les transaccions abasten tot el que calgui.
• Escalat horitzontal per rèplica completa: si cal més capacitat, s'executen diverses còpies idèntiques del monòlit darrere d'un balancejador.

És important subratllar que "monòlit" no vol dir "codi desordenat". Un monòlit pot estar perfectament organitzat en capes i mòduls. Quan el codi d'un monòlit està embolicat, sense límits interns clars, es parla de big ball of mud ("gran bola de fang"), que és un problema de qualitat, no d'arquitectura de desplegament.

Un monòlit modular és un monòlit el codi del qual està dividit en mòduls amb límits explícits, cadascun amb la seva API interna i, en la versió més disciplinada, amb el seu propi esquema o conjunt de taules a què els altres mòduls no accedeixen directament. Continua desplegant-se com una unitat, però per dins s'assembla molt a un conjunt de microserveis que viuen al mateix procés.

El monòlit modular té un valor doble: és una arquitectura excel·lent per si mateixa, i a més és el millor punt de partida si algun dia es vol migrar a microserveis, perquè els límits ja estan traçats. Un mòdul ben aïllat es pot "extreure" a un servei amb relativa facilitat; una bola de fang, no. Tornarem sobre aquesta idea al mòdul 2.

Aquesta és la taula central de la lliçó. Compara totes dues arquitectures en les dimensions que més importen a la pràctica. Llegeix-la amb calma; gairebé cada fila correspon a una lliçó posterior del curs.

Una manera útil de llegir la taula: el monòlit és senzill al principi i es complica en créixer; els microserveis són complicats al principi i mantenen la complexitat acotada en créixer. La qüestió d'on és el punt d'encreuament és exactament el que abordarem a la lliçó següent.

Tot viu al mateix rectangle. Les fletxes entre mòduls són crides a funcions. Tots els mòduls apunten a la mateixa base de dades.

Cada servei té el seu propi rectangle i la seva pròpia base de dades. Les relacions entre serveis passen per la xarxa (HTTP o RabbitMQ). El gateway és l'únic punt de contacte amb l'exterior.

Res no il·lustra millor les diferències que seguir un canvi real. La Marta demana una funcionalitat nova: cupons de descompte. Un client introdueix un codi en fer la comanda, el sistema valida el cupó, aplica el descompte al total i registra que el cupó s'ha fet servir. A més, s'ha de poder consultar al catàleg quins productes admeten cupó i enviar un correu diferent quan la comanda porta descompte.

Balanç: desenvolupament ràpid i senzill (una transacció, un repositori, un desplegament), però amb dependència del calendari global de desplegament, risc de trepitjar-se amb altres canvis i un desplegament que ho arrossega tot.

Balanç: més feina inicial (definir servei, API, contractes, gestió de fallades), però desplegaments independents, equips que no es trepitgen i una capacitat de negoci (promocions) que neix ja aïllada i podrà evolucionar sola.

• El monòlit optimitza el desenvolupament del canvi; els microserveis optimitzen el lliurament i l'evolució independent.
• Al monòlit la dificultat apareix al final (coordinar el desplegament, revertir-ho tot). En microserveis apareix al principi (decidir límits i contractes).
• La gestió de fallades, que al monòlit la resol la transacció, en microserveis és una decisió explícita de disseny.

L'elecció no és binària. Entre "un monòlit" i "dotzenes de microserveis" hi ha parades intermèdies vàlides:

• Monòlit modular (vist a l'apartat 2): mateix desplegament, límits interns rigorosos. Moltes organitzacions haurien d'aspirar a això i quedar-s'hi. És també la base ideal per a una futura extracció de serveis.
• SOA "clàssica": serveis de gra més gruixut que els microserveis, sovint amb un bus d'integració. Encara és comuna a grans corporacions. Comparteix amb els microserveis la idea de serveis, però amb més centralització (vegeu la lliçó 01-01).
• Pocs serveis grans ("macroserveis"): dividir el sistema en dues o tres peces per raons molt concretes (per exemple, separar el catàleg d'alta lectura de la resta) sense anar més enllà. És una estratègia pragmàtica que captura part dels avantatges amb una fracció del cost.

Cap d'aquestes opcions no és "fer trampes". Són punts diferents d'un mateix espectre, i el raonable és triar el que respongui als problemes reals que es tenen.

Convé dir-ho amb claredat, perquè la indústria de vegades ho oblida: el monòlit no és un error d'arquitectura. És l'opció per defecte correcta per a la majoria de projectes nous i per a molts sistemes madurs. Els seus avantatges són reals:

• Es comença a lliurar valor en dies, no en mesos d'infraestructura.
• Un desenvolupador pot entendre i executar tot el sistema al seu portàtil.
• Les transaccions i els JOIN resolen gratis problemes que en microserveis costen patrons complexos.
• Refactoritzar és fàcil perquè el compilador o les proves veuen tot el codi alhora; moure una responsabilitat d'un mòdul a un altre és canviar un import, no renegociar un contracte entre equips.
• Operar-lo és barat: un procés, una base de dades, un log.

Empreses grans i molt respectades operen monòlits enormes amb èxit, i d'altres que van migrar a microserveis han tornat parcialment a consolidar serveis perquè el cost operatiu no compensava. Els microserveis no fan bo un sistema; resolen un conjunt concret de problemes (escalat desigual, equips que es destorben, cicles de desplegament lents) a canvi d'un altre conjunt de problemes. Si no tens els primers, no compris els segons.

El cas de TechCorp que seguim al curs està triat precisament perquè sí que té aquests problemes: campanyes que saturen només el catàleg, desplegaments setmanals amb por, equips que es trepitgen al mateix codi. Per això la seva història és una història de migració. Però un TechCorp de quatre persones i mil comandes al mes s'hauria de quedar al seu monòlit, idealment modular, i ser feliç.

• Confondre monòlit amb codi dolent. Un monòlit pot estar impecablement organitzat. Si el problema és que el codi és un caos, la solució és refactoritzar cap a un monòlit modular, no repartir el caos per la xarxa.
• Comparar un monòlit real amb uns microserveis idealitzats. És fàcil guanyar el debat si es compara el monòlit heretat ple de deute tècnic amb un diagrama net de serveis. Compara amb la mateixa honestedat: els microserveis també acumulen deute, només que distribuït.
• Oblidar el cost inicial. La taula comparativa mostra que els microserveis paguen per endavant. Si el projecte necessita lliurar valor en setmanes, aquest cost pot ser prohibitiu.
• Pensar que les transaccions "se substitueixen" sense més. El pas d'"una transacció que ho fa tot" a "diversos serveis sense transacció comuna" és la part més difícil de la comparació i mereix la màxima atenció en el disseny.
• Consell: en avaluar un canvi funcional, fes l'exercici de l'apartat 5 mentalment: recorre els passos en la teva arquitectura actual i en l'alternativa. És la manera més ràpida de detectar on són els costos reals.

Per a cada descripció, indica si es tracta d'un monòlit clàssic, un monòlit modular o microserveis, i justifica-ho amb la taula de l'apartat 2.

1. Una aplicació Node.js en un únic repositori, dividida en carpetes clients/, cataleg/, comandes/, cadascuna amb el seu propi conjunt de taules a què les altres carpetes només accedeixen a través de funcions públiques del mòdul; es desplega com un únic procés.
2. Sis processos Node.js independents, cadascun amb la seva base de dades, que es comuniquen per HTTP i RabbitMQ i es despleguen per separat.
3. Una aplicació Java desplegada com un únic fitxer .war en què qualsevol classe pot executar consultes SQL sobre qualsevol taula.

La Marta demana una altra funcionalitat: llista de desitjos (un client pot desar productes per a més endavant i rebre un correu si baixen de preu). Descriu, en format de llista de passos com a l'apartat 5, com s'implementaria al monòlit actual de TechCorp i a la versió de microserveis. Assenyala en cadascun el pas més costós.

Un company afirma: "Els monòlits són cosa del passat; qualsevol projecte seriós avui hauria de començar amb microserveis". Escriu tres arguments, recolzats en la taula de l'apartat 3, per rebatre'l.

Exercici 1

1. Monòlit modular. Una unitat de desplegament, però amb límits explícits entre mòduls i dades "privades" per mòdul. És exactament el punt intermedi descrit.
2. Microserveis. Diverses unitats de desplegament, base de dades per servei, comunicació per xarxa.
3. Monòlit clàssic (i probablement amb tendència a bola de fang). Una unitat de desplegament i accés indiscriminat a les dades.

Exercici 2 (una solució possible)

Monòlit:

1. Migració: taula llista_desitjos (client_id, producte_id, preu_en_el_moment).
2. Endpoints a les rutes de clients per afegir i llistar desitjos, amb un JOIN a productes per mostrar nom i preu actual.
3. En actualitzar el preu d'un producte (mòdul de catàleg), consultar llista_desitjos i cridar la funció de notificacions per enviar el correu, tot al mateix procés.
4. Proves de l'aplicació completa; desplegament setmanal. Pas més costós: el desplegament conjunt i les proves lentes; el desenvolupament en si és senzill.

Microserveis:

1. Decidir on viu la llista de desitjos: probablement a servei-clients (és una preferència del client).
2. servei-clients afegeix la seva taula i els seus endpoints; per mostrar nom i preu actual ha de cridar servei-cataleg o desar una còpia local actualitzada per esdeveniments.
3. servei-cataleg publica un esdeveniment producte.preu-canviat; servei-clients el consumeix, busca qui tenia aquest producte a la seva llista i publica alguna cosa com desig.baixada-preu; servei-notificacions el consumeix i envia el correu.
4. Contractes: definir els dos esdeveniments nous i els seus camps.
5. Desplegaments independents de catàleg, clients i notificacions, en aquest ordre. Pas més costós: decidir com obté clients les dades del producte (crida síncrona enfront de còpia per esdeveniments) i dissenyar la cadena d'esdeveniments; cal pensar en fallades i duplicats.

Exercici 3 (arguments possibles)

• Cost inicial: un monòlit lliura valor en dies amb un servidor i una base de dades; els microserveis exigeixen contenidors, orquestració, missatgeria i observabilitat abans de la primera funcionalitat. Per a un projecte nou, el risc més gran del qual és no trobar mercat, aquest cost és difícil de justificar.
• Dades i rendiment: en un monòlit, una transacció i un JOIN resolen problemes que en microserveis requereixen sagues, duplicació de dades i crides per xarxa amb latència. Mentre el domini no estigui clar, aquesta simplicitat val or.
• Equips: els avantatges d'autonomia dels microserveis només apareixen quan hi ha diversos equips que es destorben. Amb un únic equip petit no hi ha a qui deixar de destorbar, i sí que hi ha molts més serveis a operar. A més, un monòlit modular ofereix límits clars sense cost de xarxa i deixa oberta la porta a extreure serveis més endavant.

En aquesta lliçó hem definit el monòlit com una única unitat de desplegament amb una base de dades compartida i crides internes en memòria, i hem presentat el monòlit modular com una variant disciplinada que combina la senzillesa operativa del monòlit amb límits interns clars. La comparació dimensió a dimensió ha mostrat un patró consistent: el monòlit és barat i simple al principi i es complica en créixer, mentre que els microserveis paguen un cost inicial alt a canvi de mantenir acotada la complexitat de cada peça i permetre desplegaments, escalat i equips independents. El recorregut del canvi "cupons de descompte" ha fet tangible on apareixen les dificultats en cada cas: al final del cicle al monòlit, al principi als microserveis. I hem deixat clar que el monòlit no és una arquitectura de segona: és l'opció correcta per a molts sistemes.

Amb aquesta comparació a la mà, ja podem abordar la pregunta que de debò importa a la pràctica: quan convé adoptar microserveis i quan no? La lliçó següent dona criteris concrets, senyals d'alarma, prerequisits i una llista de comprovació per prendre aquesta decisió amb fonament.