<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1214412942025937&amp;ev=PageView&amp;noscript=1">

Red Blog

Tutto ciò che devi sapere sui microservizi (microservices)

Luigi De Masi,

I microservizi (microservices)

Sono piccoli, ma fanno grandi cose. I microservizi sono un incredibile alleato di sviluppatori e aziende, dato che permettono di creare applicazioni di qualità in tempi molto più rapidi rispetto a quanto non fosse possibile fino a ieri. E non solo i tempi si accorciano, ma è anche più facile prendersi cura del software con aggiornamenti continui e liberandosi dalla paura che tutto il sistema smetta di funzionare se magari anche un solo ingranaggio si blocca.

Ma che cosa sono davvero i microservizi, perché sono diversi dagli altri approcci, e come avvicinarsi a loro senza controindicazioni?

 

Scopri come innovare il rilascio delle applicazioni con i container!

 

In sostanza, i microservizi sono i componenti "core" di un'applicazione progettata secondo un approccio architetturale modulare, opposto a quello tradizionale e monolitico. Ragionando con questa filosofia, i singoli componenti pur essendo parte di un'unica piattaforma conservano una maggiore indipendenza, che si traduce in vantaggi sia per chi sviluppa sia per l'azienda che eroga il servizio.

Facciamo un esempio: gli elementi di un sito Web di eCommerce (il motore di ricerca interno, il motore di raccomandazioni, il "carrello" in cui si accumulano gli articoli selezionati, il chatbot per l'assistenza clienti, e via dicendo) sono tutti microservizi.

Il rovesciamento del passato

Il rovesciamento del passato

L'approccio cosiddetto "monolitico", l'unico possibile agli albori dello sviluppo software, prevede che il codice sorgente dell'intera applicazione sia realizzato in un solo blocco di software (un'unità di deployment, per esempio .war o .ear). Con questo metodo, nel caso si debbano apportare modifiche anche minime, si è obbligati a eseguire un aggiornamento completo del software, ed è facile capire come ciò per gli sviluppatori si traduca in lungaggini e lavoro extra. Per le aziende, invece, può significare tempo perso. Tale metodo può avere ancora una validità se si creano piccole applicazioni, ma è inadeguato per quelle complesse e per chi non può permettersi un downtime.

I microservizi, all'opposto, sono figli di un approccio architetturale che permette di sviluppare e mettere all'opera singole funzioni "core" di un'applicazione, le quali agiscono indipendentemente l'una dall'altra. Torniamo all'esempio del sito eCommerce: può darsi che, per svariate ragioni, in un dato momento non si riescano a eseguire ricerche o il meccanismo di pagamento si inceppi, ma questo non implica che l'intero sito vada offline. Il danno, insomma, è circoscritto.

La base dei microservizi

La base dei microservizi

Se tutto questo ti sembra già sentito è perché la logica modulare non è completamente nuova. Il fatto di scomporre un'applicazione nelle sue funzioni di base, evitando le insidie dei "monoblocchi", accomuna i microservices all'architettura orientata ai servizi (service-oriented architecture o architettura SOA), un metodo già noto e affermato. Con esso le applicazioni vengono strutturate in servizi definiti e riutilizzabili, comunicanti fra loro attraverso un'infrastruttura software di tipo enterprise service bus (ESB). Ciascun servizio riguarda uno specifico procedimento e impiega un protocollo di comunicazione (per esempio SOAP, ActiveMQ o Apache Thrift) per distribuirsi tramite l'ESB. Considerati nell'insieme e integrati attraverso l'ESB questi servizi compongono l'applicazione.

Questo approccio consente di creare, testare e modificare i servizi simultaneamente, anziché con cicli di sviluppo monolitici, ma d'altra parte ha uno svantaggio: l'enterprise service bus rappresenta un Single Point of Failure, un punto di vulnerabilità per l'intero sistema. Si evita il "monoblocco" ma si crea un nuovo potenziale collo di bottiglia.

L'indipendenza conquistata con i container

L'indipendenza conquistata con i container

I microservizi differiscono dall'architettura SOA per un elemento cruciale: possono comunicare uno con l'altro, solitamente in logica stateless, in modo che l'applicazione garantisca continuità operativa in caso di guasti (sia, cioè, fault-tolerant) e non dipenda da un unico ESB. Il metodo permette anche agli sviluppatori di scegliere quali strumenti usare, dal momento che i microservices comunicano attraverso interfacce di programmazione delle applicazioni (API) agnostiche rispetto ai linguaggi.

È vero, l'idea che sta alla base dei microservizi non è del tutto nuova, considerando l'affermazione delle architetture SOA. Ma oggi grazie all'evoluzione delle tecnologie di containerizzazione è diventato molto più facile adottarli. I container Linux permettono di eseguire diverse parti di un'applicazione in modo indipendente, sul medesimo hardware e con un controllo decisamente maggiore sui singoli frammenti e cicli di vita del software.

I benefici di un'architettura basata su microservizi

I benefici di un’architettura basata su microservizi

