Laddove i team operativi gestiscono manualmente le allocazioni delle risorse dell’infrastruttura alle applicazioni tradizionali, le applicazioni cloud-native vengono distribuite su un’infrastruttura che ne estrae le complessità dei sistemi di esecuzione (runtime engine), dello storage e della rete sottostante. Gli sviluppatori e gli operatori che si occupano di questa nuova generazione di applicazioni non interagiscono direttamente con le API (Application Programming Interface) e le UI esposte dall’infrastruttura. Invece, l’orchestratore (Kubernetes ne è diventato uno standard in questo) gestisce automaticamente l’allocazione delle risorse, secondo politiche stabilite dai team DevOps. Il controller e lo scheduler, due componenti essenziali del motore di orchestrazione, gestiscono l’allocazione delle risorse e il ciclo di vita delle applicazioni.

Le piattaforme cloud-native, come Kubernetes, espongono una rete sovrapposta alle topologie di rete esistenti e alle primitive dei cloud provider. Allo stesso modo, lo storage layer viene spesso astratto per esporre i volumi logici che sono integrati con i containers. Gli operatori possono allocare quote di storage e policy di rete a cui accedono sviluppatori e amministratori delle risorse. L’astrazione dell’infrastruttura non solo risponde alla necessità di portabilità in ambienti cloud multipli, ma consente anche agli sviluppatori di sfruttare i modelli emergenti più moderni per costruire e distribuire applicazioni. Gli orchestratori diventano il target della distribuzione dell’applicazione, indipendentemente dall’infrastruttura sottostante che può essere basata su server fisici o macchine virtuali, cloud privati ​​o cloud pubblici. HyScale in questo è una ottima dimostrazione di quanto il layer di orchestrazione può essere ulteriormente astratto dai nuovi tools CNCF, lasciando spazio a nuove funzionalità software e concentrando gli sforzi non più nella gestione ma nel delivery.

Kubernetes è una piattaforma ideale per l’esecuzione di carichi di lavoro concorrenti progettati come applicazioni cloud-native. È diventato, di fatto, il sistema operativo per il cloud, più o meno allo stesso modo in cui Linux è il sistema operativo per le macchine sottostanti. Finché gli sviluppatori seguiranno best practice di progettazione e sviluppo di software come un insieme di microservizi che compongono le applicazioni cloud-native, i team DevOps saranno in grado di impacchettarli e distribuirli in Kubernetes.

Ecco i 10 punti chiave delle applicazioni cloud-native che gli sviluppatori dovrebbero tenere a mente durante la progettazione di applicazioni e soluzioni software moderne.

I 10 attributi chiave di una applicazione cloud-native:

1. Impacchettata come container superleggero : le applicazioni cloud-native sono una raccolta di servizi indipendenti e autonomi che vengono impacchettati come containers molto leggeri. A differenza delle macchine virtuali, i containers possono ridimensionarsi e adattarsi rapidamente. Poiché l’unità minima di ridimensionamento si sposta sui container, l’utilizzo dell’infrastruttura viene ottimizzato e esiste una riduzione del footprint e dei costi.
2. Sviluppata con linguaggi e framework adatti all’esigenza specifica : ogni servizio di un’applicazione cloud-native viene sviluppato utilizzando il linguaggio e il framework più adatti alla funzionalità. Le applicazioni cloud-native sono poliglotte; i servizi utilizzano una varietà di linguaggi, runtime e framework. Ad esempio, gli sviluppatori possono creare un servizio di streaming in tempo reale basato su WebSocket, sviluppato in Node.js, mentre scelgono Python e Flask per esporne le API. L’approccio accurato allo sviluppo di microservizi consente loro di scegliere la lingua e i framework migliori per lo specifico lavoro.
3. Progettata come microservizi disaccoppiati : i servizi che appartengono alla stessa applicazione si scoprono l’un l’altro attraverso il runtime dell’applicazione. Esistono indipendentemente da altri servizi. L’infrastruttura elastica e le architetture applicative, se integrate correttamente, possono essere ridimensionate con efficienza e prestazioni elevate. I servizi liberamente accoppiati consentono agli sviluppatori di trattare ciascun servizio indipendentemente dall’altro. Con questo disaccoppiamento, uno sviluppatore può concentrarsi sulle funzionalità principali di ciascun servizio per offrire funzionalità dettagliate. Questo approccio porta a una gestione efficiente del ciclo di vita dell’intera applicazione, poiché ogni servizio è gestito in modo indipendente e con una chiara proprietà.
4. Incentrata sulle API per l’interazione e la collaborazione : i servizi cloud-native utilizzano API leggere basate su protocolli come REST (Representational State Transfer), RPC open source di Google (gRPC) oppure servizi pub/sub come NATS. REST viene utilizzato come minimo comune denominatore per esporre le API su HTTP (Hypertext Transfer Protocol). Per quanto riguarda le prestazioni, gRPC viene in genere utilizzato per la comunicazione interna tra i servizi. NATS ha funzionalità di publish/subscribe che consentono la comunicazione asincrona all’interno dell’applicazione.
5. Progettato con una netta separazione tra servizi stateless e stateful : i servizi persistenti e duraturi seguono uno schema e un implementazione che deve garantire maggiore disponibilità e resilienza. I servizi senza stato devono esistere indipendentemente dai servizi con stato. In questo, lo storage gioca un ruolo molto importante, quando si sceglie l’uso dei containers. La persistenza è un fattore che deve essere sempre più considerato nel contesto delle applicazioni cloud-native; con stato, senza stato stato,  e – alcuni direbbero – in ambienti di micro-archiviazione.
6. Isolata dalle dipendenze del server e del sistema operativo : le applicazioni native del cloud non hanno affinità con alcun sistema operativo o macchina specifica. Operano a un livello di astrazione più elevato. Poche se non uniche eccezioni sono quelli di microservizi che necessitano di alcune funzionalità, tra cui unità a stato solido (SSD) e unità di elaborazione grafica (GPU), che possono essere offerte esclusivamente da un sottoinsieme di macchine assegnate a questi.
7. Distribuito su infrastruttura cloud self-service, elastica : le applicazioni native per il cloud sono distribuite su infrastruttura virtuale, condivisa ed elastica. Possono allinearsi con l’infrastruttura sottostante per crescere e restringersi in modo dinamico, adattandosi al carico variabile.
8. Gestito attraverso processi DevOps agili : ogni servizio di un’applicazione cloud nativa passa attraverso un ciclo di vita indipendente, che viene gestito attraverso un processo DevOps agile. Più pipeline di integrazione continua/consegna continua (CI/CD) possono funzionare in tandem per distribuire e gestire un’applicazione cloud-native.
9. Funzionalità automatizzate: le applicazioni native del cloud possono essere altamente automatizzate. Devono poter giocare bene con i concetti di infrastruttura come codice (IaaC). In effetti, è necessario un certo livello di automazione semplicemente per gestire queste applicazioni grandi e complesse.
10. Allocazione delle risorse definita e orientata alle policy :  infine, le applicazioni cloud-native si allineano bene a modello di governance definiti attraverso policy. Aderiscono a criteri quali assegnazione di unità di elaborazione (CPU allocation), quote di storage e criteri di rete che allocano risorse ai servizi. Ad esempio, in uno scenario aziendale, l’IT centrale può definire criteri per allocare le risorse per ciascun reparto. Gli sviluppatori e i team DevOps di ciascun dipartimento avranno così accesso e proprietà completi alla loro quota di risorse assegnate.