I pro, i contro e le sfide dei microservizi containerizzati

Non è necessario utilizzare i container per il deployment di microservizi e non si è obbligati ad adottare i microservizi per utilizzare i container. Questo in teoria. Poi, nella pratica, quelli citati sono due elementi che operano spesso assieme, perché a legarli c’è una relazione che può portare a rilevanti vantaggi, così come a qualche criticità da affrontare.

Da un lato i container rendono i microservizi più facili da sviluppare e gestire, specialmente quando i developer passano a un approccio focalizzato sulla gestione di microservizi containerizzati. Dall’altro lato. Però, i container aggiungono complessità in un ambiente basato sui microservizi, nel provisioning del server, ad esempio, o nello stoccaggio dei dati. Diventa quindi fondamentale sviluppare una strategia adeguata e completa per poter operare in modo efficiente con i microservizi containerizzati prima di implementare questo tipo di deployment.

Pro e contro dei microservizi containerizzati

Come il nome suggerisce, creare microservizi containerizzati significa distribuire singoli servizi applicativi all’interno di un’unità container astratta. In alternativa è possibile anche distribuire istanze di microservizi come pacchetti di funzioni serverless, all’interno di una VM tradizionale, o anche su un singolo host. Quella dei container, quindi, non è l’unica opzione possibile, ma resta la più diffusa per il deployment dei microservizi. Esistono delle valide ragioni perché ci accada, ecco le principali:

• Isolamento. I container permettono agli sviluppatori di isolare i microservizi all’interno di un ambiente software-defined. Rendono anche più facile impostare i limiti sul consumo di risorse di ciascuno di essi e prevenire potenziali problemi di rumore
• Efficienza. A causa di un overhead di risorse inferiore, quando i microservizi sono numerosi, tendono a funzionare in modo più efficiente con i container che non con le tradizionali VM o il singolo host.
• Qualità. Nella maggior parte dei casi, un microservizio ospitato all’interno di un container funzionerà in modo coerente, indipendentemente dalle configurazioni dell’ambiente host sottostante. Questo riduce il numero di variabili che gli sviluppatori devono affrontare durante le fasi di test e deployment.
• Scalabilità. È possibile scalare i microservizi containerizzati semplicemente aggiungendo più istanze di container. Si riduce così la complessità riscontrata nel doverli adeguare spesso per dare risposta a ogni cambiamento dinamico dell’applicazione

Oltre a questi vantaggi, l’utilizzo dei container comporta anche un costo. Il livello aggiuntivo di astrazione introdotto impone, infatti, di affrontare un nuovo livello di complessità di gestione. Si tratta di nuove sfide che però non richiedono per forza nuovi strumenti o soluzioni, possono essere fronteggiate e vinte anche utilizzando quelli già oggi disponibili per la gestione dei container, sia open source che proprietari. Ciò non toglie che sia necessario iniziare a familiarizzare con questi strumenti e imparare a implementarli efficacemente se non si è già in grado di farlo.

Per esempio, è necessario assicurarsi che sia stato effettuato un corretto provisioning sui server host, includendo i vari runtime dei container. In molti casi, questo richiede l’implementazione di un sistema di orchestrazione dei container come Kubernetes. Per ogni servizio sarà essenziale anche garantire il provisioning di rete e di storage, passaggio più complesso quando si ha a che fare con i container rispetto a quando si decide di fare il deployment direttamente su un host.

Nella maggior parte dei casi, i benefici apportati dai microservizi containerizzati superano di gran lunga le sfide. Se però una applicazione è relativamente semplice e include un piccolo numero di servizi, è meglio chiedersi se valga davvero la pena di pagare il prezzo della complessità introdotta dai container, oppure optare per un altro approccio.

Microservizi basati su container: 5 fattori critici da considerare