Un modello di sviluppo distribuito, come quello dei microservizi, può mettere il turbo agli sviluppatori e alle attività di routine. Permette, inoltre, di creare molteplici microservizi in contemporanea e questo significa mettere al lavoro un maggior numero di persone sulla stessa app, ottenendo migliori risultati in tempi più brevi. Vediamo, uno a uno, i principali vantaggi di questo approccio.

  • Time to Market. Si può arrivare prima sul mercato con un nuovo servizio perché i cicli di sviluppo si accorciano, mentre produzione e aggiornamenti diventano più agili.
  • Scalabilità. Al crescere delle richieste per determinati servizi, è possibile attivare risorse su più server e infrastrutture, a seconda delle necessità.
  • Resilienza. Se ben realizzati, i servizi sono indipendenti e non influiscono l'uno sull'altro. Se un elemento smette di funzionare, quindi, non si crea un effetto domino, come invece accade per le applicazioni monolitiche.
  • Deployment semplificato. Le applicazioni modulari e leggere sono più facili da distribuire rispetto a quelle monolitiche. Richiedono, sì, un maggior lavoro di coordinamento, ma in cambio si ottengono vantaggi enormi.
  • Accessibilità. Scomponendo un'app complessa in parti più piccole per gli sviluppatori è più facile comprendere, aggiornare e migliorare i singoli elementi, dunque i cicli di deployment si velocizzano. Ancor di più se si impiegano metodologie di sviluppo Agile.
  • Maggiore apertura. Ricorrendo ad API "poliglotte", gli sviluppatori sono liberi di scegliere il linguaggio e la tecnologia migliori per la funzione da realizzare.

Le sfide che accompagnano i microservizi

Le sfide che accompagnano i microservizi

Se stai pensando di transitare verso una microservices architecture, preparati a un cambiamento che dovrà coinvolgere le persone con cui collabori, non soltanto le applicazioni. Un'evoluzione organizzativa e culturale rappresenta una sfida perché ciascun team lavorerà secondo i propri ritmi e sarà responsabile di un servizio unico, rivolto a determinati utenti. Potrebbero, queste, non essere le tipiche preoccupazioni di uno sviluppatore, ma si tratta di elementi essenziali per il successo di un'architettura a microservizi. Oltre alla cultura e ai processi, le altre due grandi sfide riguardano la complessità e l'efficienza.

Nel suo intervento al Red Hat Summit 2017 John Frizelle, platform architect di Red Hat Mobile, ha elencato otto tipi di sfide da affrontare.

  • La creazione delle applicazioni. Devi dedicare del tempo a identificare i legami di dipendenza tra i servizi. Sappi che realizzare una build potrebbe innescare la nascita di numerose altre versioni, proprio per via di tali dipendenze.
  • Il testing. Il testing di integrazione, così come quello end-to-end, potrebbe rivelarsi più difficile e più importante che mai. Un malfunzionamento in una parte dell'architettura potrebbe avere riflessi qualche passaggio più avanti, a seconda di come i servizi sono stati strutturati per supportarsi a vicenda.
  • Il versioning. Nel passaggio a versioni più aggiornate, ricordati che potresti intaccare la retrocompatibilità. Per risolvere il problema si può far ricorso alle istruzioni condizionali, ma in breve tempo potrebbero diventare di difficile gestione. In alternativa, potresti mettere in piedi diverse versioni live per altrettanti clienti, sapendo però che la manutenzione e la gestione si complicheranno.
  • La distribuzione. Ebbene sì, anche questa è una sfida, almeno in una prima fase di setup. Per semplificare il deployment dovrai preventivamente investire nell'automazione, perché gestire tutto manualmente sarebbe insostenibile. Rifletti su come saranno lanciati i servizi e in quale ordine.
  • Il logging. Con i sistemi distribuiti è necessario centralizzare i log, così da raccogliere tutto in un unico luogo. È l'unico modo per gestire sistemi tanto estesi senza essere sopraffatti.
  • Il monitoraggio. È cruciale disporre di una visione centralizzata del sistema, da cui poter individuare con precisione le cause dei problemi.
  • Il debugging. La "bonifica" da remoto non è nemmeno da considerare, non potendo funzionare su decine o centinaia di servizi. Sfortunatamente non esiste una semplice risposta al problema.
  • La connettività. Prendi in considerazione il service discovery, centralizzato oppure integrato.

Ti è venuta voglia di trasformare applicazioni o crearne di nuove, sapendo che potrebbe non essere un gioco da ragazzi ma che sarai ampiamente ripagato? La sfida più grande, ancor più di quelle che ti ho elencato, è forse quella di fare il primo passo: lasciati guidare, allora, dal nostro eBook gratuito "Modernizzare il rilascio delle applicazioni con i container" e lanciati nel futuro dello sviluppo delle applicazioni! Ti basta un clic:

Extra Red | Modernizzare il rilascio delle applicazioni con i container

Condividi l'articolo!

   

Commenti

Prova Red Cloud Gratis per 30 Giorni

Iscriviti alla newsletter

Condividi questo blog

   

Post correlati