Nello scorso Pod, abbiamo approfondito le tematiche relative al Cloud Journey, evidenziando come qualsiasi workload si può collocare all’interno di un’infrastruttura cloud, tuttavia i benefici che ne derivano dipendono da molteplici fattori, legati soprattutto alla modalità con cui lo si utilizza e cosa si implementa all’interno del cloud.
Quello che emerge dalle nostre esperienze è che risulta molto complicato adattare il cloud a un workload (un’applicazione), mentre è assai più semplice e profittevole adattare il workload al cloud.
Partendo da questo presupposto, è stato sviluppato un approccio alla progettazione, alla costruzione e alla compilazione di carichi di lavoro operativi nel cloud, basato sul modello cloud computing. Questo approccio è identificato nel termine “Cloud Native”.
Tutti i sistemi nativi del cloud sono specificatamente pensati per massimizzare l’efficienza, la velocità e la flessibilità del cloud computing, con l’obiettivo di garantire alle aziende la possibilità di creare ed eseguire applicazioni scalabili in ambienti moderni e dinamici, come ad esempio cloud pubblici, privati e ibridi.
Scopriamo in questo articolo i soggetti che hanno contribuito a sviluppare e diffondere l’approccio Cloud Native, le architetture e le tecnologie principali che si sono affermate, fino alle pratiche DevOps: che cosa sono e qual è il loro legame con il mondo Cloud Native?
Cloud Native: i maggiori player
I cloud provider – e in particolare gli hyperscaler AWS, Google e Microsoft – giocano sicuramente un ruolo determinante da un punto di vista tecnologico, così come altri soggetti quali IBM, RedHat e Docker. Ma il Cloud Native ha soprattutto una marcata connotazione comunitaria e forti radici nell’open-source.
L’ente più autorevole è senz’altro la Cloud Native Computing Foundation (CNCF), una società no-profit costituita nel 2015 con la missione di promuovere il paradigma del cloud, sostenendo una serie di progetti vendor neutral e open-source.
La comunità CNCF conta oltre 7 milioni di sviluppatori Cloud Native, cui 220.000 circa impegnati come contributori fattivi nello sviluppo dei progetti accreditati. L’elenco dei membri della fondazione, che la sostengono e la governano, conta più di 800 entità, annoverando “tutti” i principali attori dell’IT e dell’high tech, tra cui i fondatori Google, CoreOS, Mesosphere, Red Hat, Twitter, Huawei, Intel, Cisco, IBM, Docker, Univa e VMware.
La Cloud Native Computing Foundation è un vero e proprio “incubatore” che ha patrocinato numerosi progetti (oggi sono più di 170), tutti ben catalogati, categorizzati e descritti nel CNCF Landscape. Tra questi, il sistema Kubernetes è l’indiscussa pietra miliare del cloud native, nell’orbita del quale gravitano gran parte degli altri progetti CNCF.
Uno dei compiti più importanti di CNCF, data la dimensione della comunità e la numerosità dei progetti, è stato e rimane quello di regolamentare il settore e “standardizzare” ove possibile.
Inoltre, CNCF pubblica interessanti analisi sul Cloud Native, tra le quali l’Annual Survey e il CNCF Annual Report, che forniscono una panoramica generale del settore e una buona prospettiva delle ultime tendenze tecnologiche.
Architetture Cloud Native: microservizi e “Serverless”
L’approfondimento delle architetture in un contesto Cloud Native richiede l’introduzione del concetto di “Microservizi”. Sebbene per descrivere dettagliatamente quest’architettura servirebbe un vero e proprio trattato, possiamo affermare che le nozioni principali su cui fonda la sua struttura sono relativamente semplici.
Partiamo dal seguente diagramma, che mostra la struttura di un’applicazione nelle due forme Monolitica e a Microservizi.
L’applicazione nel suo insieme viene sezionata in singole funzioni (o servizi) dove ognuna di queste diventa una parte più piccola, il microservizio appunto.
Il microservizio esegue un processo applicativo che svolge autonomamente solo i suoi compiti predefiniti (solo quelli) e che inter-opera con gli altri processi attraverso interfacce di comunicazione standard nativamente codificate nell’applicazione, cioè le Application Programming Interface (API).
Ne derivano una serie di caratteristiche peculiari in grado di portare consistenti benefici.
Il microservizio può essere sviluppato, distribuito, eseguito e ridimensionato autonomamente, senza influenzare il funzionamento degli altri componenti. Non condivide codice, moduli, librerie: è indipendente.
Inoltre, è progettato per svolgere un compito o per risolvere una necessità specifica ed è specializzato per farlo al meglio. Ne conseguono una serie di caratteristiche architetturali implicite come scalabilità e resilienza.
Infine, è molto rapido, “snello” e facilmente trasportabile da un ambiente ad un altro, pertanto la sua gestione risulta molto semplice.
Quello che perciò avviene nelle organizzazioni è che anche i teams di sviluppo si dividono gli specifici compiti. Si spartiscono i microservizi tra loro, ne prendono la ownership e conseguentemente si focalizzano e si specializzano sul loro specifico ambito funzionale.
Ci sono però aspetti meno positivi, soprattutto derivati dalla numerosità (un monolite si “moltiplica” in più “microservizi”) che aggiungono una fisiologica complessità dell’ambiente, con il rischio di perderne il controllo.
E qui ci viene in aiuto la tecnologia, consentendoci di affrontare e risolvere questo delicato problema. Il microservizio viene generalmente assimilato al container e nel linguaggio informatico comune i due termini sono pressochè intercambiabili.
I Microservizi sono quindi la bandiera della modernizzazione applicativa, dominano e pervadono il settore del Cloud Native sotto ogni prospettiva.
C’è però un’altra architettura, forse ancor più emblematica del paradigma, che ha ormai superato la fase pionieristica ed è entrata a pieno titolo nel mainstream Cloud Native: il Serverless.
In estrema sintesi, il concetto di Serverless prevede di eseguire dei workload senza doversi preoccupare del sistema computazionale sottostante e quindi dell’ambiente di runtime.
In sostanza, ci si può disinteressare di tutti gli aspetti legati al deploy, alla configurazione, alla gestione, al dimensionamento, alla capacità e alla disponibilità dei suddetti sistemi. Un servizio Serverless può eseguire una sequenza di istruzioni con una serie di dati da elaborare in input, restituendoci poi il risultato corrispondente (l’output).
Questo ulteriore livello di astrazione consente alle applicazioni, se opportunamente disegnate, di usufruire di prestazioni computazionali elevate a costi molto contenuti e agli sviluppatori di non doversi preoccupare degli aspetti precedentemente elencati.
Proseguiamo quindi ora con l’analisi delle tecnologie Cloud Native che sono state sviluppate nel corso degli anni e che devi assolutamente conoscere.
Tecnologie Cloud Native: container o virtual machine?
Un sistema di containerizzazione consente di emulare un kernel indipendente (la parte centrale del sistema operativo Linux) per ogni container, all’interno del quale collocare solo il programma software (il codice) ed eseguirlo come processo.
Nella pratica però un programma necessita di altre parti accessorie, come librerie, moduli e strumenti. Dal momento che molte di queste parti sono già incluse in un sistemo operativo, quest’ultimo va ormai di prassi a costituire la base del container.
Un container non è così diverso da una macchina virtuale, anzi, le similitudini sono molteplici:
- si compone spesso di un piccolo sistema operativo Linux, di qualche libreria e del software applicativo;
- comunica via rete con un indirizzo IP;
- ha un proprio file system in cui scrive e legge dati;
- uno o più container vengono eseguiti all’interno di un unico host (fisico o virtuale) che gli assegna una porzione di CPU, un po’ di memoria e spazio disco.
La differenza sostanziale rispetto ad una virtual machine riguarda il modo in cui il container viene costituito e come viene gestito. Strumenti come Docker consentono di impacchettare tutto il software (OS, moduli e codice) in singole immagini. Piattaforme come Kubernetes permettono, invece, di eseguire le immagini all’interno di container e di gestirli in modo efficiente su larga scala.
Dedicheremo il prossimo Pod del nostro Cloud Computing Project alla tecnologia Kubernetes: non perderlo!
Pratiche DevOps: perché sono la risposta alle sfide del Cloud Native
Abbiamo elencato i diversi plus delle tecnologie Cloud Native, tra “elasticità”, flessibilità e performance delle piattaforme. Abbiamo visto come i microservizi permettono di comprimere i cicli di gestione del software, riducendo i tempi di rilascio di nuove funzioni e rendendo quindi le aziende più agili e reattive.
Tuttavia, se è vero che questo marcato dinamismo si esprime come un vantaggio considerevole per le aziende che ne fanno uso, il Cloud Native crea inevitabilmente nuova complessità e (potenzialmente) confusione, a causa della numerosità dei microservizi e all’astrazione, che inevitabilmente aggiunge nuovi strati funzionali.
Le puntuali risposte a queste sfide, risiedono senz’altro nella tecnologia, ma anche nei processi e nelle metodologie. Le pratiche DevOps, teorizzate a fine anni duemila, hanno trovato terreno fertile nel contesto Cloud Native, con esso si sono evolute e indissolubilmente legate.
Le pratiche DevOps si presentano come una vera e propria cultura, un approccio, una filosofia con al centro le persone, la loro organizzazione e i loro comportamenti. Infatti, sono concepite da operatori IT con l’obiettivo di superare i continui attriti tra i teams di sviluppo del software (i Dev) e quelli preposti alla loro esecuzione e gestione (gli Ops).
Al di là degli aspetti concettuali però, sebbene quest’introduzione porti a pensare tutt’altro, DevOps è tanta sostanza e tanto pragmatismo. Gli strumenti e le piattaforme a disposizione dei DevOps engineer sono mature, affidabili, ricche di funzioni, relativamente economiche (c’è tanto open-source) e già attuando le pratiche più semplici i risultati e i benefici sono evidenti.
Fare la differenza con le applicazioni cloud native
L’approccio Cloud Native porta concreti e proficui benefici se:
- si adottano determinate architetture applicative;
- si eseguono le applicazioni in ambienti che utilizzano una serie di tecnologie innovative;
- si implementano specifiche metodologie e pratiche.
Le azioni di trasformazione dei workloads basati su questi elementi, definiti come processi di “modernizzazione” delle applicazioni, possono fare la differenza nell’adozione ottimale delle tecnologie native del cloud da parte delle aziende e nello sviluppo di una strategia di business competitiva.
Con le applicazioni cloud native le aziende possono trarre completo vantaggio dalla scalabilità dei servizi cloud e soprattutto di ridurre i costi legati all’acquisto e alla manutenzione di hardware e software. I team IT possono allocare risorse secondo necessità, con un provisioning appropriato e puntuale.
La capacità dei microservizi di essere ridimensionati a seconda delle esigenze, permette un aggiornamento rapido e puntuale di alcuni componenti software, senza dover aggiornare l’intera applicazione.
Le aziende possono acquisire un vantaggio dalle applicazioni cloud sfruttando la possibilità di essere trasferite senza problemi su infrastrutture diverse. Rispetto alle applicazioni tradizionali, che richiedono un collegamento diretto tra sistema operativo, hardware e storage, le applicazioni cloud native vengono eseguite su sistemi operativi “separati”, evitando problematiche di migrazione delle applicazioni nelle nuove infrastrutture.
In conclusione, adottare le applicazioni cloud native, rispetto a quelle tradizionali, garantisce alle aziende diversi vantaggi competitivi che non possono e non devono essere trascurati.
