Tags: Tecnologie per gli NPL
Gestire dati e crediti deteriorati con tecnologie cloud
Cherry Bit nasce da una visione, che deriva dalla crescente digitalizzazione in Italia del patrimonio informativo utile al mondo NPL avvenuta negli ultimi 10 anni. Si parla sempre dell’importanza della digitalizzazione dei dati e dei processi, senza spesso avere chiaro quanto sia abilitante. Ma abilitante per cosa? Nuove opportunità. Opportunità che fanno nascere realtà come Cherry Bit, un gruppo di ingegneri che cercano di utilizzare la tecnologia per creare efficienza attraverso l’ innovazione a servizio del settore del credito. Basti pensare a come 10 anni fa una realtà di questo tipo non sarebbe potuta esistere, nonostante la maggior parte della tecnologia a supporto che utilizziamo tutt’oggi, esistesse già. Questo patrimonio informativo digitale, per quanto ancora acerbo e poco sviluppato, è sempre in crescita, e genera una grande mole di dati che costituisce un valore potenziale enorme per chi sa interpretarli. La sfida quindi è rappresentata dal poter sfruttare al meglio questo mare di dati (dai un occhio al nostro osservatorio Cherry Sea), grazie alle più recenti tecnologie cloud, che permettano di processarli, trasformarli ed analizzarli in poco tempo. In un precedente blog post abbiamo parlato dell’importanza e dei vantaggi dell’utilizzo di un’architettura a microservizi. Tutti i vantaggi però comportano inevitabilmente un costo: complessità. Complessità in termini sicuramente di gestione, dovendo padroneggiare componenti come orchestratori (Kubernetes) e associati. Ma anche in termini architetturali. Lo spostamento da un’architettura monolitica consistente, fortemente accoppiata tra le diverse componenti e con unica sorgente persistente del dato, ad una a microservizi, crea la necessità di dover gestire efficacemente la comunicazione tra i diversi servizi. Ciascuno dei microservizi deve garantire:
- 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).
Antonello Fodde
Antonello Fodde è il Tech Lead di Cherry Bit. Master in Computer Science al Politecnico di Milano e autentico nerd, con la sua esperienza e passione per il mondo startup è diventato un Maestro della tecnologia a tutto tondo, da quella mobile a quelle web. E’ un tipo curioso e preciso (forse troppo), con un occhio puntato sempre verso le ultime tecnologie.
Vedi articoli autore 
