Abans d'escriure ni una sola línia de codi, convé tenir clar de què parlem quan diem "microserveis". El terme es fa servir amb tanta lleugeresa que sovint s'aplica a sistemes que no ho són (un monòlit trossejat en diversos processos, per exemple) o es confon amb tecnologies concretes com Docker o Kubernetes. En aquesta primera lliçó fixarem una definició de treball, repassarem les característiques que distingeixen de debò un microservei, entendrem d'on ve aquesta manera de construir programari i acordarem el vocabulari que farem servir durant tot el curs. Tancarem amb un primer cop d'ull, deliberadament senzill, a com es veuria la botiga online de TechCorp dividida en serveis.

Aquesta lliçó és la base conceptual sobre la qual es recolzen totes les altres: aquí no parlarem de si els microserveis són bons o dolents (això arriba a la lliçó següent), ni de com es comparen amb detall amb un monòlit, ni de quan convé adoptar-los. Aquí només responem la pregunta "què és exactament un microservei?".

1. Què és un microservei (i què no ho és)
2. Característiques definitòries
3. Breu història: de la SOA als microserveis
4. Vocabulari bàsic del curs
5. Primer cop d'ull: la botiga de TechCorp dividida en serveis
6. Errors comuns i consells
7. Exercicis
8. Conclusió

Una definició de treball, prou precisa per a tot el curs:

Un microservei és un component de programari autònom, que implementa una capacitat de negoci ben delimitada, que es desplega de manera independent, que posseeix les seves pròpies dades i que es comunica amb la resta del sistema únicament a través d'interfícies ben definides (APIs o missatges).

I una arquitectura de microserveis és un sistema compost per diversos d'aquests components que col·laboren entre si per oferir una aplicació completa.

Fixa't que la definició no esmenta cap tecnologia. No diu "contenidors", ni "Kubernetes", ni "REST", ni "Node.js". Totes aquestes eines apareixeran al curs perquè faciliten enormement la feina, però no són el que defineix un microservei. Es poden tenir microserveis sense contenidors i es poden tenir contenidors sense microserveis.

És tan important saber què no és com saber què és. Aquestes situacions es confonen sovint amb microserveis:

Una regla pràctica: si no pots desplegar el component sense coordinar-te amb un altre equip, o si no pots canviar-ne l'esquema de dades sense avisar ningú més, probablement no tens un microservei, sinó un tros d'alguna cosa més gran.

El "micro" no fa referència a línies de codi. No hi ha cap xifra màgica ("menys de 500 línies"). Es refereix al fet que el servei té un abast funcional petit i ben definit: fa una cosa de negoci i la fa completa. Un servei de pagaments pot tenir milers de línies i continuar sent un microservei perfectament raonable; el que importa és que la seva responsabilitat és clara i que s'hi pot raonar sense haver d'entendre tot el sistema.

Les set característiques següents són les que, juntes, distingeixen un microservei. Quan avaluïs un sistema, pregunta't quantes en compleix realment.

El servei pot funcionar, canviar i evolucionar per si mateix. Té el seu propi codi, el seu propi cicle de vida i les seves pròpies decisions internes. L'autonomia és la característica arrel de la qual deriven gairebé totes les altres.

Cada servei es construeix, es prova i es posa en producció per separat, sense necessitat de desplegar la resta del sistema. Si l'equip de Pagaments corregeix un error, puja una nova versió de servei-pagaments i ningú més no se n'assabenta. Això exigeix que les interfícies entre serveis siguin estables i estiguin versionades (ho veurem al mòdul 3).

Els serveis es divideixen seguint el negoci, no les capes tècniques. A TechCorp parlem de "catàleg", "comandes" o "pagaments", no de "servei de base de dades", "servei de lògica" i "servei d'interfície". Un servei conté tot el que necessita per complir la seva capacitat: la seva API, la seva lògica i el seu emmagatzematge.

Aquesta és una diferència important respecte de les arquitectures per capes on se separava "el back-end de dades" del "back-end de negoci": allà una funcionalitat nova obligava a tocar totes les capes i a coordinar tots els equips.

Cada servei és propietari exclusiu de les seves dades. Ningú més no llegeix ni escriu directament a la seva base de dades; si un altre servei necessita aquesta informació, la demana a través de l'API o la rep mitjançant esdeveniments. A TechCorp, el catàleg viurà a MongoDB i les comandes al seu propi PostgreSQL, i servei-comandes no farà mai un SELECT sobre la col·lecció de productes.

Aquesta característica és la més costosa de complir quan es ve d'un monòlit, i li dedicarem una lliçó sencera al mòdul 2.

Els serveis es comuniquen a través de la xarxa fent servir protocols senzills i ben coneguts: normalment HTTP/REST per a peticions síncrones i missatgeria (en el nostre cas RabbitMQ) per a esdeveniments asíncrons. La intel·ligència és als serveis, no a la infraestructura de comunicació. Se sol resumir amb la frase smart endpoints, dumb pipes ("extrems intel·ligents, canonades ximples").

Un servei pertany a un equip que el dissenya, el construeix, el desplega i l'opera ("you build it, you run it"). Aquest equip és responsable que funcioni en producció. A TechCorp, l'equip del Luis serà propietari de servei-comandes de cap a cap.

Amb molts serveis petits és inviable fer desplegaments a mà. Els microserveis pressuposen integració i desplegament continus, infraestructura com a codi, proves automatitzades i monitoratge. Sense automatització, l'arquitectura no escala operativament.

Els microserveis no van aparèixer del no-res. Són l'evolució d'idees anteriors, corregides per l'experiència.

Als anys 2000, les aplicacions empresarials es construïen majoritàriament com a monòlits: una única aplicació gran desplegada en un servidor d'aplicacions. A mesura que creixien, es tornaven difícils de mantenir i d'escalar.

Com a resposta va sorgir la SOA (Service-Oriented Architecture, arquitectura orientada a serveis). La idea era bona: dividir el sistema en serveis reutilitzables. Però la implementació habitual tenia problemes:

• Els serveis es comunicaven a través d'un ESB (Enterprise Service Bus), una peça central que encaminava, transformava i orquestrava missatges. L'ESB va acabar sent un coll d'ampolla tècnic i organitzatiu: tota la intel·ligència era allà.
• Els protocols (SOAP, WS-*) eren pesants i verbosos.
• Els serveis solien compartir bases de dades i desplegar-se de manera coordinada.
• La governança era molt centralitzada: comitès que decidien quins serveis existien i com eren.

Cap al 2011-2014, empreses com Netflix, Amazon o SoundCloud van començar a explicar públicament com havien dividit els seus sistemes en serveis molt petits, autònoms, amb equips propis i comunicació per HTTP. El 2014, James Lewis i Martin Fowler van publicar l'article que va popularitzar el terme i va fixar les característiques que hem vist a l'apartat anterior.

Diversos factors van fer possible aquest enfocament en aquell moment:

En cert sentit, els microserveis són "SOA ben feta": mantenen la idea de serveis però eliminen l'ESB centralitzat, els protocols pesants, la base de dades compartida i la governança rígida.

Al llarg del curs farem servir aquests termes constantment. Aquí només en donem definicions breus; cadascun es desenvoluparà a la lliçó corresponent.

No cal memoritzar la taula: l'anirem fent servir i ampliant. L'important és que, quan aparegui un d'aquests termes, sàpigues a quina família pertany.

TechCorp és l'empresa fictícia que ens acompanyarà durant tot el curs. Opera una botiga online que avui és un únic monòlit en Node.js amb Express i una sola base de dades PostgreSQL. La presentarem amb detall a la lliçó 01-05; de moment, vegem únicament quin aspecte tindria el punt d'arribada: la botiga descomposta en serveis.

Observa diverses coses al diagrama:

• El client no parla directament amb els serveis, sinó amb el gateway. Els serveis interns ni tan sols necessiten ser accessibles des d'Internet.
• Cada servei correspon a una capacitat de negoci: clients, catàleg, inventari, comandes, pagaments, notificacions. No hi ha cap "servei de base de dades" ni cap "servei de lògica".
• Hi ha dos estils de comunicació: fletxes contínues (peticions síncrones, HTTP) i fletxes discontínues (esdeveniments asíncrons a través de RabbitMQ). Quan es crea una comanda, servei-comandes no crida un per un inventari, pagaments i notificacions: publica un esdeveniment i cada interessat hi reacciona.
• Cada servei té el seu propi port perquè és un procés independent. Al mòdul 4 els aixecarem de debò.

Perquè la idea d'"API" deixi de ser abstracta, així es veuria (en pseudo-HTTP, sense implementar) una part mínima del que servei-comandes ofereix a la resta del món.

Crear una comanda:

Consultar una comanda:

Fixa't en el que no apareix en aquests exemples: no hi ha res sobre com es desa la comanda, quina base de dades fa servir el servei, ni com es calcula el total. Qui consumeix l'API només coneix el contracte: la ruta, el format d'entrada i el format de sortida. Aquesta opacitat és precisament el que permet que l'equip del Luis canviï les tripes de servei-comandes quan vulgui sense trencar res a ningú.

També convé notar que la comanda es crea amb estat PENDENT i més tard apareix com a CONFIRMADA. Entremig han passat coses en altres serveis (reservar estoc, cobrar) de les quals el consumidor no s'assabenta directament. Aquest flux, "un client fa una comanda", és el fil conductor de tot el curs i l'esmicolarem a la lliçó 01-05.

