Monòlit vs microserveis: per què el teu projecte probablement no necessita el segon

Segur que has sentit la història. Una startup arrenca amb un monòlit, creix, s'ofega, migra a microserveis i tot funciona. Netflix ho va fer. Amazon ho va fer. Spotify ho va fer.

El que no s'explica tant és el context. Netflix va migrar quan tenia cent milions d?usuaris i milers d?enginyers. El teu projecte probablement no té ni una cosa ni l'altra. I això canvia completament l'equació.

Al debat monòlit vs microserveis, l'error més freqüent no és triar malament l'arquitectura. És triar-la massa aviat, basant-se en el que fan empreses que no s'assemblen gens a la teva.

Què és cada cosa (sense embuts)

Un monòlit és una aplicació on tot el codi viu junts: la lògica de negoci, la gestió d'usuaris, els pagaments, les notificacions. Es desplega com una sola unitat. Quan actualitzes una part, ho desplegues tot.

Els microserveis divideixen aquesta aplicació en serveis independents. Cada servei fa una cosa, té la seva pròpia base de dades i es comunica amb els altres mitjançant APIs o missatgeria. Es despleguen per separat.

Fins aquí, la teoria. La pràctica és on les coses es compliquen.

El que el monòlit fa bé (i ningú no vol admetre)

El monòlit té mala premsa. Sona a antic, a limitat, a “no escala”. Però hi ha raons sòlides per les quals continua sent la millor opció per a la majoria de projectes.

Simplicitat operativa. Una base de codi, un desplegament, una base de dades. No necessites orquestradors de contenidors, service mesh, API gateways ni eines de traçabilitat distribuïda. El teu equip es pot centrar en construir producte en lloc de mantenir infraestructura.

Velocitat de desenvolupament. En un monòlit, refactoritzar és canviar codi al mateix repositori. No cal coordinar canvis entre cinc serveis, versionar API ni gestionar contractes de comunicació. Per a equips petits (menys de 10-15 desenvolupadors), aquesta simplicitat es tradueix directament a velocitat.

Debugging directe. Quan alguna cosa falla en un monòlit, l'stack trace et diu exactament on. En microserveis, un error pot implicar rastrejar trucades entre sis serveis, amb logs distribuïts i latències de xarxa que compliquen el diagnòstic.

Transaccions simples. Si la vostra operació necessita actualitzar tres taules de forma atòmica, en un monòlit és una transacció de base de dades. En microserveis, és un patró saga amb compensacions, idempotència i gestió de fallades parcials. La complexitat es multiplica.

Cost. Un monòlit corre en un servidor o un clúster senzill. Els microserveis necessiten infraestructura per a cada servei, balancejadors, cues de missatges, registres de serveis. Segons dades d' InfoQ , el cost operatiu d'una arquitectura de microserveis pot ser entre 3 i 10 vegades més gran que el d'un monòlit equivalent a les fases inicials.

El que els microserveis fan bé (quan els necessites)

Els microserveis no són una moda sense fonament. Resolen problemes reals. Però problemes que apareixen a una escala i complexitat específiques.

Escalat independent. Si el 90% del trànsit va a un mòdul concret (recerca, per exemple), amb microserveis pots escalar només aquest servei en lloc de replicar tota l'aplicació. En un monòlit, escales tot o res.

Equips autònoms. Quan tens 50, 100 o 200 desenvolupadors, un monòlit es converteix en un coll dʻampolla organitzatiu. Tothom treballa al mateix codi, els conflictes de merge són constants i els desplegaments es coordinen amb dolor. Els microserveis permeten que cada equip sigui amo del seu servei i desplegament al seu ritme.

Tecnologia heterogènia. Cada servei pot utilitzar el llenguatge i la base de dades que millor encaixi amb el vostre problema. El servei de cerca pot fer servir Elasticsearch, el de pagaments pot córrer en Java amb garanties de tipus estrictes, i el de notificacions pot ser una funció serverless. En un monòlit, tot comparteix stack.

Aïllament de fallades. Si un microservei cau, els altres poden continuar funcionant (si estan ben dissenyats). En un monòlit, una fallada en un mòdul pot tombar tota l'aplicació. Això és crític en sistemes on la disponibilitat és un requisit de negoci.

Les preguntes que t'hauries de fer

Abans d'escollir entre monòlit i microserveis, respon això amb honestedat:

