Quando si finisce a parlare di software si sente sempre più spesso parlare di applicazioni cloud native. Ma cosa sono? Perché se ne parla in maniera così costante? E, soprattutto, perché secondo gli analisti, il Software-as-a-Service, ossia il principale modello con cui vengono rese disponibili le app cloud native, è destinato a diventare il più diffuso del mercato software entro i prossimi cinque anni?

La risposta a queste domande emerge in modo quasi spontaneo nel momento in cui andiamo a soffermarci sugli aspetti fondamentali dell’universo cloud native. Oltre a capire nello specifico in cosa consiste, è fondamentale comprendere le logiche strategiche e tecnologiche che ne stanno alla base. Tali aspetti hanno visto l’esigenza di trovare un ambiente di sviluppo pensato ad hoc per le architetture a microservizi, che presenta scenari profondamente diversi rispetto ai tradizionali modelli monolitici. Questo punto di rottura ha tuttavia costituito soltanto l’inizio di un’evoluzione tuttora ampiamente in divenire.

Cosa significa cloud native

Con il termine cloud native si identifica un’applicazione progettata e realizzata nello specifico per il cloud computing, sfruttandone alcune caratteristiche fondamentali. La componente nativa si riferisce infatti al fatto che l’applicazione viene concepita sin dal primo istante per sfruttare gli ambienti di esecuzione in piattaforme disponibili in cloud (Platform-as-a-Service), in particolare per quanto concerne tecnologie di virtualizzazione come i container.

Le applicazioni cloud native si distinguono per l’impiego di un’architettura a microservizi, che prevede che i componenti del software siano tra loro disaccoppiati, in modo da poter essere sviluppati in maniera indipendente uno dall’altro, secondo i principi strategici e organizzativi della metodologia DevOps.

Come vedremo, a differenza delle tradizionali architetture monolitiche, i microservizi presuppongono un’organizzazione molto più agile in tutte le fasi dello sviluppo, ma al tempo stesso richiedono criteri di progettazione totalmente diversi, utilizzando tecnologie ad hoc, che trovano appunto la loro concretizzazione nelle applicazioni cloud native.

Le caratteristiche che rendono prontamente riconoscibile un’applicazione cloud native sono le seguenti:

Basate sui microservizi

A differenza dell’architettura monolitica, che prevede un unico blocco contenente tutte le funzioni, l’architettura a microservizi deriva dalla decomposizione in vari elementi, che possono essere gestiti in maniera distinta ed essere assegnati a differenti team di sviluppo, secondo le logiche organizzative della metodologia DevOps. I singoli componenti dell’applicazioni comunicano tra loro mediante le API (Application Program Interface);

Basate sui container

I container sono ambienti virtualizzati al livello del sistema operativo, che mettono a disposizione tutti gli elementi necessari per l’esecuzione di un’applicazione. I container si sposano perfettamente con la filosofia alla base dei microservizi, che possono essere eseguiti singolarmente e isolati gli uni dagli altri, con la possibilità di abilitare più istanze dello stesso servizio, particolare che agevola di gran lunga le fasi di testing del software;

Basate sulle API

Le API servono a connettere i container che eseguono i singoli componenti dell’applicazione quando queste devono comunicare tra loro, per risolvere a livello funzionale il disaccoppiamento che generalmente li contraddistingue.

Come viene creata un’applicazione cloud native

Le applicazioni cloud native non sono tali soltanto per una questione di carattere puramente tecnologico. C’è molta strategia nel loro approccio, in quanto sono strettamente legate ad una metodologia di sviluppo come DevOps (Developer Operations).

Le app cloud native consentono di rendere disponibile il software con una modalità CI / CD (Continous Integration / Continous Delivery) tipica del SaaS. Tale modello consente all’utente finale di concentrarsi esclusivamente sul proprio lavoro, senza preoccuparsi di dover continuamente aggiornare le applicazioni utilizzate all’ultima versione, o scaricare i continui aggiornamenti di sicurezza che interessano le applicazioni legacy.

Dal punto di vista tecnologico, come abbiamo accennato, risulta decisiva la sinergia tra l’architettura a microservizi delle applicazioni cloud native e i container che consentono di eseguirli in PaaS, avvalendosi di tutti i vantaggi caratteristici del cloud computing.

