Cos'è il cloud native?
Cosa significa essere cloud-nativi?
Cloud nativo indica un nuovo grado di astrazione software in congiunzione con un insieme di tecnologie, strumenti e processi specifici che rivoluzionano le modalità di creazione, implementazione e gestione delle applicazioni.
Quali sono le caratteristiche del cloud nativo?
- Il codice è impacchettato in container
- La sua architettura è costituita da più microservizi
- Gli sviluppatori e i team addetti alle operazioni IT lavorano fianco a fianco in una struttura agile e perfettamente integrata
- Le applicazioni sono distribuite e gestite attraverso un'infrastruttura cloud elastica
- L'allocazione delle risorse dell'infrastruttura avviene automaticamente in base alle policy stabilite
Quali sono i vantaggi dello sviluppo di applicazioni native per il cloud?
Il cloud nativo 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-nativo adottano i container, Kubernetes, e un insieme di tecnologie open source e commerciali che fanno parte di un ampio ecosistema cloud-nativo.
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 problemi aziendali critici con i contenitori cloud nativi
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. In contrapposizione alla gestione più diretta tipica del settore enterprise, Kubernetes offre un layer infrastrutturale che il reparto IT può gestire in modo programmatico e ripetibile su vasta scala.
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-nativa
L'architettura cloud-nativa sfrutta i container e Kubernetes per creare applicazioni costituite da elementi più piccoli e componibili in grado di assicurare una piena scalabilità, aggiornamenti senza disservizi, e la possibilità di migrare agevolmente in altri ambienti e rendendola ideale per l’implementazione di applicazioni cloud native. Si tratta di una tecnologia economicamente conveniente, caratterizzata da maggiore sicurezza e automazione flessibile.
Tecnologie chiave del cloud nativo
Kubernetes
Kubernetes è una piattaforma di orchestrazione dei contenitori nativi del cloud sempre più utilizzata dalle aziende, sia on premise 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 colmare le falle di 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 possono beneficiare di hardware personalizzato, 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.
Microservizi
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 gestiranno o supporteranno 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-nativo. 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 o basate su microservizi semplificano e accelerano le pratiche di sviluppo software che richiedono 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’app 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 app 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 può mettere a dura prova qualsiasi tipo di impresa.
Velocità di evoluzione della tecnologia cloud nativa – 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 possiedono un'architettura adeguata per l'utilizzo che Kubernetes e i container fanno delle 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-nativi 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.
