Croce Rossa Italiana
GAIA: una nuova architettura a microservizi per Croce Rossa Italiana
release: 2023 and to be continued
Tipologia: Associazione di volontariato
Il cliente
Croce Rossa Italiana è una delle poche organizzazioni di volontariato al mondo, se non l’unica, che non ha bisogno di presentazioni. Il suo scopo è l’assistenza sanitaria e sociale in tempo di pace e in tempo di conflitto e ha un’articolazione complessa distribuita sul territorio con una precisa identificazione dei ruoli e della struttura organizzativa.
Da diversi anni siamo lieti di collaborare con il reparto IT con particolare riferimento allo strumento informatico sul quale CRI basa molte delle sue attività, che possono andare dagli interventi sul territorio, i dialoghi tra le realtà, le pratiche autorizzative, la formazione, i titoli e la lista potrebbe continuare per ore. Questo sistema informativo, che si prefigge di essere di facile utilizzo, completo e affidabile, prende il nome di GAIA.
Le sfide
Anni fa, quando c’è stato il primo contatto e sono iniziate le prime collaborazioni, il nostro ruolo era di supporto nella manutenzione ordinaria ed evolutiva di questa piattaforma realizzata in origine dai Servizi Informatici del Comitato Provinciale di Catania e poi affidata a diversi fornitori.
Negli anni le esigenze sono cresciute, il volume dell’utenza è aumentato e ci si è cominciati a chiedere se questa crescita funzionale e prestazionale fosse sostenibile con un’architettura monolitica basata sul framework Django con le pagine generate dal framework stesso.
In particolare sono emerse esigenze di integrazioni con sistemi terzi, rivisitazione completa della UI/UX, la fruibilità dei contenuti tramite applicazione mobile, la gestione di picchi di traffico e messaggi scambiati tra gli utenti e altre sfide tecnologiche che ci hanno portato a rivalutare l’architettura.
Cosa abbiamo fatto
La risposta alle sollecitazioni ricevute è stata la proposta di un replatforming completo della soluzione, passando da un’architettura monolitica a una a microservizi dove ogni componente eccellesse nel proprio dominio e potesse fallire senza inibire il funzionamento delle altre parti. Abbiamo cominciato a scomporre i problemi cercando di volta in volta di guidare il cliente nella scelta make or buy che inevitabilmente si è costretti a fare in queste circostanze.
Il nostro, piano in estrema sintesi, era semplice: riscrivere l’interfaccia grafica basata su componenti che si popolassero con dati provenienti da un layer di mashup di dati a loro volta provenienti da uno strato ancora inferiore di business logic (microservizi) in grado di recuperare ed elaborare dati presenti nello strato piu’ basso ossia quello della persistenza (database, search engine).
1. riscriviamo la UI con tecnologie moderne e una UX coinvolgente, 👉 mockup + React js
2. separiamo di netto la presentazione delle informazioni da chi le possiede o le cucina 👉 Backend For Frontend (BFF), NodeJS
3. non possiamo migrare un tool così vasto in un colpo solo: dotiamo il monolite legacy di API in modo che fornisca i dati al BFF 👉 Django Rest Framework
4. scorporiamo le funzionalità una alla volta dal monolite legacy in microservizi dedicati e istruiamo il BFF a cambiare fornitore di dati in maniera trasparente per la UI/UX 👉 Java Quarkus, Python Flask, NodeJS
5. dobbiamo gestire n-mila pratiche diverse, ci serve uno strumento per il Business Process Management su cui fondare i processi 👉 Odoo
6. ci serve uno strumento per gestire in contenuti su App e su UI, ci serve un Content Management System 👉 Plone
7. serve compensare il volume crescente di traffico:
- usiamo Elastic Search per la lettura delle informazioni e le ricerche senza disturbare il database
- rilasciamo i nuovi sviluppi su Kubernetes sfruttando le potenzialità di scalabilità
- sfruttiamo pattern event driven con gestione delle code invece di azioni bloccanti 👉 celery, kafka
Condiamo l’insalata tecnologica appena descritta con un bel po’ di automazione e CI/CD grazie a Gitlab e teniamo sotto controllo il tutto dando sfogo al nostro voyeurismo informativo con la collezione di log e metriche di tutto l’ecosistema con lo stack ELK e Prometheus.
Una delle sfide più avvincenti che ci siamo trovati ad affrontare è stata la mancanza di voglia e tempo per scrivere le decine e decine di form per la composizione delle pratiche e movimentazione dei processi informativo-documentali!
Le nostre preghiere da sviluppatori (e quindi intrinsecamente pigri) sono state ascoltate per fortuna e abbiamo formalizzato un pattern in sè per sè elementare:
- censiamo le tipologie di pratiche
- descriviamo un’anagrafica di campi e regole tramite interfaccia grafica di Odoo nel suo modulo Survey
- adottiamo uno standard per la descrizione di questi moduli web: Json Forms
- insegniamo alla nostra UI ad interpretare questo standard (ma siamo pigri quindi non da zero 👉 https://rjsf-team.github.io/react-jsonschema-form/docs/ )
Con questo pattern otteniamo velocità di sviluppo e semplicità nei cambiamenti in quanto tutto dinamico e governato dal modulo Survey di Odoo.
Ci è piaciuto cosi’ tanto questo approccio che lo abbiamo già sperimentato in altre realtà e altri clienti sostituendo completamente il frontend, per esempio andando su mobile con applicazioni scritte in Flutter che dialogano - usando il dialetto comune Json Forms - con Odoo che tramite punta-clicca-trascina governa in toto i moduli delle app iOS/Android.
Per fortuna Croce Rossa Italiana e il progetto GAIA ci riservano sempre tante sfide e non vediamo l’ora di affrontare la prossima facendo del nostro meglio per raggiungere il massimo risultato con il minimo sforzo… ovviamente!