Ci sono alcune criticità a cui prestare attenzione quando si sceglie di adottare microservizi containerizzati. Si tratta di problematiche che possono risultare già familiari ad alcuni. Non bisogna farsi ingannare e banalizzarle perché, in questo tipo di situazione, assumono un nuovo significato e complicano la gestione dei container. Ecco i 5 aspetti principali da tenere d’occhio:

Runtime dei container. È più semplice approcciare i microservizi containerizzati usando un set completo di strumenti di gestione della configurazione, invece di distribuire semplicemente i singoli runtime dei container. Il runtime mediamente usato per i container è adatto ed efficace per le fasi di esecuzione, ma non quando si tratta del management di veri e propri container. Ci sono una varietà di runtime disponibili da diversi fornitori, quasi tutte simili. L’unica cosa da appurare è che siano conformi alle specifiche dettate dalla Open Container Initiative.

Orchestrazione del servizio. Quando si lavora con un numero considerevole di container, è importante utilizzare strumenti di orchestrazione che automatizzano i compiti più operativi, come il deployment dei container su un cluster di server. Kubernetes è tipicamente il go-to container orchestrator, in particolare per chi usa Docker, ma ci sono anche altre piattaforme di gestione dei container progettate per essere performanti in casi specifici. Per esempio, Amazon Elastic Container Service e Red Hat OpenShift sono due opzioni proprietarie con caratteristiche di livello enterprise come l’automazione del flusso di lavoro su larga scala e pipeline CI/CD integrate.

Storage persistente. Poiché i dati dei container tipicamente scompaiono una volta che l’istanza termina, quelli che si basano su dati persistenti avranno bisogno di implementare un meccanismo di archiviazione esterno. Lo storage dei dati per i container è tipicamente gestito da un componente dell’orchestratore, è quindi importante assicurarsi che tra i due ci sia compatibilità. Kubernetes, ad esempio, supporta dozzine di prodotti di storage attraverso la Container Storage Interface.

Networking. Anche se distribuiti in modo indipendente, i microservizi posti nei container hanno ancora bisogno di comunicare tra loro. Questo accade tramite una rete di servizi che gestisce le richieste tra i microservizi utilizzando un componente proxy astratto. Quando questi servizi interagiscono con endpoint esterni, è necessario anche disporre di un portale di comunicazione che possa verificare e inoltrare le richieste da componenti esterni, come un gateway API. Quando il traffico è elevato, serve anche un bilanciatore di carico da implementare per prevenire i sovraccarichi distribuendo le richieste su più istanze di container.

Sicurezza. Anche se i microservizi spesso richiedono l’accesso alle risorse di back-end, l’esecuzione dei container in modalità privilegiata permette loro l’accesso diretto alle capacità di root dell’host per evitare di esporre il kernel e altri componenti sensibili del sistema a dei cyber risk. Compito dei developer sarà quello di impostare le definizioni del contesto di sicurezza e le policy di rete in modo da impedire l’accesso non autorizzato ai container e ai sistemi sottostanti. Sono da implementare anche strumenti in grado di verificare che le configurazioni dei container soddisfino i requisiti di sicurezza e gli scanner delle immagini dei container per rilevare automaticamente le potenziali vulnerabilità.

Nonostante i fattori critici che li caratterizzano, i container rappresentano ancora il modo più semplice per fare il deployment di microservizi in ambienti di produzione dinamici. Questo è ancora più vero in scenari su larga scala. Rispetto ad altri metodi, i microservizi containerizzati continuano a introdurre in alcune situazioni un livello di complessità che non si riscontra con la distribuzione delle VM, ad esempio. C’è però ancora una ampia gamma di strumenti forniti dai provider e anche open source che vanno incontro a chi sceglie questo approccio. Oltretutto la maggior parte degli strumenti di orchestrazione incentrati sui container, i plugin di storage e gli scanner di sicurezza forniscono un grado di automazione tale da eliminare la maggior parte del lavoro richiesto per gestire i container su scala.