Punti chiave
- Puoi scalare in modo indipendente parti specifiche della tua applicazione per adeguarti alla domanda, risparmiando così su costi e risorse server.
- Se una parte del sistema si guasta, il resto dell’applicazione di norma continua a funzionare, evitando un’interruzione totale.
- Gestire molti servizi di piccole dimensioni è complesso: servono strumenti automatizzati per avviarli, arrestarli e collegarli in modo affidabile.
- Poiché i servizi sono distribuiti e si riavviano di frequente, servono strumenti di monitoraggio centralizzato per seguire le prestazioni e individuare rapidamente gli errori.
- Questo approccio è ideale per progetti grandi e complessi, ma la configurazione e la manutenzione aggiuntive lo rendono superfluo per la maggior parte delle aziende più piccole.
- Devi conservare i dati importanti separatamente dai servizi e usare sistemi automatizzati per eseguirne il backup e per segnalare gli errori.
Un’architettura basata su microservizi è vantaggiosa per le applicazioni che devono essere altamente scalabili, resilienti e disponibili, così come per le situazioni d’uso in cui la latenza è un problema, perché consente di distribuire i componenti vicino agli utenti finali. I microservizi non servono solo a ospitare applicazioni consumer e SaaS: possono essere utilizzati anche per infrastrutture e strumenti interni in cui l’affidabilità è una priorità.
Questa guida spiega come scalare i microservizi e in cosa si differenziano dalle architetture applicative tradizionali, oltre all’impatto che tutto questo ha sul modo in cui i team IT devono gestire, monitorare e mantenere i sistemi basati su microservizi.
Cosa sono i microservizi?
I microservizi (o architettura basata su microservizi) sono un modo di sviluppare applicazioni utilizzando servizi componenti indipendenti, ciascuno dei quali racchiude una funzionalità specifica. I componenti sono debolmente accoppiati e comunicano tramite API (di solito via HTTP), così se un servizio si guasta gli altri possono continuare a funzionare. I microservizi vengono solitamente utilizzati per applicazioni e servizi ospitati in logica client-server, non per applicazioni eseguite localmente sui dispositivi (anche se possono essere containerizzati a questo scopo).
Poiché ogni servizio componente è indipendente, può essere scalato singolarmente: per esempio, una semplice applicazione di e-commerce può essere suddivisa in componenti per l’elaborazione dei pagamenti, l’invio delle email e la visualizzazione delle pagine web. In caso di un’improvvisa impennata di traffico (senza però che nessuno completi davvero l’acquisto del carrello, generando pagamenti ed email), occorrerebbe scalare solo il microservizio del web server. È una soluzione efficiente in termini di risorse e conveniente, che garantisce sempre capacità sufficiente a soddisfare la domanda.
Microservizi e architetture monolitiche
I microservizi sono un’alternativa all’architettura monolitica, in cui tutto risiede in un’unica base di codice, ospitata di norma su un solo server potente.
Il vantaggio principale di un approccio basato su microservizi è la scalabilità: per scalare un’applicazione monolitica puoi aumentare le risorse a sua disposizione (ovvero più memoria e CPU, quello che si chiama scalabilità verticale) oppure eseguire un’altra istanza dell’applicazione e distribuire il carico tra le istanze (scalabilità orizzontale).
Scalare i monoliti può rivelarsi molto inefficiente, a seconda delle dimensioni e della natura dell’applicazione, perché può significare assegnare risorse all’intera applicazione quando in realtà è sotto carico elevato solo un suo piccolo componente. Con i microservizi, invece, ogni componente può essere scalato orizzontalmente e l’utilizzo complessivo delle risorse può essere ottimizzato.
I microservizi rispondono anche all’esigenza di alta disponibilità: in un monolite, se l’applicazione va in crash, va in crash tutto. Al contrario, se va in crash un singolo microservizio, gli altri possono continuare a funzionare mentre quello si ripristina (per esempio, se va in crash il microservizio che invia le email, i clienti possono continuare ad acquistare e al massimo riceveranno con un po’ di ritardo l’aggiornamento sull’ordine, invece di non poter acquistare affatto).
Come i microservizi cambiano le interazioni tra i sistemi
Quando i microservizi scalano orizzontalmente, container o istanze vengono creati ed eliminati in base alla domanda. Questo significa che tutto ciò che si trova nella memoria o nello storage locale va perso. Costruire un’applicazione scalabile basata su microservizi significa anche gestire questo aspetto con storage persistente, database e meccanismi per condividere lo stato (come i key-value store).
I microservizi dipendono inoltre in modo determinante dalle prestazioni di rete: i componenti devono comunicare costantemente, con bassa latenza e senza interruzioni.
Nuove tipologie di guasto nei sistemi distribuiti basati su microservizi
Uno dei vantaggi dei microservizi è che i componenti possono continuare a funzionare quando altri si guastano, ma questo non è sempre realizzabile: dipende dalla situazione d’uso e dalle scelte di progettazione fatte durante lo sviluppo.
Inevitabilmente alcuni componenti dipenderanno dalla disponibilità di altri e alcune operazioni devono essere eseguite in sequenza. I guasti, quindi, devono poter propagarsi a cascata e la gestione degli errori deve tenere conto delle interruzioni parziali del sistema, non solo di quelle totali.
Negli ambienti distribuiti la scalabilità funziona in modo diverso (e ha effetti collaterali)
La scalabilità, unita a componenti isolati che possono essere aggiornati singolarmente (purché le loro API restino coerenti), porta a nodi che vengono creati ed eliminati di frequente, man mano che le risorse vengono allocate in base alla domanda. In alcuni casi, un container o un’istanza di un determinato servizio può restare in vita giusto il tempo di servire una singola richiesta.
Questo incide molto sulla visibilità, perché lo stato di ogni componente va perso quando il componente viene eliminato, compresi i log degli errori necessari a diagnosticare i problemi.
Le difficoltà di coordinamento tra servizi
I microservizi devono restare coordinati e raggiungibili tra loro e le dipendenze tra i servizi devono essere considerate nelle configurazioni. Questo comporta l’uso di strumenti come Kubernetes, oppure lo sfruttamento delle funzionalità native di piattaforme cloud come Azure e AWS, per gestire container e macchine virtuali.
Quando si verificano problemi di latenza o di connessione, le architetture basate su microservizi possono diventare inaffidabili o non disponibili.
Le prestazioni dipendono dallo scopo dei microservizi e dalle loro relazioni
In un’architettura basata su microservizi le prestazioni possono essere gestite per priorità su ogni singolo componente. Per esempio, un web server dovrebbe rispondere il più rapidamente possibile, così da offrire agli utenti finali la migliore esperienza, mentre un server di notifiche email può impiegare qualche secondo per inviare un avviso senza conseguenze sull’operatività.
In alcuni casi un microservizio può essere in realtà un’API esterna (per esempio un’API di comunicazione per l’invio di SMS), con aspettative di prestazioni diverse rispetto a un servizio ospitato nello stesso datacenter della tua applicazione.
Tutto questo rende l’ottimizzazione delle prestazioni più complessa e non una semplice questione di numeri assoluti.
Come cresce nel tempo la complessità nei sistemi basati su microservizi
Pur sembrando più complessi, i microservizi possono in realtà semplificare le operazioni IT se sfruttati nel modo giusto: spesso è più facile risolvere i problemi di un singolo servizio isolato che di un intero stack applicativo monolitico.
Ci sono complessità iniziali in fase di configurazione, ma orchestrazione e automazione rendono il deployment delle applicazioni basate su microservizi sempre più semplice per i team DevOps. Gli strumenti CI/CD e gli strumenti di infrastructure-as-code come Terraform eliminano gran parte del lavoro manuale e dei rischi di configurazione errata.
Monitoraggio delle prestazioni e della sicurezza dei microservizi: differenze e difficoltà
La chiave del successo di qualsiasi sistema IT sta nella visibilità e in un approccio proattivo alla risoluzione dei problemi. I team IT e DevOps che passano il tempo a “spegnere incendi” non possono offrire servizi IT stabili e sostenibili. Se ospiti applicazioni basate su microservizi, devi essere in grado di monitorare e risolvere i problemi di macchine virtuali e container.
I Containers as a service (CaaS) possono essere utilizzati anche per astrarre la gestione diretta dell’infrastruttura. Questi servizi offrono interfacce semplificate per gestire le applicazioni containerizzate e si fanno carico di buona parte degli oneri di configurazione, manutenzione e sicurezza legati alla gestione delle piattaforme di orchestrazione dei container.
Anche i backup rappresentano una difficoltà per i microservizi: le istanze in esecuzione non dovrebbero contenere dati di lunga durata da sottoporre a backup, mentre i key-value store, i database e lo storage a oggetti usati per rendere persistenti i dati possono richiedere tutti una soluzione di backup adeguata, che consenta il rollback o il ripristino completo, con immutabilità per proteggersi dalle minacce malevole.
Quando i microservizi offrono il massimo valore
Le applicazioni basate su microservizi offrono il massimo valore quando:
- i componenti richiedono una scalabilità indipendente
- le applicazioni sono grandi e complesse
- i team di sviluppo devono lavorare in autonomia
- è necessario un cambiamento continuo
Per gli utenti finali e gli stakeholder del business, il valore dei microservizi sta nell’affidabilità, nella velocità e nell’ottimizzazione dei costi. Per i team tecnici, sta nella coerenza e nella scalabilità immediata.
Detto questo, non è il caso di correre a chiedere agli sviluppatori di migrare il codice esistente verso un’architettura basata su microservizi. È improbabile che la maggior parte delle piccole e medie imprese tragga beneficio dal lavoro aggiuntivo necessario a riscrivere basi di codice consolidate e dagli oneri operativi legati alla manutenzione di sistemi distribuiti.
Se invece stai progettando e implementando un sistema nuovo, dovresti valutare se un approccio basato su microservizi porti vantaggi operativi nel lungo periodo, soprattutto se hai in programma di scalare fino a servire un numero elevato di utenti.
Controllo e prestazioni per tutta la tua infrastruttura IT
Ottenere informazioni utili sul funzionamento di un’infrastruttura effimera e ad auto-scalabilità può essere difficile. Molti strumenti consentono di gestire gli errori all’interno di container e spot instance, ma spesso sono pensati per gli sviluppatori.
Se il tuo team IT gestisce il funzionamento quotidiano di applicazioni basate su microservizi, dovresti orientarti su strumenti di segnalazione degli errori compatibili con la tua base di codice e integrabili con una piattaforma IT unificata. In questo modo gli avvisi provenienti dalle applicazioni a microservizi vengono centralizzati e affiancati alle notifiche di monitoraggio di endpoint, sicurezza e rete.
Puoi anche impostare il monitoraggio delle prestazioni delle applicazioni per misurare le prestazioni dei singoli microservizi e quelle complessive, e usare l’automazione dell’Helpdesk per inoltrare i problemi o le anomalie di costo al tecnico giusto per una diagnosi immediata.
