Organizzare le proprie applicazioni adottando una architettura modulare a microservizi ha diversi vantaggi e pone qualche problema a cui gli sviluppatori tradizionali non sono abituati.
Il trend verso l’adozione dei microservice peraltro è ormai evidente e la gran parte delle aziende sta quantomeno considerando di adottarli in qualche misura.
Gli analisti avvisano che prima di approcciare questo mondo bisogna avere chiaro di che si tratta e sviluppare una minima competenza nella gestione dei suoi elementi principali, in particolare alcune tecnologie che inevitabilmente ruotano attorno ai microservizi. Vediamone alcune.
L’infrastruttura: cloud e container
Il legame tra microservizi, ambienti cloud e virtualizzazione a container è stretto e anche abbastanza ovvio. Un’architettura a microservizi si può creare anche senza cloud – c’è chi in fondo considera i microservice banalmente come l’evoluzione delle Service-Oriented Architecture, e di cloud non si parlava nell’epoca d’oro delle SOA – ma nella gran parte dei casi i microservizi sono la base delle applicazioni cloud-native.
D’altro canto tutti i cloud provider offrono la possibilità di realizzare microservizi sui propri cloud e, più in generale, qualsiasi ambiente basato su OpenStack li supporta. Da notare poi che i cloud provider stanno facendo evolvere la loro offerta in campo serverless computing, una concezione dello sviluppo che si integra bene con il modello dei microservice.
Più tradizionalmente i microservizi si realizzano preferibilmente come elementi “containerizzati”, anche perché tra container e micoservice ci sono molte similitudini concettuali.
Il problema della gestione
Quando vi trovate con una architettura di decine di microservizi che insieme devono realizzare il flusso logico che avete previsto, la cosa principale che volete sapere è quale microservice sta facendo cosa in un dato momento e se l’insieme dei servizi si sta effettivamente comportando come gli sviluppatori vogliono. Il che significa due cose: orchestration e monitoraggio delle applicazioni.
L’orchestration dei microservizi e quindi dei container che li abilitano è un elemento importante in una architettura applicativa destrutturata. Senza funzioni di orchestrazione diventa molto difficile capire cosa eventualmente non va, di specifico, se il (macro)servizio non sta funzionando. I tool per farlo, collegati alla containerizzazione, ci sono: ad esempio Kubernetes, Mesos e Docker Swarm.
La situazione cambia se ci portiamo a un livello di astrazione superiore e cerchiamo di valutare le performance di un’applicazione “scomposta” in microservizi. Qui le soluzioni tradizionali di Application Performance Monitoring non ci aiutano perché sono state pensate per applicazioni monolitiche e non sempre riescono ad adattarsi alle architetture a microservice. I vendor del mondo APM stanno ovviamente lavorando al potenziamento dei loro tool in ottica microservice, lo scenario è quantomeno fluido.
Dal punto di vista degli sviluppatori
Per chi sviluppa l’approccio a microservizi si basa su due elementi che fortunatamente sono ben noti: le API e Rest. Ogni microservice idealmente ha la sua API tramite cui interagisce con altri servizi e che può essere presentata all’esterno per far usare il servizio da qualsiasi applicazione. Questo permette una grande elasticità di sviluppo perché permette di collegare una propria applicazione con qualsiasi microservice, l’unico problema è che quando le API gestite o presentate all’esterno crescono di numero si rende quasi obbligatoria una soluzione di API management.
Rest (o Representational State Transfer) è una vecchia conoscenza degli sviluppatori web ed è il sistema più comunemente adottato per la comunicazione tra microservizi, una scelta logica anche perché la maggior parte delle attuali applicazioni a microservice sono applicazioni web. In questo approccio i microservizi dialogano semplicemente via Http e si scambiano informazioni in formati standard come XML, Html o sempre più spesso Json.
Fin qui tutto bene. Ciò con cui alcuni sviluppatori possono avere meno confidenza è che per sfruttare appieno l’elasticità offerta dai microservizi è assai opportuno adottare modelli di sviluppo di tipo DevOps. Questo significa avere assimilato anche i concetti di Continuous Integration (CI) e Continuous Delivery (CD) e aver adottato tool specifici che automatizzino la gestione e il rilascio del codice. Per chi deve prendere la mano con lo sviluppo “agile” le piattaforme più diffuse sono Jenkins, Hudson e Chef.
