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.
  Bisogna a questo punto fare chiarezza rispetto a due tipologie di servizi:  
  • 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).
  La piattaforma Cherry Bit ingloba una moltitudine di microservizi e nanoservizi che comunicano tra loro. Questi servizi hanno spesso un ruolo preciso, e molti di essi si occupano di recuperare informazioni digitalizzate disponibili online.  Ad Esempio: partendo da un codice fiscale, si collegano al catasto e estraggono tutta la consistenza catastale del soggetto, trasformando e rappresentando il dato secondo un modello proprietario. Già un flusso come il precedente, per quanto banale, sulla piattaforma viene implementato tramite l’orchestrazione di più di 5 servizi, sfruttando una pipeline che porti dal codice fiscale al modello di consistenza catastale. Ogni passo della pipeline utilizza un preciso servizio che, a partire da un input ricevuto tramite API, esegue una funzione e produce un risultato per il prossimo passo della pipeline tramite API. Molto spesso questa pipeline può essere molto complessa e comprendere più passi. In più potrebbe contenere in più punti delle operazioni che non possono essere completate in breve tempo. Questo porta a delle pipeline che nascono da una chiamata API e generano un risultato in alcuni (pochi) minuti.
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).

Ti potrebbero interessare

- 28/06/2022
Siamo entrati in una nuova fase storica in cui, oltre a quella umana, non si può non considerare l’Intelligenza Artificiale, che di fatto sta cambiando la società e la vita dell’uomo. Per questo, ogni giorno in cherry la studiamo, per portare valore e innovazione nel mondo del credito.
- 10/05/2022
Dove c’è innovazione non può che esserci anche cherry. E va da sé, quindi, che non potevamo mancare a un evento dal titolo “Mercoledì dell’Innovazione”.
- 25/04/2022
Come ci rendiamo conto ogni giorno in cherry, l’AI sta rivoluzionando la maggior parte dei settori produttivi. Ma quali sono le principali tecnologie che la compongo?