Scouting offre servizi di finanza straordinaria alle PMI per attività relative ai mercati nazionali ed internazionali. Mette quindi a disposizione un team di professionisti, provenienti dal mondo finanziario e dalla consulenza direzionale con esperienza internazionale e fornisce servizi personalizzati alle banche di credito cooperativo ed ai loro clienti.
Il progetto Market Intelligence
Il progetto nasce dalle esigenze delle banche di credito cooperativo, clienti di Scouting, di avere uno strumento facile e veloce per conoscere di più sulle aziende clienti e/o su eventuali prospect. Grazie alla sessione di discovery abbiamo analizzato meglio il problema e siamo riusciti a definire una prima idea di prodotto.
Per Scouting era la prima esperienza di creazione di un software dedicato all’azienda. Abbiamo quindi deciso di fare prima di tutto un’attività di prototipazione – tramite sketch+invision – per confrontarci continuamente col cliente e gli stakeholder, delineando bene gli scenari di utilizzo.
Questo ci ha evitato di sprecare risorse in sviluppi privi di valore per l’utente. Per fare un esempio concreto, grazie ad un prototipo visuale, siamo riusciti a sviluppare senza rework il meccanismo di filtro (dentro l’app ci sono 17 tipi di filtri diversi) e raffinamento continuo delle ricerche.
Tre parole chiave: progettare, sviluppare ed integrare
La sfida più grande, durante lo sviluppo di questa piattaforma, è stata l’integrazione con un database di terze parti dal quale abbiamo importato e gestito i dati che l’applicazione elabora per fornire i suoi servizi.
Abbiamo sviluppato un set di RESTful API che fornissero un rapido accesso ai dati e ne garantissero una rapida manipolazione, e abbiamo scelto di mantenere separati i modelli: attraverso l’utilizzo di MySQL siamo stati in grado di gestire i dati delle oltre 600.000 aziende presenti sulla piattaforma, generando un read model che consentisse ad Elastic di eseguire ricerche e calcoli in tempo reale.
Abbiamo deciso di scrivere l’applicazione utilizzando uno stack custom basato su React + Redux + MaterialUI: l’uso di Redux ha reso possibile isolare la logica di business lasciando aperto il futuro dell’app a nuove evoluzioni, anche al di fuori dell’ambiente meramente desktop.
Infine, attraverso l’utilizzo di tool come Terraform e Ansible, abbiamo ridotto attività ricorrenti e velocizzato le modifiche all’infrastruttura.
Evoluzione dell’infrastruttura del progetto ScoutingMI: da architettura mononolitica a microservizi event-driven
Il portale Scouting Market Intelligence (ScoutingMI) è un tool di marketing che permette di individuare le società presenti sul proprio territorio e, nel caso delle società di capitali, di effettuare una prevalutazione in base ai dati di bilancio. Per quanto riguarda le società di persone, la ricerca si focalizza sulla definizione del territorio di interesse in due modalità: la prima attraverso l’inserimento di coordinate geografiche e raggio di ricerca, la seconda indicando un comune. Una volta decisa la modalità di ricerca vengono effettuate due chiamate ad un servizio esterno che restituisce i risultati della ricerca. In seguito, ottenuti i risultati, il backend esegue operazioni di parsing, geolocalizzazione e salvataggio su database.
Originariamente l’architettura era monolitica: tutti i processi erano strettamente collegati tra loro e venivano eseguiti come un unico servizio. Questo significa che se un processo dell’applicazione sperimenta un picco nella richiesta, è necessario ridimensionare l’intera architettura. Aggiungere o migliorare una funzionalità dell’applicazione monolitica diventava sempre più complesso, in quanto era necessario aumentare la code base. Tale complessità limitava ovviamente la sperimentazione e rendeva più difficile implementare nuove funzionalità.
Inoltre, le architetture monolitiche rappresentano un ulteriore rischio per la disponibilità dell’applicazione, poiché la presenza di numerosi processi dipendenti e strettamente collegati aumenta l’impatto di un errore in un singolo processo.
Il team cloud di Flowing in sinergia con quello dei developer ha risolto i problemi sopra descritti ed ha inoltre ottimizzato i tempi di risposta della chiamata applicando una strategia di refactoring. Partendo da una situazione in cui era presente solo un monolite applicativo si è arrivati ad avere un architettura a microservizi event-driven (fig. 1).
Lato sviluppo, il backend che costituiva il monolite è stato suddiviso in microservizi che svolgono attività atomiche ed indipendenti seguendo la filosofia Unix: “Do one thing and do it well”. (Doug McIlroy).
Con un’architettura basata su microservizi invece, un’applicazione è realizzata da componenti indipendenti che eseguono ciascun processo applicativo come un servizio.
I vantaggi includono una migliore scalabilità, una maggiore resilienza e un time-to-market più rapido. Ogni microservizio è indipendente, facilitando la scalabilità di un singolo servizio o funzione senza dover scalare l’intera applicazione. I microservizi consentono inoltre di scegliere i singoli componenti che si adattano alle esigenze del progetto, offrendo la flessibilità necessaria per rivedere il set senza riscrivere l’intero flusso di lavoro. In questo caso, i microservizi sono stati deployati su EKS e Lambda.
Per gestire l’intero flusso operativo dei vari servizi abbiamo utilizzato il servizio Step Functions, ideale per orchestrare i processi come quello del caso d’uso in esame, che presentano flussi di lavoro di breve durata e richiedono il completamento di una serie di passaggi prima di restituire una risposta. Nel caso di ScoutingMI, una call to action sul sito passa un json in input alla step function che avvia il flusso.
Ogni step raffigurato nella fig.2 è una operazione atomica, indipendente, che può essere chiamata selettivamente. All’interno della funzione sono presenti chiamate a funzioni lambda, chiamate a jobs su EKS, operazioni di manipolazione dell’output della risposta e catch di eventuali errori.
L’Architettura Event-Driven (EDA) è un altro pattern comunemente utilizzato per implementare i microservizi. In un sistema event driven, l’acquisizione, la comunicazione, l’elaborazione e la persistenza degli eventi costituiscono i pilastri portanti della soluzione. Questa è la principale differenza rispetto a un modello request driven. Un’architettura guidata dagli eventi può essere basata su un modello pub/sub o di flusso di eventi. Nel caso di ScoutingMI il modello è pub/sub cioè una infrastruttura di messaggistica basata su sottoscrizioni ad un flusso di eventi. Con questo modello, al verificarsi di un evento o in seguito alla sua pubblicazione, l’evento viene inviato ai sottoscrittori che devono essere informati.
Fonti:
AWS for Solution Architects – Alberto Artasanchez
Design Microservices Architecture with Patterns & Principles – Mehmet Özkaya
AWS Documentation
Redhat Website – Cos’è l’architettura guidata dagli eventi?
