Cos'è il cloud native?

Cosa significa cloud native?

Cloud native è un approccio allo sviluppo software che combina container, microservizi e orchestrazione con processi DevOps per creare, distribuire e gestire applicazioni progettate per sfruttare al meglio gli ambienti cloud. Le applicazioni cloud native nascono per essere scalabili, resilienti e portabili tra cloud pubblici, privati e ambienti ibridi.

Quali sono le caratteristiche del cloud native?

1. Il codice è impacchettato in container
2. La sua architettura è costituita da più microservizi
3. Gli sviluppatori e i team addetti alle operazioni IT lavorano fianco a fianco in una struttura agile e perfettamente integrata
4. Le applicazioni sono distribuite e gestite attraverso un'infrastruttura cloud elastica
5. L'allocazione delle risorse dell'infrastruttura avviene automaticamente in base alle policy stabilite

Quali sono i vantaggi dello sviluppo di applicazioni cloud native?

Il cloud native offre una serie di vantaggi che lo rendono una soluzione ideale per le organizzazioni moderne.

Sviluppo di applicazioni più rapido e maggiore agilità aziendale

Le organizzazioni che intraprendono un percorso cloud native adottano i container, Kubernetes, e un insieme di tecnologie open source e commerciali che fanno parte di un ampio ecosistema cloud native.

I container e le tecnologie cloud native consentono alle organizzazioni di accelerare lo sviluppo delle applicazioni, aggiornarle senza disservizi, scalarle in maniera efficiente e trasferirle facilmente da un ambiente all'altro. In ultima analisi, queste opportunità garantiscono una migliore agilità aziendale e offrono un vantaggio competitivo.

Risoluzione di problemi aziendali critici con i container cloud native

I container risolvono alcuni problemi critici per le imprese: oltre alla possibilità di eseguire ovunque le proprie applicazioni, offrono anche pacchetti software affidabili per gli sviluppatori, aggiornamenti di servizio, scalabilità, disponibilità ed efficienza delle risorse, tutto in un'unica soluzione indipendente dai vendor. Kubernetes aggiunge a questo modello un layer di orchestrazione che il reparto IT può gestire in modo programmatico e ripetibile su vasta scala, automatizzando deployment, scaling e gestione del ciclo di vita dei container in ambienti enterprise.  

Gestione efficiente dell'infrastruttura con Kubernetes

Kubernetes può inoltre essere implementato sia on-premise che sul cloud pubblico, mettendo così a disposizione un modello operativo comune a tutti gli ambienti. Queste caratteristiche lo rendono dunque una piattaforma ideale per le aziende che operano in entrambi gli ambienti.

Architettura cloud native

L'architettura cloud native sfrutta i container e Kubernetes per creare applicazioni costituite da microservizi più piccoli e componibili, in grado di assicurare piena scalabilità, aggiornamenti senza disservizi e portabilità tra ambienti diversi, rendendola ideale per lo sviluppo e l'implementazione di applicazioni cloud native. Si tratta di un'architettura economicamente efficiente, caratterizzata da maggiore sicurezza e automazione flessibile.

Tecnologie chiave del cloud native

Kubernetes

Kubernetes è una piattaforma di orchestrazione di container cloud native  sempre più utilizzata dalle aziende, sia on-premises che nel cloud.

Vedremo ora in dettaglio i vari layer dello stack Kubernetes on-premise, dall'infrastruttura su cui funziona ai servizi che vi vengono eseguiti e che gli sviluppatori possono sfruttare per accelerare la delivery delle applicazioni. Alcuni componenti possono essere inclusi in più aree dello stack: una distribuzione Kubernetes può includere per esempio un registro dei container (come per es. Harbor o Quay), che in alternativa può essere offerto come servizio ospitato o gestito da utilizzare con qualsiasi distribuzione.

