Gestire dati e crediti deteriorati con tecnologie cloud

• unico scopo: ogni servizio dovrebbe concentrarsi su un unico scopo e farlo bene.
• disaccoppiamento: i servizi sanno poco l’uno dell’altro. Una modifica a un servizio non dovrebbe richiedere la modifica degli altri. La comunicazione tra i servizi dovrebbe avvenire solo attraverso le interfacce (REST API) esposte pubblicamente dal servizio.
• forte coesione: ogni servizio racchiude insieme tutti i comportamenti e i dati correlati. Se è necessario creare una nuova funzionalità, tutte le modifiche dovrebbero essere localizzate in un unico servizio.

• microservizi: non è un servizio che dispone di un numero limitato di righe di codice o esegue attività “micro”, come si può immaginare dal nome “microservizio”. L’obiettivo di un’architettura a microservizi non è avere il maggior numero possibile di piccoli servizi. I servizi possono essere anche complessi purché soddisfino le tre proprietà di cui sopra. Nel caso in cui abbia necessità di persistenza del dato (stateful), dovrà aver un database proprio, indipendente e unico al servizio.
• nanoservizi: rappresentano proprio servizi orientati al “micro/nano” task. Spesso espongono un’unica API e hanno uno scopo ben preciso. Sono paragonabili a singole “funzioni stateless”, e spesso rappresentate da soluzioni “serverless”, che non necessitano di stato persistente (e quindi senza database in assoluto).

Ci sono due modi di gestione: il primo è il modello sincrono REST, in cui ogni passo della catena effettua una chiamata esterna al servizio del passo seguente e attende la risposta; il secondo è un modello asincrono basato su messaggi e argomenti (topics).