Created on Monday, 24 Jan 2022 16:14:00

Article escrit per Jose Manuel Reche d'IThink UPC 

Monòlit o microserveis? És un tema que ha generat i que continua generant molt de debat en l’àmbit de l’arquitectura d’aplicacions. Mentre que les aplicacions monolítiques han predominat durant molt de temps, els microserveis han fet canviar aquesta tendència, però això no vol dir que els microserveis siguin la “bala de plata” per a l’arquitectura de totes les aplicacions; en alguns casos poden representar una mala decisió, sobretot per una “sobreenginyeria” no justificada.

Al capdavall, la resposta per decidir entre una arquitectura o l’altra és “depèn”, tal com va citar Kent Beck: “Any decent answer to an interesting question begins, ‘it depends…’”. I el “depèn” fa referència a molts factors que no tenen per què estar relacionats només amb la tecnologia.

Optar entre un dels dos estils arquitectònics ha de ser una decisió concisa basada en una sèrie de factors. Abans d’adoptar una arquitectura, hem de pensar què ens pot aportar respecte del que tenim actualment o si pot solucionar alguna cosa que no podem solucionar amb l’arquitectura actual. Pot ser que una arquitectura que funcioni en una empresa no sigui l'adequada per a una altra, o fins i tot per a la mateixa empresa però en un projecte diferent. De vegades, alguns opten per implementar arquitectures amb tecnologies que s’empren en les grans empreses tecnològiques GAFAM com a referent, i no per això té per què ser la solució idònia per a tots els casos.

Monòlit: avantatges i inconvenients

  • Avantatges 
    • Facilitat de desplegament: El desplegament d’una aplicació monolítica és molt simple, no necessita orquestració ni gestió amb altres components ni aplicacions.
    • Fàcil de sotmetre a proves i debug: Tot el codi està en una mateixa aplicació, cosa que facilita les proves, el debugging i el monitoratge. 
    • Menys latència: A causa del fet que un monòlit (a diferència dels microserveis) no necessita tanta comunicació/dependència amb altres components/serveis, la latència és menor.
    • Agilitat: En alguns casos, per raons de time-to-market, s’opta per desenvolupar una aplicació en mode monolith first i després es van migrant els casos d’ús que es justifiquin cap a microserveis.
  • Inconvenients
    • Complexa de mantenir: Si un monòlit no està ben dissenyat en mòduls i suficientment desacoblat, segons va creixent la mida de l’aplicació pot arribar a representar un alt cost per la complexitat de manteniment del codi (deute tècnic).
    • Escalabilitat: Per escalar un monòlit s’ha de desplegar tota l’aplicació, amb la qual cosa requerim més infraestructura, fins i tot quan l’escalabilitat només sigui requerida en pocs casos d’ús. D’altra banda, l’aplicació ha d’estar dissenyada per ser desplegada en clustering (sense sessions adherents, sense processos concurrents que s’encavalquin, etc.).
    • Lligada a la tecnologia: Quan es desenvolupa un monòlit, s’estableix una tecnologia/framework i tot l’equip queda lligat a aquesta tecnologia, cosa que fa impossible el fet de poder emprar solucions tecnològiques diferents (frameworks, llibreries, etc.,) en funció de cada cas d’ús i els seus requisits.
    • Punt únic de fallada: En cas que falli alguna cosa en el monòlit, podria arribar a afectar tota l’aplicació, cosa que es coneix com a single point of failure (SPOF).

Microserveis: avantatges i inconvenients

  • Avantatges
    • Llibertat tecnològica: A causa del fet que els microserveis són projectes independents fins i tot a nivell de base de dades, dona agilitat per decidir i implantar la tecnologia a emprar en funció dels requisits de negoci per a cada cas.
    • Desacoblament: Alt desacoblament, cada microservei gestiona el propi domini sense dependre d'altres.
    • Escalabilitat: A l’hora d’escalar, només s’escalen els microserveis que calgui escalar, a diferència d’un monòlit, en què és necessari escalar tota l’aplicació.
    • Mantenibilitat: Els projectes basats en microserveis són més fàcils de mantenir a causa del fet que, en comparació amb un monòlit, tenen menys codi i són més especialitzats i específics. Cada microservei té (ha de tenir) una única responsabilitat.
  • Inconvenients
    • Complexitat: Una arquitectura de microserveis pot arribar a ser molt complexa, a causa del fet que hi intervenen molts factors, ja que l’arquitectura està distribuïda en diferents projectes i infraestructures en què s’han de tenir en compte factors diferents, com per exemple la comunicació entre els microserveis, seguretat, orquestració, coreografia, resiliència, latència, consistència de dades, etc.
    • Proves i traçabilitat: Com que és un context distribuït, el cost d’implantar i executar les proves és més complicat, i el mateix passa amb la traçabilitat, que requereix la implantació d’eines específiques.
    • Consistència eventual de dades: Com que cada microservei ha de tenir —o és recomanable que tingui— la seva pròpia base de dades per gestionar el domini, sorgeixen problemes com el cas de la “consistència eventual de les dades” que el projecte ha d’assumir i gestionar.
    • Infraestructura: Els microserveis requereixen més infraestructura, sobretot en relació amb la comunicació entre microserveis (East-West traffic), i encara més si s’opta per una solució basada en esdeveniments (event-driven microservice architecture).

Només hem fet esment d’alguns avantatges i inconvenients per a cada cas, però la llista pot ser més extensa segons la mida del projecte i els requisits tècnics i de negoci.

En resum, hi ha molts factors que intervenen a l’hora de decidir entre monòlit o microserveis, però sobretot no s’ha de creure que un monòlit és la manera “antiga” de desenvolupar aplicacions i que els microserveis són la “nova”. Com s’ha descrit prèviament, la resposta és “depèn”.

Independentment de si comencem amb un monòlit o un microservei, el més important és que el codi estigui desacoblat i modularitzat i que apliqui una sèrie de patrons bàsics com els principis SOLID i les seves proves respectives, de manera que puguem anar refactoritzant l’aplicació amb facilitat cap a altres arquitectures a més de facilitar-ne el manteniment.

Si tens previst desenvolupar un nou projecte (greenfield) o refactoritzar un projecte llegat (brownfield) i no saps decidir-te entre monòlit o microserveis, contacta amb nosaltres; et podem ajudar tant si es tracta de decisions tècniques, assessorament, auditoria o la implantació de la solució.

Consulta la web d'IThink UPC 



Comparteix això:

12 de juny de 2024

21a Festibity

12 de juny de 2024

#ITalent

Sobre nosaltres

"La gran festa de les tecnologies de la informació"

         

 

Contacte

Per a més informació:

festibity@festibity.com

T. 93 000 92 02