È possibile racchiudere l’universo Cloud Native in un’unica pagina web? La CNCF lo ha fatto con il Cloud Native Landscape: vediamo come interpretarlo e cosa include.
Quando si entra nel mondo del Cloud Native è impossibile non imbattersi nel CNCF Cloud Native Landscape. Si tratta di una sorta di mappa estremamente articolata e densa, dalle dimensioni mastodontiche e di difficile lettura, che cambia profilo costantemente e a velocità impressionanti. E infatti, la reazione istintiva è quella di chiudere e fuggire.
Quindi come affrontarla? E perché farlo? A cosa serve, in fin dei conti?
Cerchiamo di destrutturarla e interpretarla in questo post.
Cos’è la CNCF?
La Cloud Native Computing Foundation ha come obiettivo rendere il Cloud Native universale e sostenibile, promuovendo le applicazioni e i servizi creati nativamente per il cloud, con una netta predilezione per l’open source e proponendosi come uno spazio neutrale indipendente dai vendor.
Rimane all’interno della Linux Foundation, fondazione no-profit. SparkFabrik è tra i primi ad aver aderito degli attuali sei silver member italiani.
A cosa serve il Cloud Native Landscape?
La mappa del landscape Cloud Native mira a raccogliere tutte le soluzioni Cloud Native esistenti, che siano progetti open source o prodotti proprietari, cercando di organizzarli per categorie.
La CNCF, tra le altre cose, funge da incubatore di progetti open source, che nella mappa sono rappresentati da riquadri più grandi. Alcuni si trovano ancora in fase di incubazione, altri sono stati promossi a tutti gli effetti (graduated). Gli altri riquadri più piccoli rappresentano progetti open source se hanno uno sfondo bianco e prodotti proprietari se hanno sfondo grigio.
Com’è strutturato il CNCF Landscape?
La mappa è organizzata secondo precise categorie e sottocategorie. Proviamo ad elencarle e a spiegarle in poche parole.
Una curiosità, prima di cominciare. Nel momento in cui scriviamo questo articolo, la mappa contiene 941 elementi, per un totale di oltre 2 milioni e 600 mila stelle (un modo di valorizzare un progetto sulla piattaforma di sviluppo per eccellenza, GitHub) e un finanziamento globale di 17.3 miliardi di dollari.
PROVISIONING
- Automation and Configuration
- Container Registry
- Security & Compliance
- Key Management
RUNTIME
- Cloud Native Storage
- Container Runtime
- Cloud Native Network
ORCHESTRATION & MANAGEMENT
- Scheduling & Orchestration
- Coordination & Service Discovery
- Remote Procedure Call
- Service Proxy
- API Gateway
- Service Mesh
APP DEFINITION AND DEVELOPMENT
- Database
- Streaming & Messaging
- Application Definition & Image Build
- Continuous Integration & Delivery
Vediamo queste categorie una per una.
PROVISIONING
Il provisioning ha come obiettivo gettare le fondamenta delle piattaforme e applicazioni Cloud Native. In quest’area sono raccolti tool che permettono:
- la creazione, configurazione e gestione delle infrastrutture;
- lo scanning e lo storing delle immagini container;
- la gestione della sicurezza con embedded authorization e authentication;
- la distribuzione dei secrets.
RUNTIME
Salendo di un livello, troviamo le soluzioni runtime che includono tutto ciò che serve ad un container per funzionare in un ambiente Cloud Native. D’altronde, il container crede di essere solo nell’ambiente in cui gira e non è consapevole di condividere risorse con altri.
In questa categoria si trovano dunque tutti i tool necessari per gestire il lifecycle di un container, per permettergli di archiviare dati da conservare anche quando l’app viene fatta ripartire (rendere i dati persistenti) e per aiutarlo a comunicare con altri container (overlay network, una rete sopra la rete).
ORCHESTRATION & MANAGEMENT
Abbiamo gettato le basi con un’infrastruttura solida e sicura, abbiamo aiutato i container ad autodefinirsi, ad avere le risorse necessarie per funzionare e a comunicare con gli altri container: a questo punto è necessario gestire più servizi indipendenti containerizzati.
Salendo di un livello nella mappa del landscape, infatti, si trovano tutti i tool per orchestrare e schedulare i container in cluster (un insieme di macchine fisiche o virtuali connesse in un network). In quest’area rientrano anche tutti i servizi di discovery, coordinamento, proxy e mesh. La loro funzione è far sì che i servizi riescano a trovarsi vicendevolmente e a comunicare in modo efficace perché funzionino come un unico applicativo coeso.
A completare lo scenario troviamo gli API gateways che aumentano la possibilità di controllo della comunicazione, soprattutto con applicativi esterni.
APPLICATION DEFINITION AND DEVELOPMENT
I primi tre livelli del landscape mirano a costruire un ambiente solido, sicuro, completo di tutte le dipendenze necessarie. Siamo pronti ad affrontare i tool che permettono agli sviluppatori di costruire effettivamente i loro applicativi.
Dai database allo streaming e messaggistica tra servizio e servizio in architetture decoupled o coreografate, fino alle tecnologie di application definition e image build che permettono un’esperienza migliorata per gli sviluppatori. Senza dimenticare la rivoluzionaria CI/CD che anticipa i possibili errori agli engineers, così da intervenire in continuum innalzando la qualità del codice deployato.
Ma la mappa non si conclude qui.
Abbiamo altre colonne sulla destra: Observability & Analysis e Platform.
OBSERVABILITY E ANALISI
L’osservabilità è la caratteristica di un sistema che descrive il grado con cui esso può essere osservato e compreso partendo dai suoi output e risultati. Si parla di CPU time memory, spazio disco, latenza, errori, ecc. A seconda di quanto questi dati siano misurabili, un sistema è più o meno osservabile.
L’analisi è quell’attività che riesce a dare senso e interpretazioni ai dati rilevati e osservati. Un alto grado di osservabilità e una costante attenta analisi sono due fattori che permettono di rilevare anomalie in tempi opportuni e di porre loro rimedio immediatamente evitando interruzioni di servizio.
In questa categoria del landscape sono raccolti tool e servizi di logging, monitoring, tracing e chaos engineering.
PLATFORM
Le piattaforme non propongono nulla in più di quanto i tool facciano singolarmente, ma indubbiamente facilitano il lavoro dei team di sviluppo che in un unico spazio trovano raggruppati tutti gli strumenti necessari ai diversi livelli del processo di creazione. Molte aziende optano per costruirsi questo tipo di piattaforma in-house, ma si tratta di un impegno importante, che richiede un team dedicato e know-how.
Per la maggior parte delle organizzazioni, invece, soprattutto se con team di sviluppo piccoli, adottare piattaforme esistenti risulta essere l’unico modo per affrontare un percorso Cloud Native sostenibile.
Si noterà che praticamente tutte le piattaforme sono basate su Kubernetes, e non è un caso: Kubernetes è e rimane il cuore di tutto lo stack Cloud Native.
Scritto daSparkFabrik Team
