Quale è la considerazione degli sviluppatori cloud-native nei confronti di Kubernetes?

2

Sebbene possa sembrare scontato, Kubernetes non vuol dire cloud-native. O meglio, Kubernetes è certamente uno strumento cloud-native, proprio perché il significato di questa parola tanto in voga, stando alla definizione data dalla CNCF (Cloud Native Computing Foundation), è sostanzialmente “tutto quello che è scalabile, automatizzato e viaggia su cloud pubblici o privati”.

Ma tra gli sviluppatori che lavorano nell’ambito cloud-native, quanti sono quelli che utilizzano e conoscono Kubernetes? La risposta la racconta uno studio di Slashdata presentato alla recente Kubecon e raccontato da devclass.com, uno studio che ha utilizzato proprio la definizione di cloud-native che abbiamo raccontato poco sopra, per fare tutti i distinguo del caso all’interno del bacino di diciannovemila sviluppatori intervistati.

Secondo il rapporto, il numero di sviluppatori che utilizzano i container è cresciuto da 9 a 10 milioni e mezzo in un anno, numeri che però se vengono ristretti agli sviluppatori cloud-native si riducono, da 6,1 milioni a 7,1 milioni. Di questi solo 4,8 milioni degli attuali intervistati utilizza strumenti di orchestrazione o piattaforme di gestione, gli altri usano direttamente le funzioni cloud o architetture serverless.

Gli sviluppatori cloud-native utilizzano più ambienti cloud rispetto ai programmatori “in generale”, il che è abbastanza scontato: come potrebbe uno sviluppatore cloud-native non utilizzare il cloud?

Eppure dal rapporto emerge come circa il 43% utilizza server on-premise, che significa lasciare il 52% ad utilizzare il cloud pubblico, il 41% quello privato e il 22% quello multi-cloud (se non vi torna la matematica è perché gli intervistati potevano selezionare più opzioni).

In tutto questo, come fanno notare da devclass.com, val la pena ricordare come l’attendibilità dei sondaggi vada presa con le pinze, poiché molto dipende da come vengono formulate le domande e quelle di questo studio si riferiscono al concetto di cloud-native.

Tutti i big cloud three, ossia AWS, Microsoft e Google, dominano il mercato e tutti e tre hanno una quota sostanziale. Nello specifico in merito agli strumenti di orchestrazione la distribuzione è questa:

  • 24% per Amazon Elastic Container Service (ECS)
  • 21% per Google Kubernetes Engine (GKE)
  • 19% per Amazon Elastic Kubernetes Service (EKS)
  • 18% per Microsoft Azure Kubernetes Service (AKS)

Il che nella sostanza stabilisce come il primato rimanga ad Amazon, almeno in termini di orchestrator.

Rilevante anche l’aspetto relativo all’uso di strumenti di orchestrazione interni o self-hosted, che è cresciuto anno dopo anno, dal 27% al 30%, e che dimostra come ormai il livello di accessibilità delle tecnologia sia molto alto, a dispetto dell’oggettiva complessità.

È interessante poi non trovare riferimenti ad OpenShift, strumento comunque offerto dalle piattaforme cloud.

Insomma, dati e numeri che avvicinano un poco alla comprensione di questo mondo tra le nuvole, complicato ed allo stesso tempo affascinante.

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.

2 risposte a “Quale è la considerazione degli sviluppatori cloud-native nei confronti di Kubernetes?”

  1. Avatar Alessio Carotenuto

    È interessante poi non trovare riferimenti ad OpenShift, strumento comunque offerto dalle piattaforme cloud.

    Secondo voi qual è il motivo?

  2. Avatar Raoul Scarazzini

    È una buona domanda e penso i motivi siano più di uno.
    Buona parte dei plus offerti da OpenShift, come ad esempio gli oggetti Route, è offerto già da tutte le soluzioni Kubernetes descritte nell’articolo. Aggiungici che chi usa una piattaforma cloud per erogare i propri servizi non vuole includerci anche tutta la fase di ciclo di sviluppo, cosa anche qui offerta da OpenShift con le BuildConfig, ma ha già una base di automazioni che vive sul cloud.
    Se a tutto questo si somma la sovra-complessità implicita di OpenShift il gioco è fatto.
    Discorso diverso riguarda l’ambito on-premise, ma sul cloud credo le ragioni siano queste.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *