Durant l'última dècada, els microserveis s'han convertit en l'estendard de l'arquitectura moderna. Cada startup que es preï dibuixa a la seva pissarra un conjunt de serveis independents: autenticació, comandes, notificacions, un broker de missatges i una API Gateway. El problema és que la majoria d'aquests equips no tenen el problema que els microserveis resolen. Aquest article no és un atac a l'arquitectura distribuïda, sinó una crida a l'honestedat tècnica: els microserveis són un patró d'escalat organitzatiu, no una actualització tècnica. Aplicar-los sense la pressió real de múltiples equips independents genera un deute tècnic que pocs calculen.
Per entendre-ho, primer definim què són exactament els microserveis. Es tracta d'un estil arquitectònic on una aplicació es divideix en serveis petits, desplegables de forma independent, cadascun amb la seva pròpia lògica de negoci, base de dades i comunicació per xarxa. En teoria, això permet escalar cada component per separat, desplegar sense coordinar, aïllar errors i fins i tot utilitzar diferents llenguatges de programació. Sona fantàstic, i ho és… quan ho necessites. El problema apareix quan es copia el model de gegants com Netflix, Amazon o Uber sense patir els seus dolors de creixement. Ells no van adoptar microserveis per moda, sinó perquè tenien centenars d'equips trepitjant-se els talons. El seu problema era organitzatiu: la comunicació entre equips s'havia convertit en el coll d'ampolla. Per a un equip de tres persones, la mateixa arquitectura és una càrrega innecessària.
La veritat incòmoda és que un monòlit ben dissenyat escala perfectament. Stack Overflow, Shopify, GitHub i Basecamp són exemples d'aplicacions que gestionen trànsit massiu amb arquitectures modulars, no distribuïdes. El coll d'ampolla real gairebé mai no està a la capa d'aplicació, sinó en una consulta lenta, un índex absent, un N+1 o una fila calenta a la base de dades. Els microserveis no arreglen res d'això. Al contrari, afegeixen latència, complexitat operativa i una factura fixa que pagaràs cada mes: pipelines de CI/CD, traces distribuïdes, consistència eventual, retries, timeouts, i un munt d'eines que abans no necessitaves.
L'alternativa sensata és el monòlit modular: un únic artifacte desplegable, però internament dividit en mòduls amb fronteres explícites. Cada mòdul és propietari de les seves taules, exposa una API pública reduïda i protegeix la seva implementació amb regles de lint. Així obtens l'aïllament que prometen els microserveis sense pagar el peatge de la xarxa. Els esdeveniments en procés són el teu mecanisme de comunicació entre mòduls: són asíncrons, traçables i, quan un mòdul creixi prou, podràs extreure'l a un servei real amb un cost mínim. Perquè extreure un mòdul ben delimitat és un projecte de setmanes; fusionar dos serveis les fronteres dels quals van resultar equivocades és un malson.
A Q2BSTUDIO, com a empresa de desenvolupament de programari i tecnologia, hem vist desenes d'equips caure al parany dels microserveis prematurs. La nostra recomanació és clara: comença amb un sol desplegament. Inverteix en aplicacions a mida que s'ajustin a la teva organització real, no a la d'una big tech. Si més endavant la pressió de l'equip o la càrrega de treball ho justifica, extreu un mòdul concret. No converteixis tota l'aplicació en un trencaclosques distribuït abans d'hora.
I quan tenen sentit els microserveis? Quan tens almenys quatre equips independents (uns 25 enginyers) els cicles de desplegament dels quals xoquen constantment. O quan un component requereix un perfil de recursos molt diferent, com GPUs, un runtime diferent o un perímetre de compliment normatiu especial (dades sanitàries, targetes de crèdit). També quan necessites aïllament d'errors per seguretat (execució de codi no fiable) o un cicle de vida separat (edge workers, APIs públiques). En aquests casos, extreure un únic servei té sentit. Però el camí correcte és: monòlit → monòlit modular → extracció selectiva, i cada pas ha d'estar justificat per evidència, no per prediccions.
L'error més comú és començar amb microserveis 'per no haver de migrar després'. Això és una fal·làcia: començar distribuït no evita la migració, la garanteix pitjor. Les fronteres entre serveis són el més difícil de canviar en un sistema distribuït. I al principi d'un producte, el teu coneixement del domini és mínim. Dibuixar fronteres equivocades a la capa de xarxa és caríssim de corregir. En canvi, un monòlit modular manté totes les opcions obertes. Si les fronteres estan malament, refactoritzes en una tarda. Si estan bé, extreus sense dolor. És la decisió reversible.
Des de la perspectiva de negoci, la modularitat ben gestionada també potencia la innovació. Pots integrar serveis cloud AWS/Azure per escalar sota demanda, aplicar intel·ligència artificial en processos concrets, reforçar la ciberseguretat amb pentesting i firewalls d'aplicació, o implementar dashboards de BI/Power BI per monitoritzar el rendiment. Però tot això es pot fer des d'un monòlit modular, sense necessitat de fragmentar el sistema en vint serveis. La clau està en l'estratègia, no en el dogma.
Si ja estàs en un ecosistema de microserveis, no intentis unificar-ho tot de cop. Això seria el mateix error al revés. Atura la fragmentació: no creïs nous serveis a menys que un problema observat ho exigeixi. Fusiona aquells que sempre es despleguen junts (són un monòlit distribuït pagant preus de xarxa). Inverteix en traçabilitat, contractes i desenvolupament local. I recorda: la bona arquitectura no consisteix a maximitzar o minimitzar el nombre de serveis, sinó a alinear el sistema amb l'organització i la càrrega de treball real que tens.
En resum, abans de dibuixar aquella pissarra amb nou serveis, pregunta't: el meu equip té el problema que això resol? Si no és així, construeix un monòlit modular del qual puguis estar orgullós. Deixa que l'organigrama, no la moda, et digui quan és moment de partir. I quan aquell moment arribi, Q2BSTUDIO serà aquí per ajudar-te a fer-ho amb cap.
