Microservizi vs monolite: quando ha senso cambiare architettura

I microservizi sono diventati quasi un dogma nello sviluppo software moderno. Eppure negli ultimi anni alcune delle aziende tecnologiche piu avanzate hanno raccontato di essere tornate verso architetture piu monolitiche per specifici use case. La scelta dipende dal contesto, non dalla moda.

Il monolite non e una parolaccia

Un monolite ben strutturato, il cosiddetto modular monolith, e piu semplice da sviluppare, testare, fare il deploy e debuggare. Non ha la complessita operativa dei microservizi: niente service mesh, niente distributed tracing, niente problemi di coerenza dei dati tra servizi. Per team piccoli e applicazioni con carico moderato e spesso la scelta piu sensata.

Quando i microservizi hanno senso

Scala di team: quando il team supera le 20-30 persone e diversi team devono lavorare in parallelo, il monolite diventa un collo di bottiglia. I microservizi permettono a team autonomi di rilasciare in modo indipendente.

Requisiti di scala diversi: se il modulo di ricerca deve gestire 100 volte il carico del modulo di pagamento, ha senso scalarlo indipendentemente.

Tecnologie diverse per problemi diversi: elaborazione video, ML, transazioni finanziarie richiedono spesso stack tecnologici diversi.

I costi nascosti dei microservizi

Latenza di rete tra servizi, complessita del testing end-to-end, gestione delle versioni delle API interne, distributed tracing, coerenza eventuale dei dati: questi problemi non esistono nel monolite e richiedono competenze specifiche. Un team che non li ha mai gestiti sottostima sistematicamente il costo di migrazione.

La strategia migliore: strangler fig

Se si parte da un monolite e si vuole migrare, il pattern strangler fig e il piu sicuro: si estrae gradualmente funzionalita in servizi separati, senza mai riscrivere tutto da zero. Il monolite si svuota progressivamente mentre il sistema rimane sempre in produzione.