L’obiettivo della CNCF è aiutare le organizzazioni a costruire applicazioni scalabili su cloud pubblico, privato e ibrido. Un supporto che prende forme diverse: dalle tecnologie agli eventi, ecco di cosa si occupa la Cloud Native Computing Foundation.
Si fa presto a dire “Cloud Native”; non altrettanto semplice è il processo di adozione di questo paradigma per le organizzazioni che decidono di innovare il proprio ecosistema IT. La CNCF nasce esattamente per rispondere a questa difficoltà.
Quando si decide di guardare al Cloud Native, alcune domande sorgono spontanee:
Come valutare affidabilità e sicurezza di un tool? Il CNCF Landscape raccoglie centinaia di progetti e la maggior parte non arriverà mai in produzione da nessuna parte. Prima di adottarne uno guardate il livello di maturità CNCF (sandbox, incubating, graduated), quanti maintainer attivi ha e con che frequenza escono le patch di sicurezza: dalla nostra esperienza sono i tre indicatori che predicono meglio se quel componente sarà ancora manutenuto fra due anni.
Come si capisce in quale direzione si sta muovendo il Cloud Native? Innovare sì, ma con strumenti e metodologie già validati sul campo, con solidità documentata e compatibilità dimostrata con gli standard di interoperabilità.
Come selezionare i migliori partner tecnologici, quelli che hanno davvero le competenze per lavorare con questi strumenti? Un fornitore che impara Kubernetes sul vostro progetto lo fa pagare due volte: in mesi di calendario e in debito architetturale da riscrivere.
La risposta arriva dal luglio 2015, in concomitanza con il rilascio di Kubernetes 1.0: è la Linux Foundation, la fondazione nata per standardizzare Linux e supportarne crescita e adozione, ad annunciare la costituzione della CNCF. Google cede Kubernetes alla nuova fondazione come progetto fondativo: da quel trasferimento di proprietà parte la crescita dell’ecosistema che oggi gestiamo ogni giorno nei cluster in produzione. L’idea era tanto semplice quanto efficace: creare un punto di raccordo del mondo Cloud Native, uno spazio neutrale in cui far convergere progetti, vendor e chi quelle tecnologie le usa ogni giorno.
Un punto di incontro tra progetti open source e big tech
Il progetto avviato dalla Linux Foundation prende il nome di Cloud Native Computing Foundation, in breve CNCF. Oggi è il luogo in cui alcune tra le più importanti tecnologie open source (per citarne alcune, Kubernetes e i container) incontrano i principali attori del mondo Tech. Sviluppatori, grandi aziende tecnologiche, imprese che implementano il paradigma Cloud Native: tutti gravitano attorno alla CNCF.
In pratica, come dice esplicitamente la CNCF, lo scopo del progetto è quello di “costruire un ecosistema sostenibile per il software Cloud Native “.
La storia della Cloud Native Computing Foundation
La storia della Fondazione è particolare. E non poteva essere altrimenti, perché la CNCF è nata in seno alla Linux Foundation per volontà dei big della Silicon Valley. L’atto fondativo risale al 2015, quando Google, che fino a quel momento aveva guidato in casa lo sviluppo di Kubernetes, il sistema open-source di orchestrazione e gestione di container, decise di conferirne la gestione alla Linux Foundation. Il progetto di Kubernetes era arrivato a maturità con la versione 1.0 e aveva già dimostrato di essere una delle tecnologie chiave dell’infrastruttura globale: troppo importante per restare dentro i confini di una sola azienda. Dieci anni dopo, nel 2025, la Fondazione ha celebrato il decennale con oltre 800 membri e più di 200 progetti ospitati, secondo i dati del landscape ufficiale della CNCF.
La Linux Foundation ha così acconsentito ad avviare il progetto della CNCF con l’obiettivo di “rendere il Cloud Native ubiquo " coinvolgendo da subito molte grandi aziende. Oltre a Google (che ha guidato la fase iniziale, prima che la regia passasse in via stabile al Governing Board e al Technical Oversight Committee, gli organi che ancora oggi decidono su membership e progetti) erano presenti fin dall’inizio anche CoreOS, Mesosphere, Red Hat, Twitter, Huawei, Intel, Cisco, Ibm, Docker, Univa e VMware.
Oggi i membri della CNCF sono oltre 800 tra aziende e organizzazioni di tutto il mondo, tra cui anche noi di SparkFabrik. Ed è un punto molto importante, come vedremo tra poco, perché partecipare ai tavoli tecnici nei quali si definiscono gli standard tecnologici della core infrastructure di Internet è di fondamentale importanza per chi opera in questo settore.
I progetti della CNCF
Sarebbe limitativo immaginare la CNCF come un semplice veicolo che contiene un’unica tecnologia, cioè Kubernetes. Anche se, sicuramente, visto il ruolo che Kubernetes ha nello sviluppo dell’ecosistema Cloud Native, non sarebbe comunque cosa da poco.
All’interno della CNCF ci sono moltissimi progetti che sono organizzati in tre livelli crescenti di maturità tecnologica: Sandbox, Incubated e Graduated. I criteri che stabiliscono il livello di maturità di un progetto includono anche il suo tasso di adozione, la longevità e se è stato impiegato nella realizzazione di applicativi affidabili.
Quali sono i principali progetti? La lista è davvero lunga: da Kubernetes (ovviamente) a Prometheus, da etcd a CoreDNS, da Containerd a Envoy e Fluentd, ai quali si sono aggiunti nel frattempo Falco e OpenTelemetry, entrambi passati allo status di progetti Graduated. Ma ci sono anche i moltissimi progetti in corso di sviluppo nell’incubatore della CNCF. Tra questi: Contour per Envoy, gRPC, KubeEdge, Litmus.
È un mondo particolarmente ricco perché alcuni progetti nascono dalla comunità open source, altri da aziende che poi li conferiscono alla CNCF.
I Technical Advisory Group raccontano bene dove si è spostato il baricentro. Sulla sicurezza della supply chain il lavoro è ormai strutturale e ha prodotto artefatti concreti: il Software Supply Chain Best Practices White Paper del TAG Security ha fissato il vocabolario comune, mentre Sigstore (firma e attestazione senza dover gestire chiavi a lunga vita) e in-toto (attestazioni verificabili sui singoli passaggi della pipeline) sono diventati mattoni ricorrenti delle catene di build. Come si combinano questi strumenti in una pipeline reale, dalla firma degli artefatti alla verifica delle attestazioni in fase di deploy, lo abbiamo raccolto nella nostra guida alla security con gli strumenti CNCF. Accanto a questo lavoro di consolidamento, i due filoni che oggi tirano l’ecosistema sono AI e platform engineering.
Sul fronte AI la CNCF ha pubblicato nel 2024 il Cloud Native AI whitepaper e ha accolto progetti come Kubeflow, incubating dal 2023, e KServe; in parallelo, dentro Kubernetes, la Dynamic Resource Allocation e Kueue hanno reso finalmente governabile la condivisione delle GPU tra workload di training e di inferenza. Non è un tema accademico: chi porta modelli in produzione lo fa quasi sempre su cluster Kubernetes che esistono già, non su stack dedicati.
Il platform engineering ha prodotto invece il Platforms White Paper e il Platform Engineering Maturity Model. Li usiamo come griglia di valutazione quando dobbiamo capire, con un cliente, se la sua internal developer platform è davvero un prodotto con utenti, owner e roadmap, oppure una raccolta di script condivisi a cui qualcuno ha dato un nome. In concreto: l’assessment sui cinque assi del modello (investment, adoption, interfaces, operations, measurement) ci porta via due o tre settimane fra interviste ai team applicativi e lettura di pipeline e repository. Il profilo che incontriamo più spesso, in organizzazioni con 5-10 team di sviluppo serviti da un gruppo piattaforma di 3-4 persone, è un livello 2 (Operational) tirato su da interfaces e operations, con adoption ancora a livello 1 e measurement praticamente assente: la piattaforma funziona, ma l’onboarding dipende da una singola persona e nessuno sa quanti team la usino davvero. È lì che la conversazione smette di riguardare gli strumenti e inizia a riguardare chi risponde della piattaforma. Backstage, donato da Spotify, resta il progetto di riferimento della categoria.
Orientarsi nel mondo Cloud Native: Landscape, Trail Map e Radar
La CNCF ha sviluppato anche degli strumenti per mappare le tecnologie cloud che rientrano all’interno del suo ambito di attività: il Cloud Native Landscape e la Cloud Native Trail Map. Le due “mappe”, assieme alle DevStats su GitHub, permettono di catalogare in maniera completa le tecnologie Cloud Native e forniscono indicazioni sugli obiettivi e gli usi di ciascuna. Un servizio particolarmente utile considerando che è facile sentirsi confusi o sopraffatti quando si deve scegliere quale tecnologia implementare nel proprio progetto.
Il CNCF Technology Radar, lanciato nel 2020 come guida trimestrale sulle tecnologie emergenti selezionate dagli esperti della fondazione, non viene più aggiornato con quella cadenza: l’indirizzo oggi porta alla sezione report della CNCF, dove le analisi periodiche hanno preso il posto del radar. Anche la Trail Map ha perso centralità, mentre il Landscape interattivo è diventato lo strumento di consultazione principale: filtri per categoria, livello di maturità e licenza permettono di attraversare centinaia di progetti e soluzioni commerciali senza passare da una mappa statica.
PER APPROFONDIRE: Come leggere il Cloud Native Landscape
Gli eventi organizzati dalla CNCF
Tra le iniziative della CNCF ci sono anche due eventi che si svolgono in contemporanea: KubeCon e CloudNativeCon. Sono di fatto diventati gli eventi più importanti per chi si occupa di tecnologia e di business in ambito Cloud Native. Occasioni di confronto tra professionisti, aggiornamenti tecnologici e trend del mercato: al KubeCon e al CloudNativeCon si fa la storia del Cloud Native.
I due eventi si tengono a rotazione in parti diverse del mondo tre volte all’anno. Dopo le edizioni virtuali del 2020 e 2021, KubeCon + CloudNativeCon è tornata in presenza: oggi il calendario alterna Nord America, Europa e Asia, con formati ibridi ormai consolidati che affiancano alle sessioni in sala lo streaming e i contenuti on demand.
Le certificazioni della CNCF: dai fondamentali agli esami su cluster reale
Il programma di certificazione è forse l’attività della CNCF con l’impatto più diretto sul mercato, perché riguarda tanto le aziende quanto le persone che lavorano con le tecnologie Cloud Native, a partire da Kubernetes. Il Certified Kubernetes Conformance Program raccoglie oggi oltre un centinaio di distribuzioni e piattaforme conformi; sul fronte delle organizzazioni valgono invece i programmi Kubernetes Training Partner (KTP) e Kubernetes Certified Service Provider (KCSP).
Il percorso individuale, nel frattempo, si è articolato su più livelli. Chi si affaccia oggi all’ecosistema non trova più soltanto CKA e CKAD: il catalogo si è allargato fino a coprire i singoli progetti Graduated e Incubating, con esami a risposta multipla dedicati a Prometheus, Argo, Istio, Cilium, OpenTelemetry e GitOps. È un segnale della maturità raggiunta da quei progetti, che hanno ormai una base di adozione sufficiente a giustificare un percorso formativo autonomo.
| Livello | Sigla | Focus | Formato d’esame |
|---|---|---|---|
| Associate | KCNA | Fondamenti di Kubernetes, container, architettura cloud native | Risposta multipla |
| Associate | KCSA | Threat model e sicurezza di base dei cluster | Risposta multipla |
| Associate | PCA | Prometheus, PromQL, alerting e instrumentation | Risposta multipla |
| Associate | CAPA | Argo CD, Workflows, Rollouts, Events | Risposta multipla |
| Associate | CGOA, OTCA, ICA, CCA | GitOps, OpenTelemetry, Istio, Cilium | Risposta multipla |
| Professional | CKA | Amministrazione e troubleshooting del cluster | Pratico su cluster reale |
| Professional | CKAD | Design, deploy e debug delle applicazioni | Pratico su cluster reale |
| Specialist | CKS | Hardening, supply chain, runtime security | Pratico, richiede una CKA attiva |
L’ordine suggerito dai livelli non è quello che consigliamo sempre di seguire. Uno sviluppatore che lavora già su cluster in produzione può saltare direttamente alla CKAD: la KCNA resta più utile a chi presidia ruoli non ingegneristici, dai project manager a chi scrive requisiti e capitolati e ha bisogno di un vocabolario tecnico condiviso con il team. Le associate verticali hanno senso quando il progetto usa davvero quello strumento: una CAPA su un team che non ha Argo CD nelle pipeline è tempo speso male.
La differenza sostanziale resta tra esami a risposta multipla ed esami pratici. CKA, CKAD e CKS si superano risolvendo problemi su un cluster vivo, con tempo limitato e accesso alla sola documentazione ufficiale: è questo il motivo per cui, in fase di selezione o di qualifica di un fornitore, valgono molto più di una certificazione teorica.
SparkFabrik ha conseguito le certificazioni di Certified Kubernetes Administrator (CKA) e di Certified Kubernetes Application Developer (CKAD). Inoltre, dal momento che nella nostra azienda ci sono più di 10 sviluppatori certificati Cloud Native, abbiamo ottenuto anche la certificazione di Kubernetes Certified Service Provider. Per chi opera nel mercato della trasformazione digitale in ottica Cloud Native, questi attestati provano che l’organizzazione ha le competenze tecnologiche e strategiche necessarie per pianificare e realizzare progetti secondo i principi e le best practice Cloud Native. Richiedi un appuntamento con i nostri esperti e parlaci del tuo progetto.