Quantes persones hi ha al teu equip de desenvolupament? Si són menys de 10-15, un monòlit et donarà més velocitat. L'overhead organitzatiu dels microserveis no es justifica amb petits equips. No és una opinió: és el patró que es repeteix a la indústria.

El teu producte ja té tracció? Si estàs validant una idea, construint un MVP oa les primeres fases de creixement, el monòlit et permet iterar més ràpid. Pots migrar després, quan tinguis dades reals sobre on són els colls dampolla. Invertir en microserveis abans de tenir usuaris és optimitzar per a problemes que potser mai no arribin.

Tens problemes d'escalat reals? "Necessitem escalar" i "necessitarem escalar algun dia" són frases molt diferents. Si el teu monòlit maneja el trànsit actual sense suar, no necessites microserveis.

Un monòlit ben construït amb Django o frameworks similars pot servir milions de peticions al dia. No és cap limitació: és una solució que funciona.

El teu equip té experiència en sistemes distribuïts? Els microserveis no eliminen la complexitat: la traslladen de l‟aplicació a la infraestructura. Necessites gent que sàpiga de networking, observabilitat, orquestració de contenidors, patrons de resiliència i debugging distribuït. Si el vostre equip no té aquesta experiència, la corba d'aprenentatge frenarà el desenvolupament durant mesos.

Pots assumir-ne el cost operatiu? Més serveis significa més infraestructura, més monitoratge, més alertes, més punts de fallada. Segons Martin Fowler , els microserveis tenen un "premium" de complexitat que només es justifica quan l'alternativa (el monòlit) ja no pot absorbir el creixement.

El camí intermedi que ningú esmenta

La conversa monòlit vs microserveis sol presentar-se com una decisió binària. Monòlit o microserveis. Blanc o negre. Però hi ha un punt intermedi que funciona molt bé per a la majoria de projectes en creixement: el monòlit modular.

Un monòlit modular és una aplicació que es desplega com una sola unitat, però el codi de la qual està organitzat en mòduls independents amb límits clars. Cada mòdul té la seva pròpia lògica, els seus models de dades i una interfície ben definida amb la resta.

L'avantatge: tens la simplicitat operativa del monòlit amb la separació lògica que després facilita extreure'n serveis si realment ho necessites. No és cap compromís: és una estratègia.

Shopify és un cas conegut. Segons el seu propi equip d'enginyeria, van apostar per modularitzar el monòlit en lloc de migrar a microserveis. Processen milers de milions en transaccions amb aquesta arquitectura. Si els funciona, probablement funcioni per al teu projecte.

Quan té sentit migrar

Si ja tens un monòlit i estàs considerant microserveis, hi ha senyals clars que el moment ha arribat:

Els desplegaments són un coll de botella. Diversos equips necessiten desplegar a diferents ritmes i el monòlit ho impedeix. Les cues de merge creixen i els desplegaments es retarden dies.

Un mòdul necessita escalar molt per sobre de la resta. Si el 5% del teu codi consumeix el 80% dels recursos, té sentit extreure'l com a servei independent. Però només aquest mòdul, no tot.

El monòlit s'ha tornat immanejable en termes de deute tècnic. La base de codi és tan gran i està tan acoblada que cap canvi no és segur. Abans de migrar a microserveis, valora si refactoritzar el monòlit no resol el problema amb menys risc.

La teva organització ha crescut fins al punt de necessitar equips autònoms. Si tens 40+ desenvolupadors i la coordinació dins del monòlit ja no funciona, la divisió en serveis pot ser la resposta organitzativa (no només tècnica).

Si cap d'aquests senyals encaixa, probablement no necessiteu microserveis. I això està bé.

L'arquitectura no és una declaració d'intencions

Triar monòlit no és admetre que el teu projecte és petit. Triar microserveis no demostra que el teu equip és modern. L'arquitectura és una ferramenta, no una identitat.

El que importa és que la decisió es prengui amb dades, no pas amb modes. Que respongui a problemes reals del teu equip i producte, no al que va fer Netflix fa deu anys.

Comença simple. Construeix un monòlit modular, ben estructurat, amb límits clars entre mòduls. Quan les dades et diguin que necessites distribuir, tindràs una base sòlida des d'on fer-ho.

I si aquest moment mai no arriba, hauràs estalviat mesos de complexitat innecessària.