Come sprecare 5 milioni di dollari in infrastrutture containerizzate

«Abbiamo creato un cluster Mesos da 70.000 nodi per i nostri sviluppatori, ma non lo useranno. Puoi aiutarmi?» Questo è stato l'inizio di una conversazione con il vicepresidente delle operazioni infrastrutturali di un'azienda molto grande e famosa. Sebbene fosse un'impresa impressionante da realizzare, si trattava anche della più grande infrastruttura containerizzata che avessi mai visto rimasta inutilizzata, né, purtroppo, si è trattato di un incidente isolato

Ho parlato di questo incontro con un gran numero di clienti, analisti, amici, colleghi, partner, venture capitalist e concorrenti. Abbiamo tutti espresso esperienze simili e tutti volevamo sapere perché è così. Dopotutto, se nel nostro settore si sprecano così tante risorse, stiamo tutti rischiando molto non comprendendo e risolvendo il problema. Altrimenti, la prossima ondata di utenti potrebbe iniziare a dubitare che i contenitori possano aiutare le loro aziende e dovremmo tutti iniziare a

Devo essere onesto: sono uno sviluppatore, un ingegnere e un tecnologo che ama creare prodotti e utilizzare le tecnologie più recenti. Quindi, il primo posto che ho cercato, nella mia ricerca di una risposta a questa domanda di 70.000 nodi, sono state le tecnologie utilizzate. Mesos era la tecnologia sbagliata? È stata implementata nel modo sbagliato? Hanno usato l'open source o il codice chiuso? È stato coinvolto un SI? Mi sono venute in mente per prime domande come queste. Col senno di poi penso che quelle fossero probabilmente le domande sbagliate

La risposta mi è venuta quando ho ricordato un giorno della mia carriera di 15 anni fa: seduti alla mia scrivania come sviluppatore in una grande banca, ricordo che venditori vestiti in modo impeccabile entravano e uscivano nelle nostre sale riunioni, corteggiando il nostro vicepresidente dell'infrastruttura e il suo team. Provenivano da VMware, all'epoca l'azienda produttrice di infrastrutture virtualizzate. Ero solo uno sviluppatore in banca, ma nemmeno il mio capo, il suo capo e nemmeno il capo del suo capo erano invitati a nessuna delle cene steakhouse organizzate dai dipendenti di VMware quasi ogni settimana. I venditori di VMware erano interessati solo ai decisori operativi e infrastrutturali. Due o tre mesi dopo, al nostro team è stato comunicato che era stato firmato un accordo con VMware e che avremmo trasferito presto i nostri servizi alle VM, e poco dopo questo trasferimento è avvenuto nel

Poi, un lunedì mattina, i servizi di cui era responsabile il mio team funzionavano su macchine virtuali anziché sui vecchi server bare metal con luci blu lampeggianti e ventole rumorose. Questo era tutto. La nostra intera infrastruttura è stata virtualizzata nel giro di pochi mesi senza che gli sviluppatori dicessero molto, e mentre facevamo finta di opporre resistenza a questo cambiamento (e dopo tutto, a chi piace il cambiamento?) e accettando a malincuore di rimanere in standby per un paio di fine settimana, non riuscivamo davvero a capire la differenza tra la vecchia e la nuova configurazione: era tutto uguale. I nostri server VM si comportavano e sembravano server «reali». Sono sicuro che non saremmo stati in grado di capire la differenza in un test in doppio cieco se qualcuno ne avesse condotto

Ricordando quei giorni mi sono chiesto perché la nuova ondata di cambiamento delle infrastrutture containerizzate non funzioni allo stesso modo. Perché non possiamo creare un cluster Mesos o Kubernetes in uno o due fine settimana e inviare un promemoria agli sviluppatori con l'oggetto: «Benvenuti nel futuro dell'infrastruttura. Prego

