Jump to section

Cosa sono i microservizi?

Copia URL

I microservizi sono un approccio architetturale alla realizzazione di applicazioni. In quanto framework architetturale, i microservizi sono distribuiti e a basso accoppiamento, in modo che le modifiche di un team non corrompano l'intera applicazione. Il vantaggio dell'utilizzo dei microservizi sta nel fatto che i team di sviluppo possono creare nuovi componenti delle applicazioni per adeguarsi a esigenze aziendali in continua evoluzione.

Quello che distingue l'architettura basata su microservizi dagli approcci monolitici tradizionali è la suddivisione dell'app nelle sue funzioni di base. Ciascuna funzione, denominata servizio, può essere compilata e distribuita in modo indipendente. Pertanto, i singoli servizi possono funzionare, o meno, senza compromettere gli altri. In questo modo si accoglie l'aspetto tecnologico di DevOps e si rendono più semplici e attuabili l'iterazione e la distribuzione costanti (CI/CD).

immagine

Pensa alla tua ultima visita al sito di un rivenditore online. Probabilmente hai usato la barra di ricerca del sito per sfogliare i prodotti. La ricerca costituisce un servizio. Potresti avere anche ricevuto suggerimenti per i prodotti correlati, che sono basati su un database di preferenze dei clienti. Anche questo è un servizio. Hai aggiunto un articolo a un carrello online? Ovviamente è un altro servizio.

Pertanto, un microservizio è una funzione di base di un'applicazione, che viene eseguita indipendentemente dagli altri servizi. Tuttavia, l'architettura basata sui microservizi non comporta solo il basso accoppiamento tra le funzioni di base di un'app, ma propone una ristrutturazione dei team di sviluppo e del framework comunicativo tra i servizi. Tale approccio offre la possibilità di gestire criticità inevitabili, supporta la scalabilità dinamica e agevola l'integrazione di nuove caratteristiche.

Per eseguire il deployment dei microservizi e sfruttare i vantaggi di questo approccio, occorre adattare gli elementi di base di un'architettura SOA (Service-Oriented Architecture).

Suddividere un'app nelle relative funzioni base ed evitare le insidie dell'approccio monolitico possono sembrare concetti familiari, perché lo stile architetturale dei microservizi è simile a quello dell'architettura SOA (Service-Oriented Architecture), uno stile di progettazione del software ormai consolidato.

Ai primordi dello sviluppo applicativo, anche un cambiamento minimo a un'app esistente imponeva un aggiornamento completo e un ciclo di controllo qualità (QA, Quality Assurance) a sé, che rischiava di rallentare il lavoro di vari team secondari. Tale approccio viene spesso definito "monolitico", perché il codice sorgente dell'intera app veniva compilato in una singola unità di deployment (ad esempio con estensione .war o .ear). Se gli aggiornamenti a una parte dell'app provocavano errori, era necessario disconnettere tutto, fare un passo indietro e correggere. Questo approccio è ancora applicabile alle piccole applicazioni, ma le aziende in crescita non possono permettersi tempi di inattività.

E qui entra in gioco l'architettura SOA (Service-Oriented Architecture), in cui le app sono strutturate in servizi distinti e riutilizzabili che comunicano fra loro tramite un Enterprise Service Bus (ESB). In questa architettura i singoli servizi sono incentrati su uno specifico processo aziendale e seguono un protocollo di comunicazione, tra cui SOAP, ActiveMQ o Apache Thrift, per essere condivisi attraverso l'ESB. Nel complesso, questa suite di servizi integrati attraverso un ESB costituisce un'applicazione.

Inoltre, questo metodo permette di compilare, testare e modificare più servizi contemporaneamente, svincolando i team IT dai cicli di sviluppo monolitici. Tuttavia, poiché l'ESB rappresenta un singolo punto di errore per l'intero sistema (nel tentativo di eliminare il monolita, se ne crea soltanto un altro), potrebbe comportare un ostacolo per l'intera organizzazione.

Qual è la differenza? I microservizi possono comunicare tra loro, in genere in modalità stateless, permettendo di realizzare app con una maggiore tolleranza di errore e meno dipendenti da un singolo ESB. Inoltre, comunicano tramite interfacce di programmazione delle applicazioni (API) indipendenti dal linguaggio e ciò consente ai team di sviluppo di scegliere i propri strumenti.

Considerando l'evoluzione di SOA, i microservizi non costituiscono una novità assoluta, ma ultimamente sono diventati più appetibili grazie ai progressi delle tecnologie di containerizzazione. Oggi i container Linux permettono di eseguire più parti di un'app in modo indipendente, sullo stesso hardware, con un controllo decisamente superiore sui singoli componenti e cicli di vita. In combinazione con le API e i team DevOps, i microservizi containerizzati rappresentano la base delle applicazioni cloud native.

Basandosi su un'architettura distribuita, i microservizi consentono di ottenere sviluppo e routine più efficienti. La possibilità di sviluppare più microservizi in contemporanea consente a più sviluppatori di lavorare simultaneamente alla stessa app, riducendo le tempistiche di sviluppo.

Time-to-market più rapido

Consentendo di abbreviare i cicli di sviluppo, un'architettura basata su microservizi supporta deployment e aggiornamenti più agili.

Scalabilità superiore

Man mano che la domanda per determinati servizi aumenta, i microservizi possono essere distribuiti su più server e infrastrutture, in base alle esigenze aziendali.

Resilienza

