I container secondo AWS tra potenza, scelta e responsabilità

I container stanno cambiando il mondo dello sviluppo e del deployment di applicazioni sui server: questo modello permette infatti di velocizzare i tempi di messa in opera delle applicazioni e garantisce maggiore flessibilità e sicurezza, ma presenta anche problematiche nuove cui le aziende devono fare fronte. Ne abbiamo parlato con Massimo Re Ferrè, principal developer advocate in Amazon Web Services.

Container: tante opportunità e tante sfide

Le macchine virtuali astraggono il concetto di hardware e rendono possibile l'esecuzione di più sistemi operativi su una stessa macchina. I container, invece, astraggono il concetto di sistema operativo e così creano un nuovo "strato" di astrazione in cui vengono spostati librerie, eseguibili e altre componenti del sistema operativo. In questo modo l'applicazione è indipendente dal sistema operativo in cui è eseguita e ciò rende possibile, ad esempio, eseguirne molteplici copie senza che queste siano in contatto l'una con l'altra. Per contro i container non consentano lo stesso livello di sicurezza delle macchine virtuali e per questo motivo esistono soluzioni come AWS Fargate, che tra le altre cose garantisce la separazione dei container confinandoli in macchine virtuali dedicate. I container sono controllati da un software, definito orchestrator, che si occupa di gestire e coordinare i vari container in esecuzione. Il più utilizzato attualmente è Kubernetes ("timoniere" in greco).

L'avvento dei container ha facilitato l'utilizzo del metodo DevOps, in cui il confine tra sviluppatori e sistemisti si sfuma: la gestione dello sviluppo e quella del deployment dei progetti diventa un tutt'uno e permette di rilasciare nuove versioni del software più velocemente e in maniera continua, con miglioramenti incrementali. La sfida per le aziende in questo contesto è quella di rivedere il processo di sviluppo e di gestione dei progetti, ma quando riescono a completare questo passaggio le opportunità che si aprono loro sono notevoli: grazie al modello dei container è possibile ottenere maggiore flessibilità e maggiore capacità di rispondere alle esigenze specifiche dell'azienda.

Questo perché, come ci spiega Re Ferrè, i container hanno tempistiche di avvio e risposta molto inferiori rispetto a quelle delle macchine virtuali: per via delle caratteristiche intrinseche di questo modello, serve pochissimo tempo per avviare un container e per rispondere alle richieste.

Re Ferrè ci segnala il caso di MailUp: "MailUp Group è un leader nel campo delle tecnologie per il marketing nel cloud. Una delle ragioni, tra le tante, per cui MailUp usa container e’ perche’ l’azienda ha trovato conveniente questo formato per la migrazione da data center al cloud AWS. Infatti uno dei vantaggi dei container e’ che possono essere trasportati facilmente. MailUp usa ECS per far girare container su AWS. In precedenza usava lo stack Docker nel proprio data center durante il periodo di transizione. Nel passaggio al cloud MailUp ha notato molteplici benefici tra cui un time-to-market dei propri prodotti da piu’ di 6 mesi a meno di 2 mesi e tempi di sviluppo applicativo ridotti di circa due terzi. Come dimostra l’esperienza di MailUp, il formato container puo’ risolvere gran parte delle necessita’ relative alla portabilita’ delle applicazioni indipendentemente dall’utilizzo dell’orchestratore utilizzato"

AWS Fargate è, come ci spiega Re Ferrè, una ulteriore semplificazione rispetto al modello dei container "classico": Fargate permette, infatti, di occuparsi solo del proprio container, delegando ad AWS la configurazione e la manutenzione della piattaforma sottostante. In questo modo le aziende possono cogliere tutti i vantaggi del modello dei container senza però doversi più occupare dei dettagli tecnici sottostanti, che spesso sono quelli che comportano i problemi e le spese più grandi. Si tratta a tutti gli effetti di un'applicazione del modello serverless nell'ambito dei container.

“I vantaggi principali di Fargate sono molteplici. Innanzitutto permette di non dover gestire l’infrastruttura computazionale necessaria per far girare i container, riducendo cosi’ i costi di gestione", afferma Re Ferrè. "In seconda istanza Fargate permette di far girare un task ECS o un pod EKS in modo dedicato su una singola istanza di macchina virtuale gestita. Questo permette di aumentare il grado di sicurezza mitigando il problema dei “container escapes”, cioe’ la possibilita’ che un’applicazione che gira in un container prenda possesso dell’host e di altri container che girano sullo stesso host. Fargate, inoltre, e’ agnostico all’orchestratore e puo’ essere usato sia da utenti di Amazon ECS che da utenti di Amazon EKS”.