Grazie all'innovazione continua che lo caratterizza, Kubernetes può essere implementato negli ambienti più diversi, e le opzioni per come e dove utilizzarlo sono sempre più numerose. In genere Kubernetes richiede un minimo di 3 nodi con connettività di rete completa tra i nodi stessi e lo storage collegato. Oggi Kubernetes è più comunemente eseguito su infrastrutture virtuali come VMware. Altre due scelte molto diffuse sono l'implementazione su bare metal e sull'HCI.

Esistono funzionalità aggiuntive che possono semplificare notevolmente il provisioning e la gestione di un cluster Kubernetes. Un'infrastruttura controllata tramite un'API (per es. Cluster API, Terraform, ecc.) facilita il provisioning e la connessione di nuovi nodi. Gli hypervisor personalizzati possono offrire l'isolamento del carico di lavoro per rafforzare la sicurezza  nei container. Un bilanciatore del carico al di fuori del cluster Kubernetes è utile per rendere disponibili i carichi di lavoro, trasferirli e scalarli in maniera dinamica. Alcuni carichi di lavoro, in particolare quelli di AI e machine learning  possono beneficiare di hardware dedicato, come GPU o TPU. Se occorre poi gestire numerosi cluster in più ubicazioni diverse (come per esempio nel caso di punti vendita che appartengono a una catena), può essere utile una funzionalità di gestione distribuita per l'infrastruttura sottostante.

Servizi infrastrutturali e applicativi su Kubernetes

Per essere utile, un ambiente Kubernetes richiede ulteriori servizi infrastrutturali oltre a Kubernetes stesso. Talvolta questi vengono forniti insieme alle distribuzioni o aggiunti come servizi separati, e includono alcune funzionalità di base quali un registro dei container, un Ingress, un bilanciatore del carico, degli archivi Secrets o un gestore di certificati, giusto per citarne alcune.

Sempre più aziende creano e implementano applicazioni su Kubernetes: di conseguenza, in genere molti dei servizi di base da cui dipendono sono anch'essi eseguiti su Kubernetes. Tra questi ricordiamo i database (per es. Redis, Postgres), i servizi Pub/Sub (Kafka), l'indicizzazione (ElasticSearch), i servizi CI/CD (Gitlab, Jenkins) e le piattaforme di storage (Portworx, MayaData, Minio, Red Hat).

Molte aziende hanno sviluppato offerte che gestiscono o supportano queste applicazioni cloud native sulla distribuzione Kubernetes prescelta dal cliente. L'esempio più noto è forse quello dei servizi dati di Microsoft Azure Arc, che offrono Postgres e MS SQL come servizi gestiti negli ambienti dei clienti, ma ne esistono anche molti altri, come Confluent per Kafka, Crunchy Data per Postgres, Redis Enterprise per Redis, Percona, ElasticSearch, Minio, Mayadata, ecc.

Container

I container sono il nucleo di base del software cloud native. Un container comprende una porzione di codice impacchettata con tutte le sue dipendenze (file binari, librerie, ecc.) che viene eseguita come processo isolato. Questo si traduce in un nuovo livello di astrazione: allo stesso modo in cui una macchina virtuale (VM) astrae le risorse computazionali dall'hardware sottostante, così un container astrae un'applicazione dal sistema operativo (OS) sottostante.

I container differiscono dalle VM sotto alcuni importanti aspetti: presentano infatti un footprint notevolmente ridotto in fatto di risorse, si possono creare più rapidamente, e sono più facili da trasferire da un ambiente cloud all'altro. A differenza delle VM, i container sono per natura effimeri.

I container spianano la strada all'architettura software dei microservizi. Mentre le applicazioni legacy sono per loro natura monolitiche, quelle basate su microservizi sono costituite da insiemi di componenti (servizi) più piccoli e componibili, in grado di scalare in maniera indipendente ed essere aggiornati senza provocare disservizi. Un servizio è composto da uno o più container che eseguono una funzione comune.

Le applicazioni containerizzate e basate su microservizi semplificano e accelerano le pratiche di sviluppo software basate su maggiore integrazione e coordinazione tra sviluppatori e team addetti alle operazioni IT (DevOps).

Cloud native e cloud enabled: qual è la differenza?

