Il termine “cloud-native” viene utilizzato sempre più spesso, soprattutto dai fornitori di servizi cloud e ha anche una base “ufficiale” grazie alla Cloud Native Computing Foundation (CNCF) lanciata nel 2015 dalla Linux Foundation.

Cos’è il cloud-native?

Nell’uso generale cloud-native rappresenta un approccio alla creazione e all’esecuzione di applicazioni che sfrutta i vantaggi del modello di delivery del cloud computing. Cloud-native riguarda il modo in cui le applicazioni vengono create e distribuite e implica il fatto che le app risiedano nel cloud pubblico e non in un data center locale.

La CNCF definisce cloud-native con un senso un po’ più preciso per indicare l’uso di stack software open source containerizzato, dove ogni parte dell’app è impacchettata nel proprio container e orchestrata dinamicamente in modo che ciascuna parte sia attivamente pianificata e gestita per ottimizzare l’utilizzo delle risorse.

“Un’app cloud-native è progettata specificatamente per funzionare nella natura elastica e distribuita richiesta dalle moderne piattaforme di cloud computing” afferma Mike Kavis, amministratore delegato della società di consulenza Deloitte. “Queste app sono liberamente accoppiate, il che significa che il codice non è strettamente legato a nessuno dei componenti dell’infrastruttura, in modo che l’app possa scalare su e giù su richiesta e rispettare i concetti di infrastruttura immutabile. Tipicamente, queste architetture sono costruite usando microservizi, ma questo non è un requisito obbligatorio.”

Per le applicazioni cloud-native la grande differenza è quindi il modo in cui l’applicazione viene creata, distribuita e gestita, afferma Andi Mann, CTO del provider di servizi cloud Splunk. “Sfruttare i servizi cloud significa utilizzare componenti agili e scalabili come i container per offrire funzionalità discrete e riutilizzabili”.

Lo sviluppo di app cloud-native include in genere devops, metodologia agile, microservizi, piattaforme cloud, container come Kubernetes e Docker e consegne continue, ovvero ogni nuovo e moderno metodo di distribuzione delle applicazioni. Per questo motivo è caldamente consigliabile un modello di piattaforma come servizio (PaaS), che pur non essendo obbligatorio rende le cose molto più semplici.

La stragrande maggioranza dei clienti del cloud inizia con un modello di infrastruttura come servizio (IaaS), che aiuta ad astrarre le proprie app dall’hardware sottostante. Ma un modello PaaS aggiunge un ulteriore livello per astrarre il sistema operativo sottostante, in modo che possiate concentrarvi interamente sulla logica di business della vostra app e non preoccuparvi di interpellare continuamente il sistema operativo.

Differenze tra app native-cloud e app on-premises

Lo sviluppo di applicazioni cloud-native richiede un’architettura molto diversa rispetto alle tradizionali applicazioni aziendali.

Linguaggi
Le app locali sviluppate per essere eseguite sui server aziendali tendono ad essere scritte in linguaggi tradizionali come C/C++, C # o un altro linguaggio di Visual Studio se distribuite su una piattaforma Windows Server. Se invece si parla di mainframe, è probabile che si utilizzi Cobol. Le app cloud-native invece hanno più probabilità di essere scritte in un linguaggio incentrato sul web e quindi in HTML, CSS, Java, JavaScript, .Net, Go, Node.js, PHP, Python e Ruby.

Aggiornabilità
Le app cloud-native sono aggiornate continuamente e sempre disponibili. Le app on-premises vengono in genere fornite in abbonamento dal fornitore e richiedono tempi di inattività durante l’installazione degli aggiornamenti.

Elasticità
Le app cloud-native sfruttano l’elasticità del cloud utilizzando risorse incrementate durante un picco di utilizzo. Se per esempio la vostra app di e-commerce basata su cloud presenta un picco di utilizzo, è possibile impostarla per utilizzare risorse di elaborazione aggiuntive finché il picco non si abbassa e quindi disattivare tali risorse. Un’app cloud-native può adattarsi alle risorse aumentate e ridimensionarle in base alle esigenze, mentre un’app locale non può scalare in modo dinamico.

Multitenancy
Un’app cloud-native non ha problemi a lavorare in uno spazio virtualizzato e a condividere risorse con altre app. Molte app on-premises invece non funzionano bene in un ambiente virtuale (o non funzionano affatto) e richiedono uno spazio non virtualizzato.

Risorse connesse
Un’app locale è piuttosto rigida nelle sue connessioni alle risorse di rete (reti, sicurezza, autorizzazioni e spazio di archiviazione). Molte di queste risorse devono essere hard-coded e si interrompono se qualcosa viene spostato o modificato. “La rete e lo storage sono completamente diversi nel cloud. Quando si sente il termine re-platforming, si tratta in genere del lavoro per adeguarsi ai cambiamenti nelle tecnologie di rete, di archiviazione e persino di database per consentire all’app di funzionare nel cloud”, aggiunge Kavis.

Automazione
Gran parte del cloud è automatizzato e include la gestione delle app. “I vantaggi del modello di delivery del cloud-native, in particolare la velocità e l’agilità, si basano in modo significativo su un substrato di processi affidabili e verificati, che vengono eseguiti ripetutamente secondo necessità da strumenti di automazione e orchestrazione piuttosto che tramite l’intervento manuale”, afferma Mann. Gli ingegneri dovrebbero cercare di automatizzare praticamente tutto ciò che fanno più di una volta per abilitare la ripetibilità, il self-service, l’agilità, la scalabilità, l’audit e il controllo. Le app on-premises devono invece essere gestite manualmente.

Design modulare
Le app on-premises tendono a essere monolitiche nel design. Scaricano un po’ di lavoro sule library, certo, ma alla fine si tratta di una grande app con un sacco di subroutine. Le app cloud-native sono invece molto più modulari, con molte funzioni suddivise in microservizi. Ciò consente ad esempio di aggiornare all’occorrenza solo un determinato modulo e non l’intera app.

Le sfide del computing cloud-native

“Uno dei grandi errori commessi quando si parla di sviluppo di app è il tentativo di spostare vecchie app on-premises sul cloud”, conclude Mann. “Il tentativo di prendere le applicazioni esistenti, in particolare le applicazioni legacy monolitiche, e trasferirle su un’infrastruttura cloud non sfrutterà le funzionalità essenziali del cloud-native”.

Si dovrebbe invece cercare di fare nuove cose in modi nuovi, sia inserendo nuove applicazioni cloud-native in una nuova infrastruttura cloud, sia suddividendo le app monolitiche esistenti per ridefinirle usando i principi cloud-native da zero. È anche meglio rinunciare ai vecchi metodi di sviluppo. Il modello a cascata è sicuramente da scartare, ma anche uno sviluppo agile potrebbe non essere sufficiente. Pertanto è necessario adottare nuovi approcci cloud-native come lo sviluppo del prodotto minimo (MVP), test multivariati, iterazione rapida e lavorare a stretto contatto con un modello devops.

Ci sono infine molti aspetti da considerare se si opta per uno sviluppo cloud-native, inclusi servizi di infrastruttura, automazione/orchestrazione, virtualizzazione e containerizzazione e architettura dei microservizi. Tutto ciò significa un nuovo modo di fare le cose e quindi rompere con le vecchie abitudini e imparare nuovi modelli.