I container, come formato di incapsulamento di ambienti applicativi, esistono da almeno tre decenni. La loro caratteristica principale è stata sempre quella di essere ostici da utilizzare. Docker, nell’ormai lontano 2013, ha cambiato radicalmente la traiettoria dei container introducendo strumenti che hanno democratizzato l’accesso a questo formato ormai diventato standard.
Su questa tematica fondamentale abbiamo interpellato Massimo Re Ferrè – Principal Technologist, AWS Elastic Containers, che ha espresso l’autorevole opinione di Amazon Web Services.
AWS ha immediatamente visto il potenziale e l’impatto che questi strumenti avrebbero potuto avere sugli sviluppatori e gli operatori IT. Infatti, nel 2014, AWS, in largo anticipo rispetto all’attuale adozione di servizi basati su container, ha introdotto Amazon ECS (Amazon Elastic Container Service), un servizio cloud completamente gestito per facilitare l’adozione di container su larga scale ed in ambiente di produzione.
Torneremo a parlare di cosa AWS sta facendo e ha fatto nel concreto per anticipare e contribuire a questo trend tecnologico fra qualche paragrafo. Vorrei prima di tutto spendere qualche minuto per capire perché oggi i nostri clienti parlano di container.
Molti clienti vedono i container come naturale evoluzione del formato VM (virtual machine). Infatti il loro ruolo è abbastanza simile: permettere il disaccoppiamento dell’applicazione dall’infrastruttura fisica. Detto ciò, è sembrato chiaro sin da subito che i container avrebbero potuto migliorare sostanzialmente i vantaggi delle tradizionali VM. Alcuni di questi aspetti riguardano la dimensione ridotta dei container e conseguenti risparmi di spazio e tempi di lancio, l’indipendenza dal tipo di infrastruttura e conseguente maggiore mobilità e, soprattutto, dei flussi di impacchettamento e rilascio del software più in linea con le esigenze di automazione necessarie per ottenere maggiore agilità.
Ad esempio, uno dei nostri clienti, MailUp, ha fatto leva sulla caratteristica di indipendenza infrastrutturale garantita dai container per spostare i loro workload dal proprio data center al cloud AWS. Moltissimi altri clienti hanno adottato tecnologie a container per risolvere i più disparati casi d’uso. In particolare osserviamo alcuni modelli di adozione che ricorrono frequentemente.
Innanzitutto l’utilizzo che i nostri clienti fanno dei container ci porta a pensare che non esista un vero e proprio “verticale” adatto a queste tecnologie. I container sono pervasivi ed ubiqui, proprio come lo sono state le macchine virtuali. Il secondo modello di adozione che osserviamo è che, tipicamente, i clienti non utilizzano esclusivamente i container nelle loro architetture ma usano un mix di tecnologie e servizi per risolvere problemi puntuali. Ad esempio Credimi, una startup che opera nel mondo Fintech, utilizza, per i loro flussi applicativi, un mix di servizi e tecnologie che includono container, funzioni AWS Lambda, database Amazon RDS, e storage Amazon S3. Parlando di Lambda e dei vantaggi del formato di impacchettamento dei container, è interessante notare come Lambda abbia introdotto recentemente il supporto al formato “container image”. Questa flessibilità è la diretta conseguenza delle richieste dei clienti che, pur apprezzando il modello di programmazione ad eventi caratteristico dalle funzioni Lambda, preferiscono il modello di impacchettamento “container image” al più tradizionale impacchettamento “zip” caratteristico delle funzioni.
Abbiamo parlato di come AWS ha anticipato questo trend con il rilascio di. In realtà ECS è stato solo il seme di un portafogli prodotti che si è andato ad ampliare nel tempo per rispondere alle esigenze dei nostri clienti. Vediamone alcuni.
Kubernetes è un sofisticato orchestratore di container open source il cui sviluppo e la cui evoluzione sono gestite dalla Cloud Native Computing Foundation (CNCF), un organismo neutrale dai vendor ed indipendente. Secondo le stime e le analisi del CNCF, AWS è sempre stata la principale piattaforma target per i clienti Kubernetes.
Questi clienti, tradizionalmente, installavano il software Kubernetes su istanze EC2. La complessità della gestione del software Kubernetes è ben nota e sappiamo che un gran numero di clienti preferisce lasciare ad AWS l’onere della gestione di questi software complessi. A seguito di queste esigenze, nel 2017 abbiamo annunciato l’intenzione di rilasciare un servizio basato su Kubernetes.
Nel 2018 abbiamo rilasciato Amazon EKS (Amazon Elastic Kubernetes Service), un servizio gestito da AWS che garantisce piena compatibilità con Kubernetes “upstream”. Questo significa che quello che gestiamo per il cliente è il software standard Kubernetes (in gergo open source questo è definito “upstream”) e non una versione speciale modificata da AWS.
Sul cloud AWS oggi esistono due poli principali di servizi di orchestrazione container che attraggono diversi tipi di utenti con caratteristiche molto diverse. Intorno ad Amazon ECS gravitano tipicamente clienti che preferiscono la semplicità di utilizzo ed una esperienza nativamente integrata nel mondo AWS. Amazon EKS attrae invece una clientela che ha richieste peculiari, che preferisce la flessibilita’ alla semplicita’ e che vuole sfruttare il vasto ecosistema open source di Kubernetes.
Ma non ci siamo fermati qui. Nel corso degli anni abbiamo cercato di osservare e risolvere altri problemi che affliggevano i nostri clienti nell’uso dei container. Ad esempio, tradizionalmente, prima di poter lanciare un container, si doveva aver creato un cluster di istanze Amazon EC2 su cui l’orchestratore avrebbe successivamente avviato i container. Molti clienti ci hanno detto di dover investire molto tempo nello scalare e mettere in sicurezza queste infrastrutture. Per aiutarli in questi sforzi di velocità e di sicurezza, nel 2017 abbiamo introdotto un nuovo servizio chiamato AWS Fargate, un servizio serverless per lanciare container senza dover creare un cluster di istanze EC2. I clienti che usano Fargate possono concentrarsi sulla loro applicazione anziché investire tempo e soldi nel risolvere problemi infrastrutturali. Condè Nast, ad esempio, utilizza Fargate per supportare alcuni dei loro siti on-line, tra cui www.lacucinaitaliana.com e www.ad-italia.it. AWS Fargate è un servizio serverless indipendente dall’orchestratore e può lavorare sia con Amazon ECS che Amazon EKS. Per darvi un’idea di quanti clienti oggi stiano usando Fargate, considerate che, ogni settimana, vengono lanciati 100 milioni di task. Gia’ nel 2019, dopo soli due anni dal lancio, piu’ del 40% di clienti che usavano servizi containers in AWS avevano gia’ scelto Fargate.
Un aspetto molto importante e al cuore della nostra vision è la sicurezza. Per AWS la sicurezza è sempre stato l’aspetto più importante di tutti i propri servizi, inclusi quelli che ruotano intorno al mondo container. AWS Fargate è un esempio di dove AWS ha alzato la barra sulla sicurezza. Innanzitutto, istanziare la propria applicazione “containerizzata“ su Fargate significa associare ad ogni applicazione un kernel linux dedicato ovviando al potenziale problema del “container escape“, di fatto non permettendo in alcun modo ad un container di ”osservare“ altri container sullo stesso host.
In secondo luogo il cliente non è costretto a dover applicare patch di sicurezza all’infrastruttura dove girano i container perché, essendo un servizio gestito, questo aspetto ricade nei compiti di AWS nello spettro del cosiddetto shared responsibility model. Spesso i clienti ci dicono che i rilasci di container su Fargate sono considerati più sicuri di quelli che fanno su infrastrutture gestite da loro perché non hanno team dedicati 24/7/365 per mantenere l’infrastruttura container sicura.
La nostra ossessione sulla sicurezza non si limita a Fargate ovviamente. Oltre alle più consuete integrazioni di ECS ed EKS con AWS IAM (AWS Identity and Access Management), Amazon VPC (Amazon Virtual Private Cloud) ed altri servizi con forti connotazioni di sicurezza integrata, ci sono altri prodotti nel mondo dei servizi container nati specificatamente per aumentare la sicurezza delle comunicazioni tra applicazioni. In particolare mi riferisco ad AWS App Mesh. App Mesh si basa sul proxy open source Envoy, lavora con ECS ed EKS e garantisce funzionalità avanzate di connessione sicura tra container supportando, ad esempio, la mutual TLS authentication.
Nonostante i progressi che abbiamo fatto è sempre “il primo giorno”. Crediamo infatti ci sia ancora tanto da fare e i piani che abbiamo per risolvere i problemi dei nostri clienti sono ambiziosi.
Sarebbe utile sapere se Amazon fornisce dei corsi e delle certificazioni ufficiali per AWS. Grazie