Quando basta un monolite, quando si separa. Conway's Law, topologie di team — e perché la risposta non è «microservizi».
Categoria · DevOps & Infra
Due architetture, una valutazione.
Un monolite tiene l'intera applicazione in un'unica codebase e un unico deployment. I microservizi la scompongono in molti servizi autonomi, sviluppati, rilasciati e scalati separatamente.
Entrambi sono legittimi. La separazione costa complessità — rete, consistenza dei dati, gestione operativa — e questo prezzo deve essere giustificato da un beneficio reale.
Quando separare.
La legge di Conway afferma che i sistemi rispecchiano la struttura di comunicazione della loro organizzazione. I microservizi hanno senso quando più team autonomi devono consegnare in modo indipendente, senza bloccarsi a vicenda.
Fino ad allora, da noi si costruisce di solito un monolite ben strutturato — più rapido da sviluppare, più semplice da gestire, più facile da capire. Separare lo si può fare dopo, in modo mirato lungo la cucitura che fa davvero male.
Perché la risposta non è "microservizi".
I microservizi come decisione di default portano a monoliti distribuiti: tutti gli svantaggi della distribuzione, nessuno dei suoi vantaggi. È l'errore costoso più frequente in questo campo.
La domanda giusta non è "monolite o microservizi", ma "dove passa il confine in cui la consegna autonoma crea valore reale". Solo questo confine giustifica il taglio.
