Microservizi e architettura di microservizi
Scopri i pro e i contro dei microservizi e come differiscono dai monoliti.
Non molto tempo fa, il metodo di compilazione di applicazioni software più gettonato era l'architettura monolitica, un'unità singola e autonoma. Questo approccio ha funzionato bene per molti sviluppatori finché le applicazioni non sono diventate più complesse. Quando viene modificata una piccola sezione di codice all'interno di un sistema monolitico, è necessario ricompilare l'intero sistema, eseguire test su quest'ultimo e distribuire una versione completamente nuova dell'applicazione.
Poi sono arrivati i microservizi, un approccio che suddivide i sistemi software in unità più piccole sviluppate e distribuite in modo autonomo. L'architettura di microservizi è stata guidata dal movimento DevOps che mira al rilascio frequente di aggiornamenti, come nuove funzioni, correzioni di bug e miglioramenti della sicurezza. Questo approccio ha, in molti casi, tracciato per le aziende un percorso da seguire per riscrivere le applicazioni esistenti utilizzando linguaggi di programmazione moderni e aggiornamenti dello stack tecnologico.
I microservizi sono una raccolta di piccole unità che rilasciano e distribuiscono costantemente applicazioni complesse e di grandi dimensioni.
Cosa sono i microservizi?
Un'architettura di microservizi, nota anche semplicemente come "microservizi", è un approccio alla compilazione di applicazioni come serie di servizi distribuibili in modo indipendente, decentralizzati e sviluppati in modo autonomo. Questi servizi sono debolmente accoppiati, distribuibili in modo indipendente e facilmente gestibili. Mentre un'applicazione monolitica è compilata come una singola unità indivisibile, i microservizi suddividono tale unità in una raccolta di unità indipendenti che contribuiscono all'insieme più ampio. I microservizi sono parte integrante di DevOps, dal momento che sono alla base delle pratiche di continuous delivery che consentono ai team di adattarsi rapidamente ai requisiti degli utenti.
Un microservizio è un servizio web responsabile di una parte della logica di dominio. Più microservizi si uniscono per creare un'applicazione, in cui ciascuno di questi fornisce una parte di funzionalità per un dominio. I microservizi interagiscono tra di loro tramite API, come REST o gRPC, ma non conoscono i meccanismi interni degli altri servizi. Questa interazione armoniosa tra i microservizi è un'architettura di microservizi.
Tramite un'architettura di microservizi, gli sviluppatori possono organizzarsi in team più piccoli specializzati in diversi servizi, con diversi stack e distribuzioni disaccoppiate. Ad esempio, Jira si basa su più microservizi, ciascuno dei quali fornisce funzionalità specifiche come la ricerca dei ticket, la visualizzazione dei dettagli dei ticket, i commenti, le transizioni dei ticket e molto altro.
Caratteristiche dei microservizi
Non esiste una definizione formale dell'architettura di microservizi, ma vi sono alcuni schemi o caratteristiche comuni che è importante conoscere.
Componenti autonomi
Il blocco predefinito di base dell'architettura di microservizi è un componente, che può essere un pacchetto di software, un servizio web o una risorsa, un'applicazione o un modulo contenente una serie di funzioni correlate. Oppure, come spiegato con parole più semplici da Martin Fowler: "I componenti software sono elementi sostituibili e aggiornabili in modo indipendente".
In un'architettura di microservizi, ciascun componente può essere sviluppato, distribuito, utilizzato, modificato e ridistribuito senza compromettere il funzionamento degli altri servizi o l'integrità dell'applicazione.
I componenti vengono utilizzati insieme ad altri componenti per offrire valore aziendale o un'esperienza cliente di qualità. I componenti più comuni sono i servizi e le raccolte, ma vi sono anche gli strumenti dell'interfaccia della riga di comando, le app mobili, i moduli front-end, le pipeline di dati, i modelli di apprendimento automatico e molti altri concetti applicabili all'interno di un'architettura di microservizi.
Interfacce semplici
Dopo essere stati definiti, i singoli componenti richiedono una considerevole quantità di logica per comunicare tra di loro attraverso un meccanismo di comunicazione dedicato come RPC, REST su HTTP o un sistema basato su eventi. Questi meccanismi potrebbero essere metodi sincroni o asincroni e i microservizi potrebbero utilizzare una combinazione di entrambi.
L'aspetto più importante è che ciascun microservizio deve fornire un contratto chiaro e intuitivo in cui sono descritte le modalità di utilizzo del servizio per il consumatore. Ciò viene fatto in genere tramite un'API pubblicata insieme al servizio.
You Build It, You Run It
La filosofia DevOps "You Build It, You Run It" ha messo in luce il concetto che non è possibile modificare un'architettura in microservizi senza tenere in considerazione la struttura dei team. DevOps riallinea gli incentivi dei diversi ruoli funzionali (sviluppo, controllo di qualità, progettazione dei rilasci, operazioni) in un singolo team con l'obiettivo comune di creare software di elevata qualità. Le pratiche DevOps, come CI/CD, test automatizzati e flag delle funzioni, accelerano la distribuzione e favoriscono la stabilità e la sicurezza del sistema. Inoltre, ogni team può compilare e distribuire microservizi di sua proprietà senza influire sugli altri team.
L'evoluzione del cloud ha semplificato le operazioni di creazione, distribuzione e funzionamento dei microservizi. Le tecniche di automazione dell'infrastruttura come la continuous integration, la continuous delivery e i test automatizzati agevolano il lavoro dei team.
Architettura orientata ai servizi e microservizi a confronto
L'architettura orientata ai servizi (SOA) e i microservizi sono due tipi di architetture dei servizi web. Come l'architettura di microservizi, una SOA comprende componenti riutilizzabili e specializzati che funzionano in modo indipendente gli uni dagli altri. La distinzione tra i due tipi di architettura risiede nella classificazione burocratica dei tipi di servizi.
Una SOA dispone di quattro tipi di servizi di base:
- Business
- Enterprise
- Applicazione
- Servizi di infrastruttura
Questi tipi definiscono la responsabilità specifica del dominio correlata dei servizi sottostanti. Invece, l'architettura di microservizi dispone soltanto di due tipi di servizi: funzionali e dell'infrastruttura.
Entrambe le architetture condividono lo stesso insieme di standard a diversi livelli di un'azienda. L'esistenza di un'architettura di microservizi è strettamente connessa alla riuscita di uno schema SOA. Di conseguenza, un'architettura di microservizi è un sottoinsieme di SOA. In questo caso, l'obiettivo principale è l'autonomia di runtime di ciascun servizio.
Vantaggi dei microservizi
Agilità
Dal momento che generalmente creano un servizio all'interno dei microservizi, i team piccoli e indipendenti sono incoraggiati ad adottare le pratiche Agile. I team hanno la possibilità di lavorare in modo indipendente e più rapidamente, riducendo i tempi del ciclo di sviluppo.
Scalabilità flessibile
Poiché sono progettati per essere distribuiti, anche in cluster se necessario, i microservizi consentono la scalabilità orizzontale dinamica tra i limiti dei servizi. Se un microservizio raggiunge la capacità di carico, è possibile distribuire rapidamente nuove istanze di tale servizio nel cluster che lo accompagna per ridurre la pressione.
Rilasci frequenti
Uno dei vantaggi principali dei microservizi sono i cicli di rilascio frequenti e più rapidi. Come elementi chiave della continuous integration e continuous delivery (CI/CD), i microservizi consentono ai team di sperimentare nuove funzioni ed eseguire il rollback se qualcosa va storto Ciò semplifica l'aggiornamento del codice e accelera il time-to-market delle nuove funzioni.
Flessibilità tecnologica
Le architetture di microservizi non seguono necessariamente un approccio fisso con una sola toolchain, ma danno ai team la libertà di scegliere gli strumenti che preferiscono.
Focus sulla qualità
La separazione degli interessi aziendali in microservizi indipendenti implica la possibilità per il team proprietario di quel servizio di concentrarsi sulla qualità del rilascio finale.
Affidabilità elevata
Grazie alla separazione delle funzionalità, i microservizi riducono il rischio di interferenze con un'intera applicazione o una base di codice durante il rilascio degli aggiornamenti. È semplice isolare e correggere gli errori e i bug nei singoli servizi. È possibile distribuire le modifiche soltanto su un servizio specifico, senza dover arrestare l'intera applicazione, garantendo quindi affidabilità elevata.
Sfide dei microservizi
Estensione dello sviluppo
Il passaggio da un monolite ai microservizi comporta una maggiore complessità. Vi sono più servizi in più posizioni, creati da più team. Ciò può rendere difficile determinare le relazioni tra i diversi componenti, individuare chi possiede un determinato componente o capire come evitare di influire negativamente sui componenti dipendenti. Se l'estensione non viene gestita, si traduce in velocità di sviluppo ridotta e in scarse prestazioni operative. Con la crescita del sistema, si rende necessario un team delle operazioni esperto che si occuperà della gestione delle nuove distribuzioni costanti e delle modifiche frequenti all'architettura.
Poca chiarezza sulla proprietà
L'architettura di microservizi aggiunge confusione sull'attribuzione della proprietà dei diversi elementi. Il team DevOps potrebbe eseguire un insieme di API, raccolte di componenti, strumenti di monitoraggio e immagini Docker per gli utenti per distribuire un'applicazione. È importante disporre di informazioni approfondite sui componenti, inclusi i responsabili, le risorse e le relazioni in evoluzione tra gli altri componenti. Servono comunicazione e coordinamento precisi tra i diversi team per far sì che tutte le persone coinvolte trovino con facilità le informazioni necessarie per comprendere un prodotto.
Costi di infrastruttura esponenziali
Ogni nuovo microservizio aggiunto alla distribuzione nell'ambiente di produzione ha i propri costi relativi a suite di test, playbook di distribuzione, infrastruttura di hosting, strumenti di monitoraggio e molto altro.
Sovraccarico organizzativo aggiunto
È necessario un ulteriore livello di collaborazione e comunicazione per il coordinamento degli aggiornamenti e delle interfacce tra i team dell'architettura di microservizi.
Debug
Può essere complicato eseguire il debug di un'applicazione contenente più microservizi, ciascuno con il suo insieme di log. Un singolo processo aziendale può essere eseguito su più computer e in diversi momenti, rendendo il debug ancora più complicato.
Risposta agli imprevisti
È importante disporre di informazioni sulla risposta agli imprevisti relativi ai microservizi, ad esempio informazioni su chi sta utilizzando il microservizio, dove questo è stato distribuito e come e chi contattare in caso di problemi.
Microservizi e DevOps: due gocce d'acqua
Dato l'aumento della complessità e delle dipendenze dei microservizi, le pratiche DevOps di automazione della distribuzione, del monitoraggio e del ciclo di vita sono considerate parti integranti delle architetture di microservizi. Per questo motivo i microservizi sono spesso considerati il primo passo verso l'adozione di una cultura DevOps, che offre:
- Automazione
- Scalabilità migliorata
- Gestibilità
- Agilità
- Accelerazione dello sviluppo e della distribuzione
Strumenti e tecnologie chiave dell'architettura di microservizi
Container, Docker e Kubernetes
Un container non è altro che il pacchetto di un'applicazione e tutte le sue dipendenze, che ne consente la distribuzione agevole e coerente. Dal momento che i container non presentano il sovraccarico dato dal sistema operativo, sono più piccoli e più leggeri rispetto alle macchine virtuali tradizionali. Possono avviarsi e arrestarsi più rapidamente e rappresentano un abbinamento perfetto con i servizi di dimensioni ridotte che compongono le architetture di microservizi.
Con la proliferazione di servizi e container, l'orchestrazione e la gestione di gruppi più grandi di container riveste un'importanza fondamentale. Docker è un'apprezzata piattaforma di containerizzazione e runtime che aiuta gli sviluppatori a compilare, distribuire ed eseguire i container. Tuttavia, l'esecuzione e la gestione dei container su larga scala rappresenta una sfida se si utilizza soltanto Docker. Kubernetes e altre soluzioni come Docker Swarm, Mesos, HashiCorp Nomad e molte altre aiutano a gestire la containerizzazione su larga scala.
La containerizzazione e la distribuzione dei container rappresentano un nuovo schema di infrastruttura distribuita. Docker e Kubernetes creano pacchetti di servizi in un container completo che può essere rapidamente distribuito ed eliminato. Questi strumenti di infrastruttura sono complementari all'architettura di microservizi. I microservizi possono essere containerizzati, distribuiti agevolmente e gestiti tramite un sistema di gestione dei container.
Gateway API
I singoli servizi all'interno di un'architettura di microservizi comunicano tra loro attraverso API ben definite. Un gateway API funge da proxy inverso accettando le chiamate API, raccogliendo i servizi per gestirle e restituendo i risultati. I gateway API forniscono un'astrazione diretta a un singolo endpoint API, anche se le API sono gestite da più microservizi. I gateway API possono inoltre consolidare elementi come la limitazione della velocità, il monitoraggio, l'autenticazione, l'autorizzazione e il reindirizzamento al microservizio appropriato.
Messaggistica e streaming degli eventi
A causa della natura distribuita dei microservizi, i team necessitano di un modo per condividere le modifiche dello stato e altri eventi. I sistemi di messaggistica comunicano tra i microservizi, consentendo ad alcuni di questi di elaborare gli eventi come parte della loro interfaccia principale. Ad esempio, le modifiche apportate alle pagine di Confluence si traducono in un evento che attiva una reindicizzazione della ricerca e delle notifiche agli utenti che monitorano la pagina.
Registrazione e monitoraggio
I microservizi rendono difficile identificare un problema e risolverlo su più servizi. È importante disporre di strumenti di osservabilità per la registrazione, il monitoraggio e la tracciabilità. In questo modo, sarà possibile comprendere il comportamento dei microservizi, identificare potenziali problemi, risolvere i problemi ed eseguire il debug degli errori.
Continuous integration/continuous delivery
Uno dei vantaggi principali dei microservizi sono i cicli di rilascio frequenti e più rapidi. Come elementi chiave di CI/CD, i microservizi consentono ai team di sperimentare nuove funzioni ed eseguire il rollback se qualcosa va storto. Ciò semplifica l'aggiornamento del codice e accelera il time-to-market delle nuove funzioni.
Portale degli sviluppatori
Man mano che la complessità delle architetture distribuite aumenta, i team di sviluppo possono trarre vantaggio da uno strumento in grado di consolidare le informazioni sui risultati tecnici e la collaborazione tra i team in un'unica posizione. Ad esempio, Atlassian Compass è stato progettato per aiutare a controllare la proliferazione di microservizi fornendo dati e informazioni approfondite sulle toolchain DevOps.
Futuro dei microservizi
La containerizzazione e la distribuzione dei container rappresentano oggi uno schema comune di infrastruttura distribuita. Strumenti come Docker e Kubernetes creano pacchetti di servizi in un container completo che può essere rapidamente distribuito ed eliminato. Questi nuovi strumenti di architettura sono complementari all'architettura di microservizi, dal momento che i microservizi possono essere containerizzati, distribuiti agevolmente e gestiti tramite un sistema di gestione dei container.
L'adozione dei microservizi deve essere considerata un percorso piuttosto che l'obiettivo immediato di un team.
Può essere utile iniziare a piccoli passi per capire i requisiti tecnici di un sistema distribuito e ampliare i singoli componenti. Quindi, sarà possibile estrarre gradualmente più servizi man mano che si acquisiscono esperienza e dimestichezza.
Esplora i microservizi con Compass
Se hai scelto di utilizzare un'architettura di microservizi, Compass di Atlassian gestisce la complessità delle architetture distribuite man mano che si ampliano. Si tratta di una piattaforma di sviluppo estensibile che riunisce i dati separati dei risultati tecnici e della collaborazione tra i team in un'unica posizione centrale e ricercabile. Oltre ad aiutarti a controllare la proliferazione di microservizi con il Catalogo componenti, Compass può essere utile per stabilire best practice, misurare l'integrità del software con le scorecard e fornirti dati e informazioni approfondite sulla toolchain DevOps utilizzando estensioni create sulla piattaforma Atlassian Forge.
