Spring GDS 25è Aniversari
Una empresa de logística que envia a 190 països va construir alguna cosa per enviar-se a si mateixa.
Un monòlit és una aplicació construïda i desplegada com una sola unitat. La interfície d'usuari, la lògica de negoci i l'accés a dades viuen tots en un únic codi, compilen junts i es despleguen junts. Quan despleges, despleges el conjunt sencer. Durant la major part de la història del software això era senzillament com es construïen les aplicacions, i per a moltíssims projectes segueix sent l'opció correcta.
El punt de comparació habitual són els microserveis, on una aplicació es divideix en molts serveis petits que corren i despleguen de manera independent. El monòlit ho manté tot en un lloc, cosa que el fa més fàcil de desenvolupar al principi, més simple de provar d'extrem a extrem i més ràpid de raonar perquè no hi ha salts de xarxa entre parts. El cost és que es torna més pesat amb el temps. Un canvi petit implica tornar a desplegar l'aplicació sencera, i la feina d'un equip pot xocar amb la d'un altre al mateix codi. Una startup que treu el seu primer producte gairebé sempre es beneficia d'un monòlit, i després revisa la qüestió quan l'escala i la mida de l'equip comencen a fer cruixir aquesta única unitat.
El plantejament honest és que "monòlit" no és un insult i "microserveis" no és un trofeu. Els microserveis resolen problemes reals d'escala i organització però afegeixen una complexitat operativa que els equips petits paguen sense treure'n el benefici. Moltes empreses que es van llançar a dividir-ho tot han tornat a posar feina dins d'un monòlit ben organitzat. L'arquitectura s'hauria d'ajustar a la mida del problema, no a la mida de l'ambició.
Arrenquem la majoria de productes com un monòlit, i ho diem sense embuts fins i tot quan un client arriba demanant microserveis. Un monòlit net i modular surt abans, costa menys d'operar i és molt més fàcil de canviar mentre el producte encara busca la seva forma. Hem assumit més d'un projecte on una divisió prematura va deixar un equip petit ofegat en infraestructura, i l'arranjament va ser consolidar, no fragmentar més.
Quan l'escala o l'estructura de l'equip ho demanen de debò, dividim amb deliberació, traient les peces que necessiten escalar o desplegar pel seu compte en lloc de reescriure-ho tot de cop. Les aplicacions web a mida que construïm estan arquitecturades perquè aquesta frontera es pugui traçar més tard sense un enderroc. Prenem la decisió sobre l'evidència, amb el client, i estem còmodes recomanant la resposta avorrida quan és la correcta.
Dubtes si començar amb un monòlit o dividir-lo? Dimensionem primer el problema.
Una empresa de logística que envia a 190 països va construir alguna cosa per enviar-se a si mateixa.
Convertir una marca en un negoci que funciona.
Mig milió de persones. Una app. Zero caos.