• Confondre l'eina amb l'arquitectura. Fer servir Docker i Kubernetes no converteix un sistema en microserveis. Pregunta't per les set característiques, no per l'stack.
• Pensar que "micro" vol dir diminut. Serveis excessivament petits (de vegades anomenats nanoserveis) multipliquen la comunicació i el cost operatiu sense aportar autonomia real. La mida correcta la dicta la capacitat de negoci, no un límit de línies.
• Dividir per capes tècniques. Un "servei d'accés a dades" i un "servei de lògica" no són microserveis; són un monòlit partit per la meitat que obliga a desplegar-los tots dos alhora.
• Compartir la base de dades "només al principi". És la manera més habitual d'acabar amb un monòlit distribuït. Si dos serveis comparteixen taules, a la pràctica en són un.
• Ignorar la part organitzativa. La propietat per equips i l'automatització no són detalls opcionals; sense elles l'arquitectura no s'aguanta. Ho veurem amb més detall a la lliçó 01-04.
• Consell: quan llegeixis sobre un sistema "de microserveis", intenta identificar quina és la seva unitat de desplegament i qui és propietari de cada dada. Aquestes dues preguntes desmunten la majoria de les afirmacions falses.

Per a cada situació, indica si descriu un microservei i justifica-ho amb almenys una de les set característiques.

1. TechCorp desplega el seu monòlit actual en quatre servidors idèntics darrere d'un balancejador de càrrega.
2. L'equip de Màrqueting crea una petita aplicació independent en Python que gestiona cupons, amb la seva pròpia base de dades, la seva pròpia API REST i el seu propi pipeline de desplegament.
3. L'equip de Comandes extreu la lògica de comandes a un procés Node.js separat, però aquest continua llegint i escrivint directament a les taules productes i clients de la base de dades del monòlit.

Relaciona cada frase amb el terme del vocabulari que descriu:

• a) "Quan es confirma un pagament, es publica un missatge perquè qui ho necessiti hi reaccioni."
• b) "Per Black Friday aixequem vuit còpies del servei de catàleg."
• c) "Totes les peticions de l'app mòbil entren pel mateix lloc, que decideix a quin servei enviar-les."
• d) "Documentem les rutes, camps i codis d'error de l'API de comandes i ens comprometem a no trencar-los."
• e) "Podem veure que la petició va passar per tres serveis i en quin es va perdre el temps."

Seguint l'estil dels exemples de pseudo-HTTP de la lliçó, escriu dos endpoints que podria exposar servei-cataleg: un per consultar un producte pel seu identificador i un altre per llistar productes filtrant per categoria. Indica mètode, ruta, un exemple de resposta i el codi d'estat. No implementis res; només es tracta de pensar en el contracte.

Exercici 1

1. No. És el mateix monòlit replicat. La unitat de desplegament continua sent una (falla el desplegament independent) i totes les rèpliques comparteixen codi i base de dades (falla la descentralització de dades).
2. Sí. Compleix autonomia, desplegament independent, capacitat de negoci pròpia (cupons), dades pròpies i API lleugera. A més, il·lustra l'heterogeneïtat tecnològica: pot estar en Python encara que la resta sigui Node.js.
3. No (encara). Tot i que és un procés separat, accedeix directament a dades d'altres àrees. És un monòlit distribuït en miniatura: qualsevol canvi a productes o clients pot trencar aquest procés, i viceversa. Per ser un microservei hauria d'obtenir aquesta informació a través de les APIs o esdeveniments de catàleg i clients.

Exercici 2

• a) Esdeveniment (i per extensió, broker de missatges).
• b) Instància (diverses instàncies del mateix servei).
• c) Gateway (API Gateway).
• d) Contracte.
• e) Traça distribuïda (observabilitat).

Exercici 3 (una solució possible)

Punts a valorar: rutes basades en substantius (/productes), ús de GET per a consultes, filtres per query string, resposta amb paginació i un 404 Not Found (no mostrat) si el producte no existeix. Tot el que fa referència al bon disseny REST es desenvolupa a la lliçó 03-01.

En aquesta lliçó hem establert la definició de treball de microservei: un component autònom, centrat en una capacitat de negoci, desplegable per separat, propietari de les seves dades i que es comunica per interfícies lleugeres. Hem vist que les set característiques (autonomia, desplegament independent, modelatge per capacitat de negoci, dades descentralitzades, APIs lleugeres, propietat per equips i automatització) són les que distingeixen un microservei, i que cap tecnologia concreta no el defineix. Hem situat la idea en el seu context històric, com a correcció dels errors de la SOA clàssica, i hem fixat el vocabulari que farem servir d'ara endavant. Finalment, hem fet un primer cop d'ull al mapa de serveis de TechCorp i al que significa que un servei "exposi una API".

Amb aquests fonaments, la lliçó següent aborda la pregunta que tothom es fa a continuació: què es guanya i què es paga en adoptar aquesta arquitectura? Veurem els avantatges i els desavantatges dels microserveis il·lustrats amb situacions concretes de TechCorp.