Ti mancano i microservizi, sbrigati.

"I monoliti sono obsoleti! Scomponi tutto!". Era già il 2015, o poco prima.

Veramente già esistevano i Service Oriented Architecture (SOA), e la modularità concettualmente 20 secoli fa.
Con il SOA era più grossolano. A volte avevi architetture che facevano ridere, o meglio, adatte a delle ncessità meno challegning, cosi rimaniamo educati.
Sembra che ancora molte applicazioni girano ancora con SOAP (e relativo WSDL), che non è una saponetta, ma un formato di scambio in XML.
Un formato che per dire "ciao" impiega solo l'anti-logica di ottimizzazione.
Tutti protocolli nati per dire quanto siamo speciali perché l'IT è complicata, compra da noi. Robba forte.
Più il nome delle soluzioni è altisonante o vuole essere importante, più devi diffidare, vedi "Business Intelligence". Scusate la digressione e polemica velata.

Netflix

Non a caso quando si è trattato di dover gestire milioni di istanze a scala planeteria, qualcuno a comminciato a definire i suoi microservizi,
e qualcun'altro abbandonato la saponetta (scusate SOAP) per passare a REST, o meglio Google (prima della release pubblica nel 2015) ha definito e usato gRPC...
Chiaro, gRPC e relativo Protocol Buffers meno diffuso negli interscambi tra sistemi che non lo usano.
E sappiamo bene che con l'avvento delle app su smartphone (no non era tanto tempo fa), hanno scoperchiato necessariamente l'inganno del messaggio commerciale "più complicato (e non ho detto più complesso), più caro, più indispensabile".
Uno potrebbe dire esigenze diverse, soluzioni diverse. Mah, in teoria se inginerizzi, provi a non andare verso il caos, verboso, e contro la salutà umana.

Dicevamo, devo o non devo parlare di microservizi? Anni fa spopolavano articoli derivati da tech blog di Netflix.
Quindi ci serve. Amazon offre microservizi, non puoi scalare un monolito! Legge di Conway, Implementazioni indipendenti.

Difficile non sposare questo minimo architetturale, ma al di delle soluzioni salvifiche, si chiama MODULARITA'!
Vantaggi dell'approcio microservice? Ovviamente:

• Scalabilità indipendente,
• autonomia del team,
• diversità tecnologica (sono meno vincolato ad un unica tech, maggiore flessibilità),
• 'guasti' isolati,
• servizi di piccole dimensioni più facili da comprendere, etc...

Non vuoi polemizzare, ma:

Il tuo team di 5 persone ora gestisce 40 microservizi.
Una semplice registrazione utente richiede 7 chiamate di servizio. Il debug si estende su 12 diversi sistemi di aggregazione dei log.
Hai transazioni distribuite ovunque. La tua "architettura a microservizi" significa che ogni servizio chiama tutti gli altri servizi.
Metà della tua fattura cloud è rappresentata dal trasferimento dati tra servizi.
Hai bisogno di tracciamento distribuito, service mesh, gateway API e un team DevOps dedicato solo per implementare una funzionalità.
Il tuo monolite che serviva 10 milioni di utenti senza problemi ora è composto da 50 servizi che non riescono a gestirne 10.000.

Allora sei proprio tu che forse hai frammentato troppo? Martin Fowler ne aveva già parlato e avvisato tutti.

Ma oggi?

Vuoi parlare di un architettura ben strutturata ? Trova gli interlocutori giusti, se li trovi.
A meno che tutti manager nell'IT sono di colpo CEO o proprietari di fondi.. "A noi interessa che funzioni e basta, le tecnologie ci sono".