Il concetto di Trasformazione Digitale richiama ormai costantemente quello dello sviluppo cloud-nativo. E questo rimanda al modello della virtualizzazione a container. Non sono due legami del tutto scontati. Ma per molte imprese l'approccio "ovvio" alla digitalizzazione è diventato appunto adottare approcci cloud-nativi. In particolare ora nella parte dello sviluppo applicativo. Il che di norma di traduce in adottare una logica basata su container e microservizi. Questo come linea generale. Il problema per molte aziende semmai è capire cosa voglia davvero dire, nella pratica, cloud-nativo.

Non è semplice muoversi nella galassia delle tecnologie e delle piattaforme che si possono considerare cloud-native. Anche la Cloud Native Computing Foundation non ne dà una definizione molto stringente. E nemmeno un elenco di strumenti da adottare. Quella "cassetta degli attrezzi" per lo sviluppo cloud-nativo che molte aziende invece cercano.

Per la CNCF le tecnologie cloud-native sono quelle che "permettono di realizzare ed eseguire applicazioni scalabili in ambienti moderni e dinamici come i cloud pubblici, privati e ibridi". Container, service mesh, microservizi e API dichiarative sono indicati come esempi di questo approccio. Perché "abilitano sistemi ad accoppiamento lasco che sono resilienti, gestibili ed osservabili". Il che, insieme all'automazione, permette di "applicare modifiche ad alto impatto frequentemente e in maniera prevedibile, con uno sforzo minimo".
Tutto vero, ovviamente. Ma per molti dipartimenti IT queste definizioni non danno un grande aiuto pratico. Scendendo più in dettaglio, la Cloud Native Computing Foundation presenta un Cloud Native Landscape che traccia a grandi linee il percorso nei "territori inesplorati" delle tecnologie cloud-native. Una serie di passi successivi che comprendono containerizzazione, CI/CD, orchestration, analisi, service mesh, networking, database e storage distribuiti, messaging. E un inizio di indicazione delle piattaforme di riferimento. Anche per lo sviluppo cloud-nativo.

Dopo però, a meno che non si siano sviluppate competenze interne o non ci si muova per co-innovazione, un'azienda si trova un po' persa davanti a quasi 1.400 progetti, open source e non, potenzialmente utili. Alcuni che certamente si useranno. Altri molto meno scontati. Con una complessità in più: poche aziende hanno il vantaggio di potersi basare del tutto su applicazioni cloud. Il più delle volte hanno una dotazione legacy che va modernizzata. O integrata con il nuovo sviluppo cloud-nativo.

Cloud-nativo ai minimi termini

Si può cercare di dare una linea guida relativamente sintetica al percorso cloud-nativo potenziale di una impresa. Partendo da una interpretazione molto operativa di IT cloud-nativa: la somma di sviluppo agile, DevOps, container, microservizi, cloud. Almeno per le applicazioni che ne traggono vantaggio. Non per tutte è così: se una applicazione funziona adeguatamente in una versione monolitica tradizionale, trasformarla in una rete di microservizi sarà moderno ma potrebbe anche essere eccessivo. Lo sviluppo cloud-nativo non è un obbligo universale.
Da questa interpretazione restrittiva può nascere una piccola "lista della spesa", assolutamente non esaustiva, di strumenti da adottare. Il mattoncino di base è praticamente obbligato, comunque. La virtualizzazione a container è la base imprescindibile di qualsiasi modello cloud-nativo. Il che oggi significa anche adottare Kubernetes come piattaforma di orchestrazione. A partire da Kubernetes ci si può muovere scegliendo altri strumenti che vi siano particolarmente integrati. Dipende dalle aree operative che si vogliono coprire.

Prima però va ricordato che, come per tutti i buoni progetti open source, scegliere Kubernetes in sé significa comunque avere la scelta tra varie sue implementazioni. Kubernetes in sé non è affatto banale. Per questo si stanno affermando le piattaforme "branded" che lo circondano con altri tool e interfacce in modo da semplificarlo. A volte anche integrandolo in modelli applicativi sensibilmente diversi ma più familiari.

Sviluppo cloud-nativo mirato

Se Kubernetes è la base infrastrutturale, come affrontare lo sviluppo cloud-nativo? I linguaggi papabili sono diversi. Alcuni davvero moderni e pensati per il cloud, come Go o il peculiare Ballerina. Ma uno sviluppatore prudente sa che prima o poi dovrà scontrarsi con codice lagacy. Quindi non stupisce come restino sempre popolari i linguaggi che riescono a creare un ponte tra vecchio e nuovo. Due nomi da considerare sono il buon vecchio Java e Kotlin.
Java sembrerebbe fuori gioco. Ma molte imprese e software house vi hanno investito pesantemente. Quindi conviene esaminare alcuni approcci - in particolare Quarkus - che cercano di traghettare il linguaggio al mondo dei container. Da parte sua, Kotlin è noto soprattutto per aver soppiantato Java come piattaforma di rifermento per lo sviluppo Android. Ma molti scommettono su una sua crescente diffusione anche nel mondo dello sviluppo cloud-nativo.

Per le applicazioni cloud-native è impossibile muoversi senza un approccio DevOps. E senza una piattaforma di Continuous Integration e Continuous Delivery. L'autorità in questo campo è la Continuous Delivery Foundation. Che al momento ha quattro progetti di punta: Jenkins, Jenkins X, Spinnaker, Tekton. Jenkins non ha bisogno di presentazioni ed è un grande classico. Jenkins X è il suo erede per il mondo cloud, Spinnaker segue un approccio simile. Tekton è forse più indietro degli altri, come progetto, ma ha il vantaggio interessante di essere nato per Kubernetes. E dalla stessa casa madre: Google.