Il futuro dell'infrastruttura sarà containerizzato

Sebbene la maggior parte delle aziende tecnologiche e delle startup oggi gestisca i propri sistemi nel cloud, molte non sono ancora in grado di comprenderne tutti i vantaggi. Se utilizzi il cloud, ma non usi Kubernetes, probabilmente stai sfruttando soluzioni di proprietà per creare e gestire strumenti personalizzati aggiuntivi. È probabile che tu abbia anche problemi in termini di efficienza, esecuzione dei carichi di lavoro su macchine virtuali (VM) sottoutilizzate ed esclusione da ciò che ti accade intorno. 

Quanti strumenti stai utilizzando attualmente per gestire e applicare patch alle tue VM? Come esegui l'upgrade delle applicazioni? Come utilizzi le VM? La tua situazioni attuale potrebbe non essere davvero efficace. È possibile che si verifichino inconvenienti (interruzioni, problemi di scalabilità e così via) per via delle lacune nell'architettura delle VM, che i costi siano eccessivi o che l'infrastruttura non sia configurata per supportare molti aspetti essenziali per la tua attività:

• Refactoring/riprogettazione dell'MVP in una soluzione scalabile
• Espansione su altri provider cloud per soddisfare le aspettative delle normative o dei clienti
• Espansione geografica per ridurre la latenza e fornire esperienze migliori a una base clienti ampia
• Miglioramento della strategia di sicurezza end-to-end
• Miglioramento la customer experience (ad es. disponibilità dei servizi)

Il debito tecnico e legacy può rallentarti. Ecco perché stiamo assistendo a questo grande passaggio a Kubernetes. Si tratta di un'architettura moderna composta da container gestiti che ti permette di sfruttare pattern comprovati per gestire un'infrastruttura affidabile e sicura. Puoi velocizzare il time to market e aumentare la produttività senza sacrificare la stabilità e la sicurezza, con il vantaggio aggiuntivo di attirare i migliori talenti tecnici per promuovere l'innovazione.

Dovresti anche preoccuparti della possibile esclusione dalla community Kubernetes e dal rispettivo ecosistema, la cui innovazione costante definisce le best practice e gli standard odierni. In ultima analisi, e questo è ancora più importante date le attuali difficoltà in termini di assunzione del personale, devi decidere in quali campi vuoi che i tecnici dedichino il loro tempo: la manutenzione dell'infrastruttura e la gestione di strumenti personalizzati oppure attività prioritarie per far progredire la tua attività. La situazione in cui trovi oggi potrebbe funzionare, ma la tua roadmap include probabilmente aspetti che vorresti migliorare, ad esempio risolvere il debito tecnico e colmare le lacune della piattaforma sulla base di:

• Crittografia end-to-end
• Osservabilità (log, metriche, logging automatico)
• Gestione e applicazione dei criteri
• Alta disponibilità e failover automatico
• Riduzione dei costi

Kubernetes è una soluzione open source e indipendente dalla piattaforma. Offre tutti gli strumenti più comuni e pronti all'uso per proteggere e accelerare ogni fase del ciclo di vita di creazione e deployment. È la somma di tutti gli script bash e di tutte le best practice che la maggior parte degli amministratori di sistema accumula nel corso del tempo, il tutto all'interno di un unico sistema basato su un set dichiarativo di API. Tutto è automatizzato, i dettagli sono nascosti ed è un sistema che può essere utilizzato subito. Kubernetes può eliminare la maggior parte dell'infrastruttura basata su codice e facilitare il passaggio della piattaforma a un'infrastruttura basata su dati. Non devi scrivere o gestire il codice: basta indicare a Kubernetes cosa vuoi, non cosa fare. Ciò garantisce un enorme risparmio di tempo per quel che riguarda l'overhead di gestione. 

