Quale software scegliere per i crediti deteriorati?

Dic 9, 2020

Quando ho iniziato la mia avventura in Cherry ormai oltre un anno fa, non capivo ancora bene il mondo del credito finanziario e ancor meno quello dei crediti deteriorati.

Una cosa però ho compreso da subito, il mio ruolo all’interno del Team di Cherry e cosa dovesse essere fatto per la creazione dell’ ambizioso prodotto Cherry Bit, motivo per cui mi sono unito al gruppo Cherry.

Per costruire qualcosa di nuovo in un mondo visto da molti ancora “vecchio” e retrogrado come quello bancario in Italia, bisognava ricominciare da zero, dalle fondamenta e per noi, persone “giovani” abituate alla tecnologia, significava tirare su un’architettura solida che fosse capace di sostenere carichi di lavoro variegati ma, allo stesso tempo, intrinsecamente dinamica, data la vasta gamma di sorgenti dati, di sistemi legacy e di fornitori con cui Cherry Bit come prodotto si sarebbe andato ad integrare.

La scelta di una tecnologia rispetto ad un’altra non deve, a nostro parere, seguire obbligatoriamente il trend tecnologico del momento, ma partire piuttosto da una reale necessità. Per capire meglio le necessità che abbiamo è bene comprendere il nostro specifico scenario di applicazione.

Cherry Bit è una piattaforma di raccolta e analisi dei dati: per raccolta dati intendiamo la ricerca e raccolta massiva di informazioni su una moltitudine di piattaforme online e sistemi eterogenei, che forniscono informazioni sia pubbliche che profilate andando così ad arricchire notevolmente il patrimonio informativo di un portafoglio di crediti deteriorati; l’analisi consiste invece nella riconciliazione dei dati risolvendo eventuali incongruenze ed inesattezze attraverso i nostri algoritmi di AI, che analizzano i nuovi dati raccolti assieme allo storico che già abbiamo. Ad esempio, nel primo anno di vita di Cherry abbiamo raccolto i dati sui tribunali fallimentari italiani dal 2010 al 2019 e i nostri algoritmi ci hanno permesso di estrarre una panoramica il più oggettiva possibile sulle performance di ciascun tribunale. Potete leggere l’articolo qui: https://bit.ly/CherrySeaBlog .

A partire dal solo codice fiscale o partita Iva, Cherry Bit recupera un set di informazioni precise e verificate, unificate in un data model congruo di nostra proprietà, e lo fa in maniera automatica ed estremamente veloce, così da arricchire in pochi secondi un portfolio con informativi completi ed ordinati.

 

Pertanto Cherry Bit doveva nascere con due caratteristiche principali: la velocità ed il massimo automatismo. La velocità è fondamentale quando ci arrivano portafogli con decine di migliaia di posizioni (debitorie) da analizzare: in questo caso vale proprio il detto il tempo è denaro, per noi vale il tempo è valore.Ci serviva l’automatismo perché ci siamo resi conto che molti processi bancari di analisi e raccolta dati erano ancora (inutilmente) operazioni manuali. Non vogliamo sottrarre lavoro a nessuna persona, ma far sì che quella persona crei valore col suo lavoro riducendo al minimo le operazioni che prima doveva eseguiva a mano. Questo credo sia uno dei maggiori valori aggiunti di Cherry Bit.

 

Ma come abbiamo realizzato tutto ciò?

Intro, ovvero agli albori

Il primo approccio affrontato dai miei colleghi ancora prima del mio arrivo è stato quello di usare Google Flex di GCP che permette di avviare in maniera dinamica multiple istanze di un applicativo, occupandosi sia dell’ autoscaling che della gestione dello stato dell’applicativo.

Lo scopo principale di Google Flex Environment è descritto così:

the App Engine flexible environment automatically scales your app up and down while also balancing the load