Ogni microservizio esegue infatti una funzione e, facilitandoci la vita con soluzioni come Docker, può essere facilmente avviato all’interno di un singolo container, che contiene tutto il necessario per la sua esecuzione (librerie, codice, file binari, config file, dipendenze, ecc.). L’elevata portabilità dei container consente al team di sviluppo una notevole flessibilità, indispensabile quando si tratta di gestire team differenti, che operano oltretutto con tecnologie e linguaggi di programmazione differenti all’interno dello stesso progetto DevOps.

Per progettare le applicazioni cloud native basate sulla metodologia DevOps è opportuno attenersi ad alcune best practice, anche se non vi sono regole assolute. Ogni project manager può infatti decidere di strutturare un’operatività differente, in quanto non esiste a priori una soluzione migliore di un’altra, anche se i vari framework a cui è possibile ispirarsi sono già il risultato di una profonda osservazione e sperimentazione su milioni di casi studio di sviluppo.

La soluzione scelta per produrre un’applicazione cloud native deriva sempre da una delicata fase di assessment, in cui i project manager devono individuare le soluzioni migliori per sviluppare un’applicazione che sappia risolvere le esigenze di business in coerenza con i budget e i tempi previsti per il rilascio.

Non è inoltre fondamentale azzeccare ogni passaggio al primo colpo, in quanto l’applicazione cloud native è perfetta per una strategia di miglioramento continuo lungo il suo intero ciclo di vita. Il fatto che i suoi componenti siano fortemente disaccoppiati agevola questo approccio sia dal punto di vista operativo che da quello strategico ed organizzativo.

A titolo esemplificativo, il design di un’applicazione cloud native dovrebbe pertanto tenere conto il più possibile delle seguenti best practice.

Automazione

I Platform-as-a-Service offrono tool sempre più automatizzati e dotati di processi self-service, che consentono di gestire gli ambienti di esecuzione senza un contributo sostanziale da parte di un sistemista, dal momento che tutto ciò che avviene lato cloud fa carico alla responsabilità del CSP con cui si effettua il contratto di fornitura, secondo le SLA (Service Level Agreement) previste. Questa condizione agevola la possibilità di sviluppare un’applicazione eseguendo i vari microservizi su cloud differenti. Il multicloud da un lato rende più complessa l’orchestrazione dei vari servizi utilizzati, ma può agevolare notevolmente le cose dal punto di vista tecnico, per garantire agli sviluppatori la maggior flessibilità possibile.

Monitoraggio

Le applicazioni basate sul CI / CD possono prevedere cicli di vita anche estremamente lunghi, che vanno implementati senza farsi travolgere dalla complessità, rischiando di risultarne congestionati dall’incapacità di gestire certe numeriche di microservizi eseguiti su differenti cloud. In altri termini, non devo ritrovarmi dopo due anni dall’inizio di un progetto ad impazzire perché non riesco più a monitorare quanto avviene negli elementi che compongono le applicazioni cloud native. L’orchestrazione dei container in multicloud e, più in generale, nel cloud ibrido, andrebbe sempre pianificata a monte e implementare con strumenti adeguati a risolvere le nostre esigenze, in base alla natura molto eterogenea dei progetti di sviluppo che possono di volta in volta prospettarsi.

Documentazione

Uno degli aspetti critici legati alla metodologia DevOps è costituita, per design, dal fatto che i singoli team di sviluppo possono avere una scarsa visibilità del lavoro che stanno producendo i loro colleghi, impegnati nello sviluppo di altre funzioni. Talvolta è addirittura possibile che un team ignori il significato complessivo dell’applicazione. Anche se tale condizione non è essenziale dal punto di vista puramente tecnologico, i project manager dovrebbero coinvolgere i singoli team nell’ottica di una visione di insieme che può favorire sia la motivazione generale sia quell’approccio di continuità funzionale che viene dissimulato dal disaccoppiamento dei singoli componenti da sviluppare. A livello operativo, sarebbe opportuno che ogni team documentasse in maniera dettagliata il proprio operato, anche in funzione di agevolare i possibili turnover che possono verificarsi nel tempo, sempre considerando la notevole dilatazione temporale che può assumere il ciclo di vita di un’applicazione cloud native.