A volte i termini “cloud native” e “cloud enabled” vengono erroneamente utilizzati in modo intercambiabile, quando in realtà rappresentano due concetti molto diversi.

Cloud enabled significa tipicamente modificato o adattato per funzionare nel cloud. Ad esempio, le applicazioni cloud enabled sono applicazioni che in origine risiedevano on-premises, ma che sono state successivamente riarchitettate o ricostruite per una piattaforma cloud. La riarchitettura può richiedere molto lavoro e far funzionare un’applicazione on-premises nel cloud comporterà probabilmente alcune sfide. Quantomeno, un’applicazione riarchitettata non offrirà l’agilità e la flessibilità intrinseche delle applicazioni cloud native.

Sebbene le applicazioni cloud enabled utilizzino una varietà di servizi cloud, in genere dipendono ancora da parte dell’infrastruttura on-premises per funzionare nel cloud.

Alcune delle principali differenze tra applicazioni cloud enabled e cloud native includono:

• Progettazione originale: le applicazioni cloud native sono sviluppate pensando ai servizi e alle tecnologie cloud, mentre le applicazioni cloud enabled devono essere adattate per operare nel cloud;

• Architettura: un’architettura distribuita che utilizza microservizi è comune nelle applicazioni cloud native; le applicazioni cloud enabled sono costruite utilizzando un’architettura più tradizionale;

• Utilizzo delle risorse: l’ottimizzazione dell’uso delle risorse è parte integrante delle applicazioni cloud native, consentendo scalabilità dinamica e un elevato grado di flessibilità. Le applicazioni cloud enabled non sono progettate per sfruttare le funzionalità di ottimizzazione delle risorse del cloud;

• Resilienza: essere cloud native significa sfruttare capacità di affidabilità come ridondanza integrata e failover automatico. Le applicazioni cloud enabled in genere non includono queste funzionalità, a meno che non vengano integrate intenzionalmente durante la fase di riarchitettura.

Passare alle tecnologie cloud native: le sfide

Le tecnologie cloud native sono il nuovo punto di riferimento in fatto di agilità aziendale e innovazione, ma la loro configurazione, implementazione e gestione possono mettere a dura prova qualsiasi impresa.

• Velocità di evoluzione della tecnologia cloud native: prima di tutto, Kubernetes e il suo ecosistema di tecnologie cloud native costituiscono un panorama sconfinato e in rapida evoluzione;

• Incompatibilità dell'infrastruttura legacy: inoltre, le infrastrutture legacy non sono dotate di un'architettura adeguata al modo in cui Kubernetes e i container utilizzano le risorse IT: un ostacolo significativo per gli sviluppatori di software, che per le loro applicazioni cloud native hanno spesso bisogno di risorse on-demand e servizi facili da usare;

• Gestire in modo efficace tutte le distribuzioni: infine, ogni organizzazione finisce per impiegare un mix di ambienti Kubernetes on-premise e basati su cloud pubblico, ma i vantaggi della flessibilità multicloud dipendono dalla capacità di gestire e monitorare efficacemente tutte le implementazioni.

Best practice per l'utilizzo di tecnologie cloud native

Per i team addetti alle operazioni IT, creare uno stack Kubernetes di livello enterprise all'interno del datacenter non è un'impresa da poco. È infatti fondamentale eseguire Kubernetes e le applicazioni containerizzate su un'infrastruttura che sia resiliente e in grado di scalare reattivamente per supportare un sistema distribuito dinamico.

L'infrastruttura iperconvergente (HCI) di Nutanix è l'ideale per i carichi di lavoro cloud native eseguiti su Kubernetes su larga scala, poiché offre una maggiore resilienza sia per i componenti della piattaforma Kubernetes che per i dati delle applicazioni, con una scalabilità superiore rispetto all'infrastruttura bare metal. Nutanix semplifica inoltre la gestione del ciclo di vita dell'infrastruttura e lo storage persistente per i container stateful, eliminando alcuni dei problemi più complessi che le organizzazioni devono affrontare nell'implementazione e nella gestione delle infrastrutture cloud native.