Affermazione molto ambiziosa da parte di Google, e sicuramente in parte lo scopo è raggiunto da questo prodotto: il costo del servizio dipende però dal numero di istanze e dal tempo di esecuzione, per cui lasciando la logica di gestione delle repliche applicative e del carico di lavoro a Google si sarebbe rischiato di incorrere in costi elevati per workload relativamente bassi. Inoltre, con questa piattaforma abbiamo riscontrato alcuni problemi/limitazioni:

  • L’autoscaling era gestito assieme al file di deploy, per cui i parametri di configurazione erano vincolati al deploy.
  • Si aveva a nostra impressione poco controllo sulla logica di autoscaling, per cui a volte ci trovavamo ad avere decine di istanze senza alcun vero motivo, altre volte non venivano invece create le repliche necessarie per il carico di lavoro o si avevano lunghe attese dovute alla creazione di nuove istanze VMs per fornire maggiori risorse.
  • Il prodotto si integrava abbastanza bene con Google Build, che era però in Beta release con funzionalità limitate se comparate ad altri tool di Build Automation.

I problemi principali riscontrati alla fine erano due, la logica di autoscaling quasi completamente fuori dal nostro controllo e la poca reattività nel flusso di Deployment di nuove release applicative. 

Una delle cose più frustranti per uno sviluppatore e devops è non avere abbastanza controllo sui sistemi con cui lavora quotidianamente.

Abbiamo quindi deciso di esplorare altre soluzioni per la nostra piattaforma.

Quale tecnologia?

Non è pensabile sviluppare una soluzione applicativa single code-base che possa svolgere le funzionalità richieste da un sistema come Cherry, in quanto esso necessita di un numero elevato di esecuzioni concorrenziali su più sistemi e piattaforme esterne. La soluzione di un’unica applicazione monolita è comunque possibile, ma quanto sarebbe mantenibile tale soluzione? Quale livello di scalabilità si potrebbe raggiungere mantenendo però un costo contenuto?

Una prima decisione è stata quindi di scegliere un pattern di architettura orientata a microservizi in quanto il naturale comportamento di Cherry bit è quello di collegarsi a più sistemi e piattaforme, oltre a fornire diversi tipologie di servizio al cliente, dalla dashboard applicativa, alla raccolta storica dei dati, alla sua analisi per estrarre ulteriore valore. 

 

 

Quindi ogni sistema con cui ci siamo interfacciati è mediato da uno o più microservizi. Tra questi, ad esempio, possiamo trovare:

  • Servizio di interfacciamento con il catasto per le visure immobiliari.

  • Servizio di interfacciamento per estrarre e scaricare le note ipotecarie dal catasto.

  • Servizio di interfacciamento per rintracciare le aste.

  • Servizio per l’interpretazione dei documenti.

  • Servizio di interfacciamento con il portale Telematico della Giustizia Italiana.

  • Servizi di piattaforma, APIs, Gateways, Dashboarding, Logging etc…

 

Oltre ai servizi core, abbiamo l’esigenza di clusterizzare e quindi ulteriormente isolare le risorse per i nostri clienti, secondo i regolamenti di privacy e di sicurezza del dato.

Per motivi di GDPR, oltre a garantire il massimo livello di servizi per ciascuno dei nostri clienti, rilasciamo:

  • Un cluster MongoDB dedicato con repliche e gestione encryption key (anche con chiave del cliente).
  • Un set di microservizi comprensivi di Front-End ed API con risorse dedicate ed isolate.

I servizi sono già tanti e ne arriveranno molti altri con le prossime integrazioni di servizi dedicati alle posizioni NPL unsecured, e altri ancora.

La scelta di Kubernetes (K8s) e di GitLab

Dopo 4 mesi di uso di Google Flex, abbiamo optato per una soluzione su cui avremmo potuto avere maggior controllo e flessibilità dei costi. Abbiamo introdotto Kubernetes come orchestratore dei nostri applicativi e GitLab come Build Automation tool per le nostre pipelines di Build, Test, Deployment.

Questo non è un articolo in dettaglio su Kubernetes, tantomeno su GitLab e DevOps, bensì sui valori e vantaggi che queste tecnologie hanno apportato a noi di Cherry come sviluppatori e, di conseguenza, al mercato dei crediti deteriorati.

Perché Kubernetes? 

Perché è una piattaforma che reputiamo matura e ci permette di avere un buon livello di controllo sui costi e sulle risorse senza però inficiare sul funzionamento core del prodotto, cioè avere la “garanzia” che le istanze applicative funzionino come ci si aspetta.