Reversibilità e miglioramento continuo

Il progetto andrebbe concepito sia per facilitare le continue integrazioni di cui i vari moduli funzionali necessitano, sia per rendere facilmente reversibili le operazioni nel caso in cui nel medio periodo ci si rendesse conto che la strada intrapresa da un certo punto in poi non corrisponde a quella ottimale. Anche in questo caso l’automazione offre un notevole aiuto, ad esempio grazie al IaC (Infrastructure as Code) che consente di tracciare i cambiamenti nei vari repository. Un’adeguata strategia di miglioramento continuo per un’applicazione cloud native deve inevitabilmente tenere conto degli errori che si presentano lungo il ciclo di vita del software. È inoltre possibile avvalersi di framework che consentono di simulare errori per valutarne le conseguenze ed adottare puntualmente strategie di carattere migliorativo.

I vantaggi del cloud native rispetto alle soluzioni on-premise

Le applicazioni cloud native consentono di avvalersi della maggior parte dei vantaggi generalmente garantiti dal cloud computing, a cominciare dalla scalabilità delle applicazioni. I singoli servizi non sono legati per forza ad uno specifico cloud service provider, per cui è possibile valutare costantemente le migliori offerte disponibili sia dal punto di vista tecnologico che da quello economico.

Anche se l’offerta in cloud è composta da ecosistemi che potrebbero generare un lock-in in maniera abbastanza naturale, la struttura a microservizi delle applicazioni consente di svincolarsi abbastanza agevolmente da un PaaS all’altro, pur senza sottovalutare tutte le criticità del caso.

In ogni caso, non si è vincolati dall’overbuy e dal mantenimento dell’infrastruttura IT on-premise. In cloud è possibile scalare in qualsiasi momento verso l’alto o verso il basso le risorse necessarie per eseguire i propri carichi di lavoro, una caratteristica irrinunciabile quando si tratta di sviluppare applicazioni cloud native composte anche da centinaia di differenti microservizi.

L’approccio cloud native consente inoltre di ottenere una generale flessibilità grazie al fatto che i microservizi vengono eseguiti in container che per natura sono estremamente portabili da un sistema all’altro, soprattutto se ci si avvale di tecnologie come Docker e Kubernetes per facilitarne la creazione e l’orchestrazione. Non va inoltre dimenticato che l’onere di mantenere aggiornato il PaaS spetta al cloud service provider, per cui lo sviluppatore può concentrarsi soprattutto a svolgere al meglio il proprio lavoro, senza preoccuparsi di dover anche tenere sotto controllo l’infrastruttura IT necessaria per il test e il deploy delle applicazioni cloud native.

Un’altra qualità fondamentale delle applicazioni cloud native è costituita dalla facilità con cui i singoli componenti possono essere ricombinati e riutilizzati nel contesto di produrre nuove applicazioni. I singoli elementi, del tutto isolati e disaccoppiati possono comunicare tra loro mediante l’impiego di API standardizzate, per cui è possibile disegnare una nuova applicazione in tempi relativamente ridotti, ricombinando dei moduli funzionali già sviluppati in precedenza, concentrandosi soltanto sulle variazioni strettamente necessarie. 

Questo aspetto corrisponde probabilmente al principale collo di bottiglia del software basato sull’architettura monolitica, un unico blocco che va necessariamente rimodellato nel caso in cui si rende necessario sviluppare un nuovo progetto. La stretta interdipendenza funzionale rende molto difficile il riciclo di parti di codice senza che vi siano significative ripercussioni su altre parti dell’applicazione.

Un altro vantaggio chiave delle applicazioni cloud native rispetto al tradizionale on-premise monolitico è costituito dall’alta prevedibilità del loro comportamento, oltre all’elevato livello di automazione a cui abbiamo fatto accenno nel corso dei precedenti paragrafi. Tale qualità consente di avvalersi pienamente della scalabilità del cloud per poter disporre delle risorse necessarie in funzione dell’aumento o della diminuzione dei carichi di lavoro previsti. 