La risposta, come tutti sappiamo, è che la containerizzazione non funzionerà senza il coinvolgimento e l'acquisto degli sviluppatori. Gli sviluppatori devono creare applicazioni per una configurazione containerizzata, ma è fondamentale per sviluppatori e operatori cambiare il modo in cui lavorano e comunicano tra loro grazie alle API come Kubernetes esposte lungo tutto il ciclo di vita del software. Il motivo per cui abbiamo creato un cluster brillante da 70.000 nodi che esegue Tumbleweed anziché applicazioni aziendali è che gli strumenti che abbiamo creato per questa nuova transizione non stanno affrontando questo cambiamento organizzativo fondamentale ed essenziale, la fusione di sviluppatori e operativi. La realtà interessante è che la creazione di un'infrastruttura containerizzata sta diventando sempre più semplice, in quanto vi è un'abbondanza di soluzioni open source che consentono di iniziare a utilizzare un cluster Kubernetes. Se utilizzi già un importante provider di servizi cloud, ti bastano un paio di clic per avere il tuo cluster containerizzato, gestito, assistito e fatturato di minuto in minuto. I vantaggi della gestione di un'infrastruttura containerizzata sono visibili ai team operativi: server a configurazione singola (niente più «fiocchi di neve»), elevata disponibilità e resilienza integrate e migliore utilizzo delle risorse, solo per citarne alcuni. Gli sviluppatori vedono anche il valore dell'esecuzione in una configurazione containerizzata: maggiore influenza sull'ambiente di esecuzione, migliore controllo su librerie e dipendenze e riduzione del divario tra ambienti di produzione e sviluppo sono alcuni di questi. Ciascun aspetto di questa equazione (sviluppatori e operativi) ha i propri fornitori, strumenti e progetti open source per aiutarli con ciò che serve per passare a un mondo containerizzato, ma non è sufficiente. Ci manca ancora il framework che consenta a sviluppatori e operatori di lavorare insieme per rendere tutto questo un successo. Sono semplicemente pochissimi, se non nessuno, gli strumenti e le tecnologie disponibili che facilitano questa comunicazione

Siamo tutti così concentrati sulle nostre singole aree di innovazione, dalla rete allo storage e all'orchestrazione, che possiamo perdere la concentrazione sul raggiungimento degli obiettivi aziendali da parte dei nostri clienti. In un ambiente del genere, le società di integratori di sistemi, consulenza e servizi professionali ottengono buoni risultati, poiché sono le uniche a concentrarsi sul risultato e sulla fornitura lungo tutta la catena di fornitura del software, ma questo non è sostenibile. Le tecnologie che richiedono ai clienti di pagare così tanto in consulenze per farle funzionare non saranno tecnologie rivoluzionarie. Ammettiamolo: se la virtualizzazione avesse bisogno che McKinsey fosse sempre presente nelle buste paga perché funzioni, oggi non ci sarebbe il

Affinché tutti possiamo trarre vantaggio da una tecnologia rivoluzionaria come la containerizzazione delle infrastrutture, dobbiamo pensare in modo più ampio rispetto ai nostri strumenti monouso o alle aree di interesse principali e ripensare il modo in cui creiamo prodotti per questo settore. Questo è diverso dalla rivoluzione della virtualizzazione e del cloud e quanto prima ce ne rendiamo conto, tanto maggiori saranno i vantaggi per i nostri clienti

Devops non è solo un insieme di strumenti frammentati o un elegante progetto di «trasformazione digitale», è un metodo per lavorare in modo collaborativo tra le funzioni, reso possibile dalla tecnologia. Pertanto, qualsiasi tecnologia destinata al mercato devops, in particolare per quanto riguarda la containerizzazione, deve anche affrontare la mentalità della collaborazione continua prima di ogni altra cosa. Quindi, creiamo tutti prodotti con questo in mente per avviare e mantenere una conversazione tra sviluppatori e

Questo post è stato pubblicato per la prima volta qui