Ciascun servizio, se costruito correttamente, è indipendente e non influisce sugli altri servizi nell'infrastruttura. Di conseguenza, l'eventuale errore di un componente non determina il blocco dell'intera app, come avviene con il modello monolitico.

Semplicità di deployment

Poiché le app basate su microservizi sono più piccole e modulari delle tradizionali applicazioni monolitiche, tutti i problemi associati a tali deployment vengono automaticamente eliminati. Benché questo approccio richieda un coordinamento superiore, per il quale può rivelarsi utile un livello di service mesh, i vantaggi che ne derivano sono determinanti.

Accessibilità

Poiché le app più grandi vengono suddivise in parti più piccole, per gli sviluppatori è molto più semplice comprendere, aggiornare e migliorare tali componenti, e questo permette di accelerare i cicli di sviluppo, soprattutto in combinazione con le metodologie di sviluppo agile.

Maggiore apertura

Grazie alle API poliglotte, gli sviluppatori sono liberi di scegliere il linguaggio e la tecnologia ottimali per la funzione da creare.

Se hai deciso di passare a un'architettura basata su microservizi, è essenziale riuscire a cambiare anche la struttura di comunicazione e collaborazione tra i team, non solo quella delle app. Cambiare la cultura aziendale può risultare difficile, in parte perché ciascun team segue una propria cadenza di deployment ed è responsabile di un servizio unico, per un determinato gruppo di clienti. Pur non essendo una problematica strettamente legata agli sviluppatori, superarla diventa essenziale per il successo dell'architettura basata su microservizi.

Oltre a queste, un'architettura basata su microservizi presenta due criticità principali: la complessità e la produttività. Nel suo intervento in occasione del Red Hat Summit del 2017, il platform architect di Red Hat Mobile John Frizelle ha identificato queste otto categorie di problematiche:

  1. Compilazione: occorre dedicare tempo all'identificazione delle dipendenze fra i servizi. A causa di tali dipendenze, quando si esegue una compilazione può essere necessario eseguirne anche molte altre. È fondamentale considerare anche gli effetti prodotti dai microservizi sui dati.
  2. Test: i test di integrazione, così come i test end-to-end, possono diventare molto difficili, ma anche più importanti che mai. Occorre ricordarsi che un errore in una parte dell'architettura potrebbe causare un errore in un componente poco distante, a seconda del modo in cui i servizi sono strutturati per supportarsi a vicenda.
  3. Gestione delle versioni: l'aggiornamento a una nuova versione potrebbe compromettere la retrocompatibilità. Il problema può essere gestito attraverso la logica condizionale, ma in breve tempo può diventare difficile da gestire. Disporre di più versioni live per client diversi può essere un'alternativa, ma la manutenzione e la gestione possono essere molto più laboriose.
  4. Deployment: durante la configurazione iniziale, anche questa è una fase critica. Per semplificare il deployment, occorre innanzitutto investire notevolmente in soluzioni di automazione. La complessità dei microservizi renderebbe il deployment manuale estremamente difficile. Pensa al modo e all'ordine in cui eseguire il roll-out dei servizi.
  5. Registrazione: nei sistemi distribuiti, per ricollegare tutti i vari componenti sono necessari registri centralizzati, senza i quali gestirli in modo scalabile risulterebbe impossibile.
  6. Monitoraggio: è fondamentale per i team operativi avere una visibilità centralizzata del sistema, al fine di identificare l'origine dei problemi.
  7. Debugging: il debugging remoto tramite l'ambiente di sviluppo integrato (IDE) locale non è una scelta praticabile con decine o centinaia di servizi. Al momento non esiste un'unica soluzione legata al debugging.
  8. Connettività: occorre valutare quale metodo di rilevamento dei servizi scegliere, se centralizzato o integrato.

Massimizza il tuo investimento

Alcune infrastrutture virtuali possono limitare le opzioni software a disposizione, vincolando l'azienda a contratti di licenza enterprise. La migrazione alla virtualizzazione open source può agevolare l'adozione dei container.

Keep reading

ARTICOLO

I microservizi supportano l'integrazione dell'IT nel settore sanitario

I microservizi permettono agli sviluppatori che lavorano in ambito sanitario e altri settori di creare applicazioni che grazie all'impiego di servizi a basso accoppiamento risultano facili da sviluppare, testare, distribuire e aggiornare.

ARTICOLO

Cosa sono i microservizi?

I microservizi sono un approccio architetturale alla realizzazione di applicazioni, in cui le varie componenti di un'app, che vengono suddivise in funzioni indipendenti, lavorano insieme.

ARTICOLO

Cos'è una service mesh?

Una service mesh è un livello infrastrutturale integrato direttamente nell'app in grado di documentare le modalità di interazione tra i vari servizi, ottimizzando la comunicazione ed evitando i tempi di inattività.

Scopri di più sui microservizi

Prodotti

Red Hat OpenShift

Una piattaforma container enterprise-ready basata su Kubernetes, che consente di automatizzare le operazioni nell'intero stack tecnologico per gestire deployment di cloud ibrido, multicloud e all'edge.

Risorse

Ebook

Il percorso verso le applicazioni cloud-native: 8 passi per guidarti nel percorso verso il cloud native.

Ebook

Come rendere agile un'architettura monolitica.

Formazione

Corso di formazione gratuito

Developing Cloud-Native Applications with Microservices Architectures

Illustration - mail

Ricevi contenuti simili

Iscriviti a Red Hat Shares, la nostra newsletter gratuita.