Approfondimenti

Un caso reale di adozione di architetture a microservizi

Microservizi: perché sono un vantaggio.
L’architettura a microservizi vive, in questi giorni, il suo momento di gloria e sembra essere la soluzione a tutti i problemi che si incontrano, prima o poi, nello sviluppo di applicazioni. Ovviamente non è così, molto dipende dal contesto in cui ci troviamo ad operare.

microservizi

 

Indubbiamente questa architettura pone le basi per la gestione agile dell’evoluzione di una applicazione, riducendo notevolmente il time-to-market. Tale scelta però non è gratuita e, anzi, richiede un costo di impostazione più alto rispetto ad altre soluzioni.

Prima di scegliere l’architettura a microservizi è importante studiare il dominio in cui si opera, le necessità che le funzionalità applicative richiedono e valutare con attenzione se questi requisiti sono affini con le caratteristiche delle architetture a microservizi.

Dall'analisi fatta da Consoft Sistemi per un sistema di gestione di trial clinici - specificatamente per il progetto “CANP – La Casa Nel Parco” finanziato sulla Piattaforma Salute e Benessere POR FESR 2014/2020 dalla Regione Piemonte - è emerso che la scelta di un’architettura a microservizi sarebbe stata la soluzione più idonea da adottare.

Vediamo nel dettaglio il motivo di tale conclusione introducendo il dominio funzionale, quello dei trial clinici.

 

Il progetto “CANP - La Casa Nel Parco”