Se vuoi eseguire carichi di lavoro tradizionali, puoi farlo su una piattaforma moderna con Kubernetes separando le app dalle VM e inserendole nei container. L'adozione di immagini di container per pacchettizzare il software semplificherà gli upgrade delle VM. Ora puoi svincolare la gestione del ciclo di vita della VM da quella del ciclo di vita dell'applicazione, il che semplifica la VM mediante la rimozione del codice Ruby, Python e Java. Inoltre, spostandola nel punto più adatto (accanto all'applicazione dello sviluppatore), puoi controllarne centralmente tutti gli aspetti in modo che sia di tipo bare metal.

Le piattaforme di computing gestito trasformano i servizi cloud in piattaforme basate su servizi (Platform as a Service), il che ti permette di avere la potenza e la flessibilità dei container, nonché la comodità delle funzionalità serverless. Non sono previsti server, configurazioni dei cluster e attività manutenzione, il che porta enormi vantaggi e ti consente di mantenere tutto sotto controllo.

Per i carichi di lavoro che non richiedono un controllo eccessivo in termini di configurazione del cluster, puoi permettere ai servizi di eseguire il provisioning e gestire l'infrastruttura sottostante del cluster, inclusi i nodi e i pool di nodi, pagando solo il carico di lavoro, non il cluster. In questo modo puoi eliminare le operazioni di amministrazione dei cluster, ottimizzando al contempo la sicurezza e risparmiando potenzialmente molto denaro.

Nel caso delle applicazioni maggiormente cloud-native, la funzionalità serverless svolge le stesse operazioni con meno lavoro, poiché elimina l'infrastruttura sottostante e funge da host end-to-end per le applicazioni, i dati e persino l'analisi. Una piattaforma serverless ti consentirà di iniziare a eseguire i container in un ambiente completamente gestito con pochissimi problemi di complessità e sicurezza, garantendo contemporaneamente prestazioni, scalabilità e best practice integrate.

Diamo un'occhiata alle possibili implicazioni per la tua attività e come garantire che la tua organizzazione sia sempre un passo avanti.

Alcune attività devono operare in più cloud. La gravità dei dati è reale e, se hai una base clienti globale, ti ritroverai inevitabilmente a dover offrire tempi di latenza minimi e tariffe di networking ridotte, mantenendo le risorse di computing vicino a dove si trovano effettivamente i dati.

In questi casi, il multi-cloud può espandere il mercato che puoi raggiungere. Ti troveresti comunque a dover supportare servizi gestiti e dati su altri provider. Altre aziende considerano il multi-cloud ottimo come strategia di mitigazione dei rischi. In entrambi i casi, è fondamentale adottare il multi-cloud in modo corretto, perciò le soluzioni standard del settore possono essere utili.

Per prima cosa, assicurati di sfruttare al meglio il maggior numero di flussi di lavoro per svolgere le tue attività nel modo più efficiente possibile. Per flussi di lavoro intendiamo abilitare l'automazione delle attività per creare l'architettura del flusso dei dati tra database e risorse di computing. È qui che l'open source è importante: se selezioni un database non aperto, avrai difficoltà a implementare l'architettura del flusso di dati e l'automazione. Ti conviene scegliere una soluzione come il protocollo Postgres (ad es.Cloud Spanner) o un database Postgres gestito (ad es. Cloud SQL) su qualsiasi provider cloud. 

Per quanto riguarda l'aspetto del computing, Kubernetes fa risparmiare molto tempo su in termini di deployment e automazione perciò, quando scegli un insieme di tecnologie, assicurati che funzionino entro tutti i limiti stabiliti dal tuo provider. I confini potrebbero essere aree geografiche o zone diverse, progetti o account diversi e persino risorse on-premise o su cloud. Non sprecare tempo a creare e gestire infrastrutture separate per ogni provider cloud (ad esempio una su AWS, una su Google e una su Azure). I tecnici potrebbero impazzire nel tentativo di gestirli tutti in modo ottimale. Se crei ed esegui il deployment una sola volta su più cloud, puoi eseguire gli aggiornamenti in modo centralizzato e uniforme. Gli stack di computing come Kubernetes offrono un enorme vantaggio ai clienti che intendono davvero passare al multi-cloud. È efficace e non richiede di ricominciare sempre daccapo ogni volta che occorre utilizzare un nuovo cloud provider.

Poi dobbiamo considerare la gestione dei rischi. Avere la possibilità di eseguire lo stack in un altro ambiente contribuirà a ridurre il rischio che il provider cloud subisca interruzioni o inizi a competere con la tua attività. Al fine di rispettare le normative, le organizzazioni sceglieranno i provider in grado di garantire la continuità aziendale. Ad esempio, se le operazioni vengono interrotte in un'area geografica, un provider di backup ti permetterà di non avere tempi di inattività.

Le migrazioni multi-cloud che di solito funzionano meglio sono quelle che sfruttano gli standard aperti. Prendiamo ad esempio Kubernetes, che offre un'API indipendente dal provider per l'esecuzione, la configurazione e il deployment delle applicazioni, nonché per l'integrazione di aspetti come criteri di sicurezza, networking e altro ancora. Kubernetes è in pratica un sistema operativo multi-cloud: se utilizzato come livello di astrazione, di solito puoi nascondere le differenze tra la maggior parte dei principali provider cloud.

Se decidi di utilizzare Kubernetes, puoi scegliere varie opzioni. Puoi eseguirlo in modo autonomo, ovviamente. Kubernetes è un progetto open source, perciò puoi scaricarlo e dedicare anni a integrarlo nel provider cloud o nell'ambiente che preferisci.

Se, invece, decidi che questo uso ti farebbe perdere tempo, puoi utilizzare un'offerta Kubernetes gestita. Se utilizzi AWS, la soluzione da usare è EKS. Se utilizzi Azure, scegli AKS. Se utilizzi Google Cloud, implementa Google Kubernetes Engine (GKE). Tutte queste opzioni ti forniranno un'API Kubernetes comune in modo che, quando il tuo team crea strumenti e flussi di lavoro personalizzati, potrai riutilizzarli in vari provider.

Tuttavia, non tutte le offerte di servizi gestiti sono uguali. Il rendimento di Kubernetes dipende dall'infrastruttura su cui viene eseguito e GKE colma le lacune come servizio di orchestrazione Kubernetes completamente gestito. Offre un'infrastruttura IaaS completamente integrata che spazia dal provisioning delle VM delle Tau VM, con un rapporto prezzo/prestazioni migliore del 42% rispetto a offerte simili per uso generico¹, alla scalabilità automatica in più zone e agli upgrade, il tutto al fine di creare e gestire GPU, TPU per machine learning, volumi di archiviazione e credenziali di sicurezza on demand. Non devi fare altro che inserire la tua applicazione in un container e scegliere un sistema in base alle tue esigenze.

Cosa succede se hai scelto AWS come provider cloud per le VM? Devi continuare a utilizzare EKS? A livello generale, Kubernetes è uguale per tutti i provider cloud. Userai l'API Kubernetes. Ma alla base di questa API ci sono un cluster, nodi worker e criteri di sicurezza; insomma, un sistema davvero completo, che poi è il punto di forza di GKE.

Ad esempio, se hai ancora bisogno di altri cluster, puoi connetterli a GKE Connect, che fungerà da punto centralizzato dove gestirli, visualizzarli, risolverne i problemi ed eseguirne il debug, avendo al contempo un controllo centrale su elementi come le credenziali. GKE è l'opzione Kubernetes migliore perché offre ottime funzionalità di gestione end-to-end, non solo per il suo control plane o per la disponibilità elevata che offre in più aree geografiche o zone. GKE può anche sfruttare i bilanciatori del carico globali utilizzando il servizio Ingress multi-cluster centralizzato per più cluster e aree geografiche.

E se volessi utilizzare l'API Kubernetes, ma non avere la responsabilità del provisioning, della scalabilità e dell'upgrade dei cluster? Per la maggior parte dei carichi di lavoro, GKE Autopilot nasconde l'infrastruttura sottostante del cluster, inclusi i nodi e i pool di nodi. Pagherai solo il carico di lavoro. GKE Autopilot ti offre un'API Kubernetes standard con tutte le solide impostazioni predefinite di sicurezza, in modo che tu possa concentrarti sui carichi di lavoro e non sul cluster.

__________________________

¹ I risultati si basano sulla stima di SPECrate®2017_int_base eseguita su VM di produzione di altri due principali fornitori di servizi cloud e sulle Tau VM di Google Cloud pre-produzione mediante compilatori consigliati dal fornitore. SPECrate è un marchio di Standard Performance Evaluation Corporation. Ulteriori informazioni disponibili all'indirizzo www.spec.org.

Kubernetes ha permesso alle organizzazioni di passare dalle VM a nuove astrazioni che consentono di automatizzare le operazioni e di concentrarsi sulle applicazioni. Nel caso di carichi di lavoro più specifici (ad es. app web e per dispositivi mobili, backend di API REST, trattamento dati e automazione dei flussi di lavoro), puoi semplificare ulteriormente e ottimizzare il deployment sfruttando il modello serverless.

È possibile che tu stia utilizzando AWS Lambda, una piattaforma serverless molto diffusa che consente di scrivere modelli Functions as a Service e di collegarli a tutti i tipi di eventi. Poiché alla fine devi comunque connetterti a un database e gestire i problemi di sicurezza, queste funzioni tendono a diventare più complesse, in alcuni casi anche più grandi rispetto alle normali applicazioni. Cosa succede se hai un'applicazione che non sfrutta più la semplicità offerta dal modello Functions as a Service oppure un'applicazione esistente che vuoi eseguire in modalità serverless?

A differenza di una piattaforma serverless tradizionale che prevede la riscrittura delle applicazioni, Cloud Run offre un approccio che ti consente di riutilizzare gli investimenti esistenti per applicazioni containerizzate. Sebbene GKE sia un servizio gestito, devi comunque prendere alcune decisioni chiave: quali sono le zone di esecuzione, dove archiviare i log, come gestire il traffico tra le diverse versioni delle applicazioni, quali sono i nomi di dominio registrati e come gestire i certificati SSL.

Cloud Run elimina tutte queste decisioni: puoi eseguire carichi di lavoro più tradizionali e non devi eseguire avvii completi disabilitando del tutto la scalabilità fino a zero. Cloud Run supporta anche l'esecuzione continua della applicazioni, oltre ad altri requisiti tradizionali come NFS, WebSocket e integrazioni VPC. Tuttavia, come per la maggior parte delle piattaforme serverless tradizionali, Cloud Run è una soluzione "guidata" e offre funzionalità come gestione del traffico e scalabilità automatica integrate.

Supponi di non utilizzare affatto i container e che non sai da dove iniziare. Ecco l'approccio pragmatico per implementare la containerizzazione.

Il primo motivo per adottare i container è risolvere il problema della pacchettizzazione. Oggi si lavora molto sulla produzione di artefatti riproducibili e sulla comprensione dei vari elementi che compongono il software. È quella che nel nostro settore è chiamata "protezione della catena di fornitura del software". Crediamo che il modo migliore per farlo sia sfruttare le immagini container che ospitano il codice dell'applicazione, i runtime e le dipendenze. Uno dei vantaggi dei container è che è possibile eseguirne il deployment nelle VM, il che riduce la complessità del deployment e della gestione del software su tutte le tue macchine.

Il secondo motivo per l'adozione dei container è l'orchestrazione. La gestione delle VM comporta un notevole sovraccarico di gestione e manutenzione. Nella maggior parte delle aziende, il team esegue decine o centinaia di passaggi per gestire la tua infrastruttura e, anche se sono automatizzati, gli strumenti di automazione richiedono comunque una manutenzione costante. E questo presupponendo che tu stia utilizzando strumenti di automazione standard di settore come Terraform, Puppet, Chef e Ansible. L'overhead per la manutenzione è ancora peggiore per strumenti nativi o personalizzati.

Il terzo motivo per adottare i container è l'efficienza. Oltre all'onere della manutenzione, la maggior parte delle organizzazioni ha raggiunto un utilizzo della CPU pari solo al 5%-10%, per non parlare di memoria e archiviazione. Si tratta di una grande perdita di risorse. Molti team stanno creando strumenti ancora più personalizzati per colmare questa lacuna implementando aspetti come la scalabilità automatica e il bin packing, il che porta a un ulteriore spreco di tempo operativo. Ciò causa spese eccessive e una fatturazione Cloud sorprendentemente alta.

Pochissime organizzazioni sono in grado di creare con successo la propria piattaforma di orchestrazione. È per questo che sfruttare una piattaforma open source come Kubernetes, Mesos o Nomad è una scelta molto comune. Tuttavia, se cerchi una piattaforma che ti consenta di ottenere vantaggi come manutenzione ridotta, best practice standard di settore e integrazione completa con il tuo provider cloud, dovrai scegliere un servizio gestito come GKE per massimizzare il valore potenziale dei container.

Ti potresti chiedere se la migrazione ai container in realtà non porti a tempi di inattività lunghi senza ottenere in cambio alcun valore. Ovviamente, non vuoi sospendere le tue attività per lo sviluppo futuro, giusto?

Per rispondere a questa domanda, vediamo come utilizzare al meglio la tua esperienza cloud fino a oggi.

La migrazione delle applicazioni dalle VM ai container può sembrare complicata, specialmente se si tratta di spostare tutte le risorse di computing in un nuovo provider cloud. In realtà non devi necessariamente eseguire tutto in un'unica operazione: puoi farlo un'applicazione alla volta, partendo dalle VM e spostando una o due applicazioni su Kubernetes, dove possono trovarsi affiancate sulla stessa rete e comunicare con le VM. Non è necessario effettuare una transizione definitiva: puoi passare lentamente da una piattaforma all'altra.

Rimanere sulle VM può essere utile per alcune app, come database di grandi dimensioni e pesanti che hanno pochi vantaggi da Kubernetes. Non c'è problema: va bene combinare i vari elementi. Tuttavia, abbiamo notato che la maggior parte dei clienti ha ottenuto ottimi risultati dallo spostamento delle applicazioni e dei progetti open source nell'ambiente Kubernetes. Dai la priorità alle applicazioni che generano il massimo ritorno passando a GKE. Non devi per forza spostare tutto contemporaneamente.

Kubernetes viene comunque eseguito sulle stesse VM Linux che potresti utilizzare attualmente. Il vero vantaggio è che il flusso di lavoro sarà più fluido e coerente, incorporando molti elementi che dovrebbero essere presenti nella tua roadmap dell'infrastruttura, piuttosto che una semplice raccolta di script proprietari e dell'automazione. Anche l'integrazione di nuovi membri del team diventa molto più semplice se utilizzi uno strumento standard di settore come Kubernetes, dato che non dovrai insegnare loro tutti i modi personalizzati che vengono utilizzati nella tua azienda.

A questo punto, hai un percorso ben definito per adottare i container lentamente, ma in modo pragmatico, in modo che il tuo team possa risparmiare tempo in termini di sovraccarico delle attività di amministrazione e la tua azienda possa ridurre i costi di computing.

Abbiamo parlato molto di container e migrazioni al cloud, sia se ti affidi completamente a Kubernetes e stai cercando un'offerta migliore oppure se ti interessa un approccio diverso che si adatti alle tue applicazioni e alle tue roadmap esistenti.

Qualunque sia il tuo percorso per lo sviluppo di app, l'opzione dei container gestiti riduce al minimo i costi dell'infrastruttura e massimizza al contempo la capacità del tuo team di concentrarsi sulla creazione di prodotti di qualità. Il futuro dell'infrastruttura è la containerizzazione. Ora devi fare in modo che la tua azienda e i tuoi tecnici possano raggiungere i migliori risultati possibili. 

Kubernetes to Cloud Native: Jumpstart your journey developing on GKE

Containers in Cloud - A better way to develop and deploy applications

The past, present, and future of Kubernetes with Eric Brewer

Re-architecting to cloud native: an evolutionary approach to increasing developer productivity at scale