Questa così grande flessibilità e scalabilità porta però anche a un problema di controllo delle spese. Re Ferrè porta l'esempio di Avio Aero, cliente di AWS in Italia, che è riuscito a portare i suoi applicativi verso i container di AWS in appena sei mesi di tempo e mantenendo la stessa operatività, ma spendendo 12€ al mese. Si tratta di un risultato eccezionale sotto tutti i profili che mostra quanto una configurazione ben fatta e pensata appositamente per il sistema cui ci si appoggia possa garantire risparmi significativi rispetto alle soluzioni tradizionali. Non sempre le aziende tengono però conto delle differenze esistenti tra i vari modelli di fatturazione e questo le porta a spendere di più; in questi casi è consigliabile affidarsi alla consulenza di esperticon i quali stabilire la giusta strategia di migrazione.

L'offerta di AWS include due orchestratori: da un lato c'è EKS che offre un'implementazione upstream, ovvero senza modifiche, di Kubernetes compatibile con tutti i fornitori che offrono Kubernetes; dall'altro c'è ECS, con un'implementazione di un orchestratore creato da Amazon con collegamenti ad altri servizi dell'azienda. Entrambe le soluzioni sono compatibili anche con Fargate. EKS è l'opzione migliore nel caso in cui si voglia rimanere fedeli allo standard e si voglia mantenere l'interoperabilità con altri fornitori di cloud, mentre ECS è la scelta di chi voglia o abbia necessità di utilizzare anche specifici servizi di Amazon non compatibili con EKS.

"Per alcuni clienti l’integrazione nativa delle applicazioni con gli altri servizi AWS e’ una priorita’ di business ed una opportunita’ di abbattere costi di gestione. Questi clienti tipicamente scelgono Amazon ECS, un servizio completamente gestito e nativamente integrato con altri servizi AWS. Altri clienti hanno esigenze particolari quali la necessita’ di configurare l’orchestrazione dei container in modo peculiare usufruendo di un vasto ecosistema open source di soluzioni add-on. Questi clienti tipicamente scelgono Amazon EKS, un servizio gestito basato su Kubernetes e compatibile con l’ecosistema stesso. Come dimostrato dal caso di MailUp comunque, la portabilita’ delle applicazioni e’ principalmente garantita dal formato container in primis, ed in seconda battuta dall’orchestratore utilizzato."

La responsabilità condivisa e il futuro

C'è poi il tema dell'informazione sul modello a responsabilità condivisa (shared responsibility model in inglese): questo modello prevede che il fornitore di servizi abbia una parte di responsabilità, che solitamente corrisponde alla fornitura del servizio e alla garanzia di fornirlo entro i termini stabiliti dal contratto, mentre la restante parte di responsabilità (sicurezza delle applicazioni, configurazione, ecc) appartiene al cliente. Il modello è in realtà piuttosto semplice, ma molte aziende non lo hanno ancora compreso correttamente poiché è piuttosto differente rispetto ai modelli passati; per questo i più critici dicono che i fornitori di servizi non fanno abbastanza, mentre altri affermano che sono le aziende a doversi impegnare per comprendere un modello in uso da anni.

Re Ferrè afferma che "personalmente penso che non si faccia mai abbastanza. È per questo che Amazon fornisce numerosi strumenti per tenere sotto controllo le proprie istanze e ricevere avvisi nel caso ci siano problemi, ma c'è sicuramente ancora molto da fare." Garantire che le aziende abbiano maggiore controllo su cosa sta accadendo sulle proprie istanze e che abbiano degli avvertimenti nel caso avvenga qualcosa di inaspettato è uno degli impegni di AWS, che sta continuamente implementando nuove funzionalità per andare verso una presa di coscienza maggiore delle aziende e verso una maggiore semplificazione dei controlli.

Grazie ai sistemi già a disposizione si possono ottenere risultati come quello precedentemente citato dell'azienda italiana passata ai container su AWS: la verità sta, come spesso accade, nel mezzo e saranno necessari sforzi da entrambe le parti per ottenere risultati migliori.

Abbiamo chiesto a Re Ferrè quale modello si affermerà di più in futuro: se sarà quello a container (e, sa sua volta, se Kubernetes o ECS) o se sarà un altro modello. Secondo Re Ferrè in questo momento il modello a container costituisce un'importante opportunità per le aziende ed è quello che avrà maggiore diffusione per i casi d'uso previsti. Le evoluzioni future sono difficili da prevedere, ma Amazon sarà pronta a offrire nuovi servizi in base ai mutamenti tecnologici e del mercato.