Il progetto “La Casa nel Parco” ( http://casanelparco-project.it/) propone soluzioni per l’e-health come applicazione di tecnologie ICT nella gestione dei processi sanitari, nella telemedicina e telemonitoraggio, allo scopo di supportare l’accessibilità e interoperabilità delle informazioni e dei servizi sanitari, il decentramento della cura, la razionalizzazione delle risorse ed il miglioramento dei percorsi assistenziali in un’ottica di Smart Hospital.

Tra gli obiettivi del progetto “La Casa nel Parco” troviamo:

  • Miglioramento della qualità della vita del paziente nel rispetto della sua autonomia e nella promozione della sua indipendenza nelle fasi post-acuzie, oltre che della sua riabilitazione attuata con un ricovero a casa.
  • Ottimizzazione dei Processi di assistenza
  • Sostenibilità dei costi dei servizi sanitari
  • L’accettabilità da parte di operatori e pazienti di soluzioni e-health
  • Il sistematico controllo clinico del paziente
  • L’applicabilità di soluzioni ICT a supporto dell’efficacia clinica

I Trial Clinici

Un trial clinico è l’esecuzione di un processo il cui scopo è quello di verificare la validità di una certa tesi. Le modalità di esecuzione del trial sono descritte in un documento detto protocollo clinico che spiega, in buona sostanza:

  • Lo scopo del trial: quale tesi si intende dimostrare, come a titolo esemplificativo la validità di un farmaco nella cura di un certo disturbo
  • Quali sono le regole per la scelta dei partecipanti (fase di arruolamento)
  • Quali sono le formule che vengono utilizzate per determinare l’appartenenza ad un gruppo rispetto ad un altro (fase di randomizzazione), per es. nel caso di un trial per un farmaco, la randomizzazione è quella operazione che determina (in modo casuale o secondo una logica dettata dal protocollo clinico) se un partecipante farà parte del gruppo che riceve il farmaco sotto validazione oppure del gruppo che riceve il placebo
  • Quali sono le visite da svolgere e quali dati devono essere raccolti durante le visite e durante tutta la durata del trial
  • Qual è il criterio di validazione del trial: quali sono le evidenze che devono emergere per riuscire a dare una risposta al quesito del trial

Problematiche

Definito l’ambito “funzionale” vediamo quali problematiche la soluzione architetturale risolve:

  • Affidabilità: il sistema deve avere momenti di disservizio nulli, anche durante i rilasci di nuove versioni il sistema deve essere sempre disponibile
  • Scalabilità: i trial possono avere un’alta variabilità in termini di dimensioni, potrebbero dover vedere coinvolti un solo centro clinico o diversi centri sparsi in tutto il globo
  • Versatilità: deve essere possibile adattare la piattaforma per ricevere dati dalle più disparati fonti. Basti pensare a dispositivi indossabili che inviano quotidianamente dati e che sono una informazione preziosa per valutare il trial, oppure dispositivi elettromedicali che possono mandare al sistema le misurazioni effettuate

Piattaforma

Il sistema sviluppato è una piattaforma integrata per la gestione di informazioni ed i dati provenienti da sensori, sistemi ospedalieri personale sanitario. Per gestire al meglio le potenzialità di una architettura a microservizi, come piattaforma PaaS, è stata scelta Kubernetes, su HPC4AI ( https://hpc4ai.it/) progetto dell’Università di Torino - Dipartimento di Informatica partner CANP e Politecnico di Torino finanziato da Regione Piemonte sul bando INFRA-P POR-FESR 2014-2020.

Kubernetes ci permette di rendere più agevole l’implementazione del CI/CD (Continuous Integration e Continuous Delivery).

Di seguito il diagramma di rilascio automatizzato che è stato configurato:

 

immag 1

 

 

Affidabilità

Come dicevamo, il sistema deve avere un’alta affidabilità. Ma cosa si intende per alta affidabilità? Un applicativo nonostante il code review, gli innumerevoli unit test, test di integrazione, test funzionali e stress test non è detto sia immune da bug, magari anche gravi che possono portarne al crash. Un’alta affidabilità si ha quando in presenza di situazioni anomale in una certa area del sistema (per es. bug) non si hanno impatti, o sono minimi, sulle altre aree. L’architettura a micro-servizi scompone in tante componenti autonome, ognuna responsabile di una certa specifica funzionalità, ciò che una sarebbe stata un’applicazione monolitica. L’architettura proposta dovrà puntare a raggiungere livelli minimi, se non nulli, di dipendenza tra micro-servizi (coupling); per ridurre l’area di impatto di un possibile malfunzionamento.

Nella progettazione del sistema sono state individuate le aree funzionali e per ognuna di esse è stato definito un micro-servizio:

  • Compilazione questionari
  • Compilazione referti
  • Gestione dispositivo di tracciamento dell’attività (Adamo)
  • Compilazione questionari direttamente dai partecipanti
  • Arruolamento dei partecipanti
  • Analisi dati
  • Gestione dati: i dati prodotti dalle fonti esterne e dai micro-servizi sopra descritti vengono registrati su un db nosql attraverso l’invio degli stessi su Kafka

L’utilizzo di Kafka come veicolo per la comunicazione tra micro-servizi permette di aumentare il disaccoppiamento tra gli stessi, grazie ad una comunicazione asincrona ad eventi.

Kubernetes, d’altro canto, ci consente di monitorare costantemente il sistema e gestire i crash dei componenti e il loro riavvio in automatico.

 

Scalabilità

La progettazione a microservizi permette una più precisa gestione delle risorse e quindi una migliore scalabilità. Ci sono microservizi dove le richieste di potenza di calcolo sono più alte rispetto ad altre o viceversa. Per esempio, la funzionalità di analisi richiede maggiore potenza di calcolo; ed è attraverso Kubernetes che diventa possibile collocare questo microservizio su un nodo ad alta potenza di calcolo (attraverso il node affinity del microservizio).

Ogni microservizio ha i probe, strumenti di monitoraggio, che sono in grado di gestire automaticamente l’upscaling, in caso di sovraccarico, delle istanze (pod).

 

Versatilità

Ogni microservizio dell’infrastruttura è autonomo e può gestire un proprio ciclo di vita, in modo totalmente indipendente dagli altri. Questo permette di inserire nuovi microservizi, come, ad esempio, un microservizio che gestisca una nuova fonte dati, con impatti minimi sul resto del sistema.

La piattaforma è rappresentata dallo schema di seguito:

 

immag 2

 

 

Conclusioni

La scelta di una architettura a microservizi per il sistema ha portato sicuramente ad un vantaggio in termini di scalabilità, sicurezza e affidabilità.

L’altro aspetto, non meno importante, è l’indipendenza delle aree funzionali. Questa peculiarità ha permesso di:

  • Essere autonomi sulle singole aree funzionali: il team Consoft Sistemi, che ha in carico l’evoluzione della componente, ha il controllo completo del suo funzionamento, e operare in autonomia le operazioni di refactoring o di re-ingegnerizzazione
  • Aggiungere nuove aree funzionali: l’aggiunta di nuove aree funzionali può essere svolta in modo meno impattante rispetto a tutto il sistema, sempre mantenendo l’indipendenza del microservizio in aggiunta
  • Sperimentare nuovi framework di sviluppo: Consoft Sistemi ha potuto sperimentare nuovi framework di sviluppo più promettenti, infatti grazie all’indipendenza dei microservizi, non ci si è mai trovati legati ad una scelta specifica di linguaggio, librerie o altre componenti tecnologiche.

Ovviamente la scelta di una architettura a microservizi va ponderata con attenzione perché se applicata non correttamente può portare più a svantaggi che vantaggi. Occorre porre particolare attenzione a:

  • DevOps: se non c’è l’automatismo nel build - deploy il vantaggio del time-to-market si perde in quanto le frequenti operazioni di rilascio diventerebbero troppo gravose. Questo significa pensare a strumenti di CI/CD quali Jenkins
  • Log: i microservizi cooperano, tra loro e una transazione può passare attraverso diversi microservizi, diventa quindi importante studiare un sistema di log centralizzato in modo da semplificare le operazioni di analisi, per es. in situazioni di malfunzionamento
  • Rilascio: è necessario adottare degli strumenti di versionamento dell’applicazione. Ogni microservizio è indentificato da una versione, l’insieme delle versioni di tutti i microservizi determinano la versione dell’applicazione. Adottare uno strumento quale Helm permette di gestire la storia dei rilasci ed eventualmente procedere nel rollback in caso di malfunzionamento.

 

Consoft Sistemi ha investito molte risorse nello studio dell’architettura qui descritta raggiungendo gli obiettivi che si era prefissata.
Non solo il rispetto dei tempi di consegna e dei costi preventivati, mantenendo un’alta qualità del prodotto, ma la possibilità di coinvolgere nuovi componenti nei team di sviluppo aumentando il numero di professionisti con conoscenze approfondite dei paradigmi del DevOps e di tecnologie d’avanguardia.

Tecnologie che ancora una volta pongono Consoft Sistemi come uno dei più avanzati partner di integrazione!

 

Francesco Mocci Francesco Mocci, Enterprise Architect
Appassionato ed esperto di tecnologie, mentor ed evangelist

imm1

imm2 

 

Image