«Abbiamo creato un cluster Mesos da 70.000 nodi per i nostri sviluppatori, ma non lo useranno. Può aiutarmi?» Questo è stato l'inizio di una conversazione con il vicepresidente delle operazioni infrastrutturali di un'azienda molto grande e famosa. Sebbene sia stata un'impresa impressionante da realizzare, è stata anche di gran lunga la più grande configurazione di infrastruttura containerizzata che avessi visto rimasta inutilizzata, né, purtroppo, è stato 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 così tante risorse vengono sprecate nel nostro settore, rischiamo tutti 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 perfezionare i nostri curriculum
.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 in cui ho cercato di trovare una risposta a questa domanda di 70.000 nodi sono state le tecnologie utilizzate. Mesos era la tecnologia sbagliata? È stato implementato nel modo sbagliato? Hanno usato open source o closed source? C'era un SI coinvolto? Domande come queste mi sono venute in mente per prime. Col senno di poi penso che 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, corteggiavano il nostro vicepresidente dell'infrastruttura e il suo team. Erano di VMware, all'epoca l'azienda per l'infrastruttura virtualizzata. Ero solo uno sviluppatore in banca, ma nemmeno il mio capo o il suo capo o nemmeno il capo del suo capo erano invitati a nessuna delle cene steakhouse che i dipendenti di VMware organizzavano quasi ogni settimana. I venditori di VMware erano interessati solo ai decisori operativi e infrastrutturali. Due o tre mesi dopo, al nostro team è stato detto che era stato firmato un accordo con VMware e che presto avremmo trasferito i nostri servizi alle VM, e poco dopo questo trasferimento è avvenuto nel giro di un paio
di fine settimana.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 opponevamo una falsa resistenza a questo cambiamento (e a chi piace il cambiamento dopo tutto?) e accettando a malincuore di rimanere in attesa per un paio di fine settimana, non siamo riusciti 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 uno
.Ricordando quei giorni mi sono chiesto perché la nuova ondata containerizzata di modifiche all'infrastruttura non funzioni allo stesso modo. Perché non possiamo creare un cluster Mesos o Kubernetes in un fine settimana o due e inviare un promemoria agli sviluppatori con l'oggetto: «Benvenuto nel futuro dell'infrastruttura. Prego!»?
La risposta, come tutti sappiamo, è che la containerizzazione non funzionerà senza il coinvolgimento e il consenso degli sviluppatori. Gli sviluppatori devono creare applicazioni per una configurazione containerizzata, ma è intrinseco ai contenitori, con API come Kubernetes esposte durante tutto il ciclo di vita del software, per sviluppatori e operatori cambiare il modo in cui lavorano e comunicano tra loro. Il motivo di 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 combinazione di sviluppatori e operativi. La realtà interessante è che la configurazione di un'infrastruttura containerizzata sta diventando più semplice, poiché ci sono molte soluzioni open source che La rendono operativa con un cluster Kubernetes. Se utilizza già un importante fornitore di servizi cloud, le bastano un paio di clic per avere il suo 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»), alta 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. Ogni 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 renderlo 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 dei loro obiettivi aziendali da parte dei nostri clienti. In un ambiente del genere, le società di integratori di sistemi, consulenza e servizi professionali fanno bene, poiché sono le uniche a concentrarsi sul risultato e sulla fornitura in tutta la catena di fornitura del software; ma questo non è sostenibile. Le tecnologie che richiedono che i clienti paghino così tanto alle 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
cloud.Affinché tutti noi possiamo beneficiare di 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 costruiamo prodotti per questo settore. Questo è diverso dalla rivoluzione della virtualizzazione e del cloud e prima ce ne rendiamo conto, 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, abilitato 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 operatori.
Questo post è stato pubblicato per la prima volta qui