Perché GitLab? 

In GitLab abbiamo trovato una piattaforma solida e ben rodata rispetto a Google Build (allora in Beta). Costruire pipelines e configurare i custom runners (agents di GitLab che si occupano di eseguire i nostri script di Build, Test e Deploy del nostro codice) è stato estremamente facile ed intuitivo. Sottolineo custom runners perché è stata una nostra scelta usare solo runners in esecuzione sui nostri ambienti per motivi di sicurezza, rispetto ai shared runners offerti da Gitlab. Inoltre usando custom runners siamo riusciti a ridurre di molto i tempi delle esecuzioni delle pipelines in quanto evitiamo ogni fase di inizializzazione dell’agent e la preparazione dell’ambiente necessario per l’esecuzione della Build.

Pros K8s

I costi sono fissi (quasi):  sono legati al numero di nodi (aka VMs del cluster).

Pieno controllo sulle repliche:  variare il numero di repliche è un’operazione di pochi secondi e l’autoscaling di Kubernetes è abbastanza affidabile e facile da gestire.

Facile esecuzione di apps: una volta configurato un cluster funzionante, si ha un ambiente ready to go per l’esecuzione di qualsiasi applicativo (containerizzato, si intende)

 

Cons K8s

Maggiore conoscenza: richiede un buon livello di conoscenza del prodotto e di patterns per evitare errori di configurazioni e seguire anti-patterns

Ruolo operativo aggiuntivo: è consigliato avere un team member dedicato per la gestione e configurazione delle risorse applicative sul cluster K8s.

 

Pros GitLab

IAM ben definiti: gestione di Teams e users per ruoli ben definiti con permessi segretati

Custom Runners: configurare custom runners è facile ed intuitivo e permette di ridurre se non azzerare i costi della piattaforma se si eseguono i runners sui propri ambienti. (e.g. K8s)

 

Cons GitLab

Triggers lenti (a volte): secondo la nostra personale esperienza, ai push di codice nuovo, non sempre viene avviata la build integration in tempi real-time o near real-time. I servizi dei workers di Gitlab potrebbero essere migliorati.

 

Terminologia di base per una maggiore comprensione: 

Orchestratore: una piattaforma capace di gestire in ‘autonomia’ il ciclo di vita di un applicativo software a partire da alcune configurazioni.

Build Automation tool: una piattaforma che permette di automatizzare l’esecuzione di script per la compilazione automatica di codice, l’esecuzione dei tests ed infine il rilascio dell’artefatto generato in ambienti di Sviluppo, Pre-Produzione e Produzione.

DevOps: un’insieme di best-practices e tools che permettono di gestire il ciclo di vita del codice di applicativi a partire dalla Repository (storage a freddo del codice) fino alla sua esecuzione (rilascio dell’applicazione) sui vari sistemi/ambienti.

 

State of the art

Ad oggi siamo soddisfatti della scelta fatta, abbiamo al momento un cluster con 8 nodi per l’ambiente di sviluppo e un cluster con 15 nodi per l’ambiente di produzione. I costi sono stabili e sotto controllo e riusciamo a sostenere i picchi di carico gestendo in maniera intelligente le configurazioni di autoscaling orizzontale fornito dal cluster. Uno dei maggiori vantaggi che abbiamo riscontrato con Kubernetes è la velocità di deploy e di creazione di repliche dei nostri applicativi. Riducendo il tempo speso per le attività di build&deploy, anche grazie al pieno controllo sulle pipelines di automation su GitLab, riusciamo a focalizzare meglio la nostra attenzione sul codice e sui processi che realmente creano valore.

 

Se vi interessa confrontarvi con noi sulla vostra e nostra esperienza con i prodotti descritti sopra, non esitate a scrivermi a chai.botta@cherrynpl.com

Sono sempre aperto a discussioni sulle tecnologie utili a migliorare la vita di uno sviluppatore/devops, sia condividendo esperienze professionali che studiando nuove best-practices in questo ambito, perché la tecnologia sia una vera risposta al Business.

 

Articoli correlati