La visibilità di questo processo può ormai avvenire addirittura in tempo reale. L’applicazione cloud native può essere quindi scalata in ogni singolo microservizio, senza agire complessivamente sull’insieme, come avviene nel contesto del software monolitico. I processi di aggiornamento e autoregolazione dei microservizi vengono automatizzati grazie all’impiego di trigger predefiniti. Questi processi, attivati e cessati sulla base di eventi strettamente correlati alle funzioni, raggiungono la condizione limite nelle architetture serverless, totalmente trasparenti dal punto di vista delle risorse IT necessarie per eseguire un container che, per tale ragione, viene appunto definito stateless.

La possibilità di legare la disponibilità di risorse ad un evento e automatizzarne gli aggiornamenti costituisce un vantaggio essenziale nei confronti del tradizionale on-premise, che deve essere aggiornato manualmente, costringendo ad intervenire ogni volta sull’intera applicazione, il che rende estremamente più complessa la riduzione dei disagi causati dai downtime pianificati.

La possibilità di aggiornare in maniera indipendente soltanto i microservizi interessati da effettive novità consente una gestione molto più agile, che il più delle volte risulta del tutto trasparente all’utente finale. Tale logica, che costituisce il cardine del ciclo CI / CD è uno degli autentici game changer introdotti dalle applicazioni cloud native.

Le sfide del cloud native

Le applicazioni cloud-native costituiscono un argomento relativamente giovane nel mercato IT, ma è stato in grado di produrre un impatto veramente rivoluzionario nel modo in cui il software viene attualmente sviluppato e reso disponibile agli utenti finali.

Non è un caso che il futuro dello sviluppo sia identificabile in due macro direzioni, entrambe cloud native e tra loro oltretutto complementari. Da un lato, DevOps per le progettualità più complesse, a cui si aggiunge il mondo del low code / no code per i lavori ad elevata automatizzazione, richiesta in particolar modo dagli applicativi caratterizzati da un ciclo di vita più breve. Anche se in quest’ultimo caso il monolitico potrebbe costituire tuttora una valida alternativa, i vantaggi derivanti dalla maggior capacità di automatizzare i processi e disporre di tecnologie esclusive per gli ambienti cloud, come quelle basate sull’intelligenza artificiale, sta facendo oltremodo la differenza a vantaggio delle applicazioni cloud native.

Secondo le stime pubblicate da Cloud Native Computing Foundation, l’incremento di sviluppatori cloud native è aumentato di circa due milioni dal 2019 al 2020 (da 4.7 milioni a 6.6 milioni) e la brusca accelerata della trasformazione digitale innescata dalla pandemia Covid-19 ha contribuito ulteriormente ad accentuare questa dinamica di crescita, al punto che si prevedono importanti skill gap nei prossimi anni.

Per sopperire alla mancanza di sviluppatori cloud native “tradizionali”, sarà essenziale sviluppare e diffondere la cultura dello sviluppo low code / no code, in modo che un numero sempre crescente di applicazioni sia generato dai cosiddetti citizen developer. Si tratta di comuni dipendenti aziendali, che non possiedono specifiche competenze nei linguaggi di programmazione, ma possono costruire le applicazioni a loro necessarie grazie a comode piattaforme di sviluppo disponibili come SaaS.

Le sfide che attendono il cloud native sono dunque caratterizzate da una richiesta sempre più famelica di applicazioni basate su questo approccio. Dal punto di vista tecnologico lo scenario ci presenta un notevole fermento.

Da un lato, tecnologie di recente implementazione come i container dei Platform-as-a-Service, che presentano un trend in netta ascesa, risultano paradossalmente già “anziane” se paragonate alle architetture serverless, basate sul Function-as-a-Service, che godono di ambienti di esecuzione totalmente basati sugli eventi, che, grazie alla loro continua attivazione e cessazione, svincolano dalla persistenza delle risorse allocate in cloud.

L’approccio serverless costituirà pertanto un ulteriore livello di sfida per le applicazioni cloud native, con l’obiettivo di rendere lo sviluppatore sempre più svincolato da qualsiasi responsabilità gestionale nei confronti delle risorse IT necessarie.

Applicazioni Cloud Native: cosa significa e quali sono i vantaggi ultima modifica: 2022-05-05T11:01:47+02:00 da Francesco La Trofa

LEAVE A REPLY

Please enter your comment!
Please enter your name here