In previsione di Vitaliy Khabarov ha intervistato Dmitrij Stolyarov (), direttore tecnico e co-fondatore dell'azienda «Flant». Vitaliy ha chiesto a Dmitrij cosa fa «Flant», di Kubernetes, dello sviluppo dell'ecosistema e del supporto. Hanno discusso del perché Kubernetes sia utile e se serva davvero. Inoltre, hanno parlato di microservizi, Amazon AWS, dell'approccio «Mi sentirò fortunato» nel DevOps, del futuro di Kubernetes, perché, quando e come conquisterà il mondo, delle prospettive del DevOps e di cosa si devono preparare gli ingegneri nel prossimo e luminoso futuro con semplificazioni e reti neurali.
in formato podcast può essere ascoltata su DevOps DeFlop — il podcast in lingua russa su DevOps, e qui sotto trovate la versione testuale.
Qui e di seguito le domande sono poste da un ingegnere di Express42.
Su «Flant»
— Dima, ciao. Tu sei il direttore tecnico di «» e anche il suo fondatore. Raccontaci, per favore, cosa fa l'azienda e tu in essa?
Dmitrij: Dall'esterno sembra che siamo quei ragazzi che vanno in giro a installare Kubernetes e a fare qualcosa con esso. Ma non è così. Siamo partiti come azienda che si occupava di Linux, ma da molto tempo la nostra attività principale consiste nell'assistenza a progetti di produzione e highload chiavi in mano. Di solito costruiamo tutta l'infrastruttura da zero e poi per molto tempo ce ne assumiamo la responsabilità. Pertanto, il lavoro principale che fa «Flant», per cui viene pagato, è prendersi la responsabilità e realizzare la produzione chiavi in mano.
Io, come direttore tecnico e uno dei fondatori dell'azienda, lavoro giorno e notte per inventare come aumentare la disponibilità della produzione, semplificare la sua gestione, rendere la vita degli amministratori più facile e quella dei programmatori più piacevole.
Su Kubernetes
— Ultimamente da «Flant» vedo molte relazioni e sul Kubernetes. Come ci siete arrivati?
Dmitrij: Ne ho già parlato molte volte, ma non mi dispiace ripeterlo. Penso che sia giusto ripetere quest'argomento, perché c'è confusione tra causa ed effetto.
Avevamo davvero bisogno di uno strumento. Ci siamo imbattuti in una miriade di problemi, abbiamo lottato, superato le difficoltà con vari espedienti e sentivamo la necessità di uno strumento. Abbiamo esplorato molte opzioni diverse, costruito le nostre soluzioni, accumulato esperienza. Gradualmente siamo arrivati al punto di iniziare a utilizzare Docker quasi subito dopo la sua apparizione, intorno al 2013. Al momento del suo arrivo, avevamo già una significativa esperienza con i container, avevamo già scritto un nostro equivalente di "Docker" — alcuni espedienti in Python. Con l'arrivo di Docker, è diventata possibile eliminare gli espedienti ed utilizzare una soluzione affidabile e supportata dalla comunità.
La storia con Kubernetes è simile. Quando ha iniziato a guadagnare terreno — per noi è la versione 1.2 — avevamo già una moltitudine di espedienti sia in Shell che in Chef, con i quali tentavamo di orchestrare Docker. Abbiamo preso in considerazione seriamente Rancher e diverse altre soluzioni, ma poi è arrivato Kubernetes, che è realizzato esattamente come lo avremmo fatto noi, o addirittura meglio. Non c'era nulla di cui lamentarsi.
Sì, ci sono alcune opere incomplete qui e là — molte cose non completate, e la 1.2 è davvero spaventosa, ma... Kubernetes è come un edificio in costruzione: guardi il progetto e capisci che sarà fantastico. Se l'edificio ha già una base e due piani, capisci che è meglio non trasferirsi ancora, ma nel software non ci sono problemi del genere — è già utilizzabile.
Non abbiamo mai avuto un momento in cui ci siamo chiesti se utilizzare Kubernetes o meno. Lo aspettavamo da molto prima che apparisse e tentavamo di costruire analoghi.
Circa Kubernetes
— Partecipate direttamente allo sviluppo del Kubernetes stesso?
Dmitrij: In modo indiretto. Partecipiamo piuttosto allo sviluppo dell'ecosistema. Inviamo un certo numero di pull requests: in Prometheus, in vari operatori, in Helm — nell'ecosistema. Sfortunatamente, non sono in grado di tenere traccia di tutto ciò che facciamo e potrei commettere errori, ma non abbiamo alcuna pull request in kernel.
— Allo stesso tempo, sviluppate anche molti dei vostri strumenti attorno a Kubernetes?
Dmitrij: La strategia è questa: andiamo e facciamo pull request su tutto ciò che esiste già. Se le pull request non vengono accettate, semplicemente le fork e viviamo finché non vengono accettate con i nostri build. Poi, quando questo arriva all'upstream, torniamo indietro alla versione upstream.
Ad esempio, abbiamo un operatore Prometheus con cui abbiamo fatto su e giù rispetto all'upstream della nostra build già 5 volte, probabilmente. Abbiamo bisogno di una funzionalità, abbiamo inviato una pull request, dobbiamo rilasciarla domani, e non vogliamo aspettare che venga rilasciata nell'upstream. Pertanto, ci creiamo la nostra build con la funzionalità di cui abbiamo bisogno e la distribuiamo a tutti i nostri cluster. Poi, ad esempio, nell'upstream ci dicono: "Ragazzi, facciamo in modo che funzioni per un caso più generale", e noi, o qualcun altro, lo completiamo, e col tempo viene di nuovo unito.
Cercando di sviluppare tutto ciò che esiste. Molti elementi che non esistono ancora, che non sono stati ancora inventati o che sono stati inventati ma non sono stati realizzati, li stiamo facendo. E non perché ci piaccia il processo stesso o la costruzione di biciclette come settore, ma semplicemente perché abbiamo bisogno di questo strumento. Spesso ci chiedono perché abbiamo creato quella o quell'altra cosa? La risposta è semplice: perché avevamo bisogno di andare avanti, di risolvere qualche problema pratico, e abbiamo risolto quel problema con questo strumento.
Il percorso è sempre lo stesso: cerchiamo molto attentamente e, se non troviamo alcuna soluzione su come trasformare una pagnotta di pane in un filobus, allora facciamo la nostra pagnotta e il nostro filobus.
Strumenti di Flant
— So che attualmente Flant ha operatori add-on, operatori shell e strumenti dapp/werf. Da quanto capisco, si tratta dello stesso strumento in incarnazioni diverse. Inoltre, capisco che all'interno di Flant ci sono molti altri strumenti diversi. È così?
Dmitrij: Su GitHub abbiamo ancora molte altre cose. Tra quelle che riesco a ricordare, abbiamo statusmap — un pannello per Grafana, che è stato apprezzato da tutti. Viene menzionato quasi in ogni secondo articolo sul monitoraggio di Kubernetes su Medium. È impossibile descrivere brevemente cos'è lo statusmap — serve un articolo a parte, ma è uno strumento molto utile per monitorare lo stato nel tempo, poiché in Kubernetes è spesso necessario mostrare lo stato nel tempo. Abbiamo anche LogHouse — una soluzione basata su ClickHouse e magia nera per la raccolta di log in Kubernetes.
Molti strumenti! E ce ne saranno ancora di più, poiché un certo numero di soluzioni interne sarà rilasciato quest'anno. Tra i grandi, ci sono molti addon per Kubernetes, come ad esempio come installare correttamente il sert manager – uno strumento per la gestione dei certificati, o come installare Prometheus con un sacco di accessori – si tratta di circa venti binari diversi che esportano dati e raccolgono informazioni. A questo si aggiungono grafica e avvisi straordinari di Prometheus. Tutti questi sono semplicemente moltissimi addon per Kubernetes, che vengono installati nel cluster, trasformandolo da semplice a avanzato, automatizzato, in cui molte questioni sono già risolte. Sì, facciamo davvero molto.
Sviluppo dell'ecosistema
— Mi sembra che questo sia un contributo molto significativo allo sviluppo di questo strumento e alle sue modalità di utilizzo. Puoi provare a stimare chi potrebbe contribuire in modo simile allo sviluppo dell'ecosistema?
Dmitrij: In Russia, tra le aziende che operano nel nostro mercato, non c'è nessuno anche lontanamente. Certo, è un'affermazione audace, perché ci sono grandi attori come Mail e Yandex che stanno facendo qualcosa con Kubernetes, ma anche loro non si avvicinano al contributo delle aziende a livello mondiale, che stanno facendo molto di più di noi. È difficile confrontare "Flant" con uno staff di 80 persone e Red Hat, che ha solo per Kubernetes 300 ingegneri, se non sbaglio. È difficile fare un confronto. Nel nostro dipartimento RnD ci sono 6 persone, me compreso, che sviluppano tutti i nostri strumenti. 6 persone contro 300 ingegneri di Red Hat – non è semplice fare un paragone.
— Tuttavia, quando anche solo questi 6 possono creare qualcosa di realmente utile e trasferibile, quando affrontano un problema pratico e forniscono una soluzione alla comunità – è un caso interessante. Capisco che nelle grandi aziende tecnologiche, dove ci sono sviluppatori e team di supporto per Kubernetes, potrebbero in linea di principio essere sviluppati strumenti simili. Questo è un esempio per loro di ciò che è possibile sviluppare e condividere con la comunità, dando impulso a tutta la comunità che utilizza Kubernetes.
Dmitrij: Probabilmente è una caratteristica dell'integratore, una sua peculiarità. Noi abbiamo molti progetti e vediamo molte situazioni diverse. Per noi, il modo principale per creare valore aggiunto è analizzare questi casi, trovare punti in comune e minimizzare i costi per noi. Su questo ci dedichiamo attivamente. È difficile per me parlare della Russia e del mondo, ma abbiamo circa 40 ingegneri DevOps in azienda che si occupano di Kubernetes. Non penso che ci siano molte aziende in Russia con un numero comparabile di specialisti che conoscono Kubernetes, se ci sono davvero.
Capisco tutto riguardo al titolo di DevOps engineer, tutti lo capiscono e si sono abituati a chiamare DevOps engineer DevOps engineer, non discuteremo di questo. Questi 40 straordinari ingegneri DevOps affrontano problemi ogni giorno e li risolvono, noi analizziamo semplicemente questa esperienza e cerchiamo di generalizzare. Comprendiamo che se questa conoscenza rimane al nostro interno, dopo un anno o due lo strumento diventa inutile, perché da qualche parte nella community apparirà uno strumento pronto. Non ha senso accumulare questa esperienza all'interno—è solo uno spreco di energia e tempo in dev/null. Così, non ci dispiace affatto. Pubblicizziamo tutto con grande piacere e capiamo che è necessario pubblicare, sviluppare, promuovere, far girare affinché la gente lo utilizzi e aggiunga le proprie esperienze—così tutto cresce e vive. Allora, dopo due anni, lo strumento non finisce nella spazzatura. Non ci dispiace continuare a investire energie, perché è evidente che qualcuno utilizza il tuo strumento, e dopo due anni lo usano già tutti.
Questa è parte della nostra grande strategia con dapp/werf. Non ricordo quando abbiamo iniziato a realizzarlo, sembra circa 3 anni fa. Inizialmente era completamente in shell. Era un super proof of concept, abbiamo risolto alcune delle nostre specifiche problematiche—e ci siamo riusciti! Ma con lo shell ci sono dei problemi, non è possibile svilupparlo ulteriormente, programmare in shell è un'occupazione piuttosto complicata. Avevamo l'abitudine di scrivere in Ruby e quindi abbiamo rifatto alcune cose in Ruby, sviluppato, sviluppato, sviluppato, e ci siamo scontrati con il fatto che la community, il gruppo che non dice Lo strumento DevOps deve essere un binario statico. Su Go o non su Go non è così importante, ma è meglio un binario statico scritto in Go.
Abbiamo investito risorse, riscritto il dapp in Go e lo abbiamo chiamato werf. Il dapp non è più supportato, non è in sviluppo, funziona con una sorta di ultima versione, ma c'è un assoluto percorso di upgrade, e si può seguirlo.
Perché è stato creato il dapp
— Puoi spiegare brevemente perché è stato creato il dapp, quali problemi risolve?
Dmitrij: La prima ragione riguarda il processo di build. Inizialmente avevamo seri problemi con la build, quando Docker non supportava il multi-stage, e abbiamo realizzato il multi-stage da soli. Poi avevamo anche molte domande sulla pulizia delle immagini. Tutti coloro che fanno CI/CD, prima o poi, si imbattono nel problema di avere un sacco di immagini create, è necessario trovare un modo per pulire ciò che non serve e mantenere ciò che serve.
La seconda ragione riguarda il deploy. Sì, esiste Helm, ma risolve solo parte dei problemi. È strano, ma c'è scritto che "Helm è il Package Manager per Kubernetes". Esattamente, "il". Ci sono anche le parole "Package Manager" — quali aspettative abbiamo di solito da un Package Manager? Diciamo: "Package Manager, installa il pacchetto!" e ci aspettiamo che ci dica: "Pacchetto installato".
È interessante che diciamo: "Helm, installa il pacchetto", e quando risponde che l'ha installato, scopriamo che ha solo avviato l'installazione — ha indicato a Kubernetes: "Avvia questa cosa!", ma se è stata avviata o meno, se funziona o meno, Helm non risolve affatto questa questione.
Dunque, Helm è semplicemente un preprocessore testuale che carica dati in Kubernetes.
Ma noi, nel contesto di qualsiasi deploy, vogliamo sapere — l'applicazione è stata distribuita in produzione o no? Essere distribuita in produzione significa che l'applicazione è stata lanciata, è stata distribuita una nuova versione e che almeno non sta crollando e risponde correttamente. Helm non risolve affatto questo problema. Per affrontarlo, bisogna spendere molte energie, poiché è necessario dare a Kubernetes il comando di distribuire e monitorare cosa succede — se è stata distribuita o meno. E ci sono anche molti altri compiti legati al deploy, alla pulizia, alla costruzione.
Piani
Anche quest'anno ci dedicheremo allo sviluppo locale. Vogliamo arrivare a uno stato simile a quello di Vagrant: digitando "vagrant up", le nostre macchine virtuali si avviano. Vogliamo che, con un progetto su Git, sia sufficiente scrivere "werf up" per avviare una copia locale di questo progetto, distribuita in un mini-Kub locale, con tutte le directory collegate, pronte per lo sviluppo. A seconda del linguaggio di sviluppo, ciò può essere realizzato in modi diversi, ma è importante poter condurre lo sviluppo locale in modo conveniente sotto file montati.
Il prossimo passo per noi è investire molto nel comfort per gli sviluppatori. Per poter lanciare rapidamente un progetto localmente con uno strumento, svilupparlo, effettuare il push su Git e farlo uscire esattamente allo stesso modo in stage o per il testing, a seconda dei pipeline, e poi utilizzare lo stesso strumento per andare in produzione. Questa unità, unificazione e riproducibilità dell'infrastruttura, dal ambiente locale fino alla produzione, per noi è un aspetto molto importante. Ma finora non è disponibile in werf; stiamo solo pianificando di farlo.
Ma il percorso verso dapp/werf è sempre stato simile a quello di Kubernetes all'inizio. Abbiamo affrontato problemi e li abbiamo risolti con soluzioni alternative, inventando qualcosa per noi stessi su shell o su qualsiasi cosa. Poi, abbiamo cercato di rettificare, generalizzare e consolidare questi metodi in binari, che condividiamo semplicemente.
C'è anche un altro punto di vista su tutta questa storia, con delle analogie.
Kubernetes è il telaio di un'auto con il motore. Non ci sono porte, vetri, radio, albero di Natale — non c'è proprio nulla. Solo il telaio e il motore. E c'è Helm: è il volante. È fantastico avere il volante, ma servono anche il perno dello sterzo, la cremagliera, il cambio e le ruote, altrimenti non si va da nessuna parte.
Nel caso di werf, è un altro componente di Kubernetes. Solo che adesso, nella nostra versione alpha di werf, Helm si compila direttamente all'interno di werf, perché ci siamo stancati di farlo da soli. Ci sono molte ragioni per fare così; spiegherò dettagliatamente perché abbiamo incorporato completamente helm insieme a tiller dentro werf .
Attualmente werf è un componente più integrato. Otteniamo un volante finito, un perno di controllo - non sono molto esperto di automobili, ma si tratta di un grande blocco che risolve già un ampio spettro di compiti. Non dobbiamo perdere tempo a cercare nel catalogo, abbinando un pezzo all'altro e pensando a come montarli insieme. Riceviamo un combinato pronto all'uso che risolve immediatamente un gran numero di compiti. Ma all'interno è costruito con gli stessi componenti open source, utilizza Docker per le compilazioni, Helm per alcune funzionalità e ci sono anche altre librerie. È uno strumento integrato per ottenere rapidamente e facilmente un ottimo CI/CD direttamente dalla scatola.
È difficile mantenere Kubernetes?
— Parli della tua esperienza con Kubernetes, dicendo che è il vostro telaio, motore, e che si può aggiungere tanto di diverso: carrozzeria, volante, collegare i pedali, i sedili. Nasce la domanda: quanto è difficile per voi mantenere Kubernetes? Avete una ricca esperienza, quanto tempo e risorse dedicate specificamente alla manutenzione di Kubernetes a parte tutto il resto?
Dmitrij: È una domanda molto complessa e per rispondere, bisogna capire cosa significa mantenere e cosa vogliamo da Kubernetes. Potresti chiarire?
— Da quello che so e come vedo, molte squadre vogliono provare Kubernetes. Tutti si cimentano, lo installano da soli. Ho la sensazione che le persone non comprendano sempre la complessità di questo sistema.
Dmitrij: Esatto.
— Quanto è difficile prendere Kubernetes e installarlo da zero affinché sia pronto per la produzione?
Dmitrij: Cosa ne pensi, quanto è difficile trapiantare un cuore? Capisco, è una domanda compromettente. Usare un bisturi e non sbagliare non è così difficile. Se qualcuno ti dice dove tagliare e dove suturare, la procedura in sé non è complessa. È difficile garantire di volta in volta che tutto funzioni perfettamente.
Installare Kubernetes e farlo funzionare è semplice: puff! - è installato, ci sono molti modi per farlo. Ma cosa succede quando sorgono problemi?
Sorgono sempre domande: cosa non abbiamo considerato? Cosa non abbiamo fatto? Quali parametri del kernel di Linux abbiamo specificato in modo errato? Dio mio, li abbiamo specificati?! Quali componenti di Kubernetes abbiamo installato e quali no? Nascono migliaia di domande, e per rispondere a queste è necessario avere 15-20 anni di esperienza in questo settore.
Ho un esempio fresco su questo tema che può chiarire il significato del problema "È difficile mantenere Kubernetes?". Qualche tempo fa abbiamo seriamente considerato se valesse la pena implementare Cilium come rete in Kubernetes.
Spiegherò cos'è Cilium. In Kubernetes ci sono molte diverse implementazioni del sistema di rete, e una di esse è davvero fantastica: è Cilium. Qual è il suo scopo? Nel kernel, qualche tempo fa, è stata introdotta la possibilità di scrivere hook per il kernel che, in un modo o nell'altro, si inseriscono nel sistema di rete e in altri vari sistemi, consentendo di aggirare grandi parti nel kernel.
Nel kernel di Linux ci sono storicamente ip rout, netfilter, bridge e molti altri componenti datati, alcuni dei quali hanno 15, 20 o 30 anni. In generale, funzionano, è tutto fantastico, ma ora abbiamo una moltitudine di contenitori, e appare come una torre di 15 mattoni uno sopra l'altro, mentre tu ci stai sopra su una gamba - una sensazione strana. Questo sistema si è sviluppato storicamente con molte sfumature, come un'appendice nell'organismo. In alcune situazioni ci sono problemi di performance, ad esempio.
C'è un fantastico BPF e la possibilità di scrivere hook per il kernel: i ragazzi hanno scritto i loro hook per il kernel. Il pacchetto arriva nel kernel Linux, lo estraggono direttamente all'ingresso, lo elaborano come necessario senza bridge, senza TCP, senza stack IP - insomma, saltando tutto ciò che è stato scritto nel kernel di Linux, e lo sputano immediatamente nel contenitore.
Qual è il risultato? Un performance davvero impressionante, funzionalità fantastiche - semplicemente incredibile! Ma guardiamo a questo e vediamo che su ogni macchina c'è un programma che si connette all'API Kubernetes e, in base ai dati che ottiene da quest'API, genera codice C e compila i binari che carica nel kernel, affinché questi hook funzionino nello spazio del kernel.
Cosa succede se qualcosa va storto? Non lo sappiamo. Per capirlo, dobbiamo leggere tutto questo codice, comprendere tutta la logica, ed è incredibilmente complicato. D'altra parte, ci sono questi bridge, netfilter, ip rout - non ho letto i loro sorgenti, e nemmeno i 40 ingegneri che lavorano nella nostra azienda. Forse alcuni pezzi sono compresi solo da pochi.
E qual è la differenza? Risulta che ci sia ip rout, il nucleo di Linux, e ci sia un nuovo strumento: qual è la differenza? Non comprendiamo né l'uno né l'altro. Ma abbiamo paura di usare il nuovo: perché? Perché se uno strumento ha 30 anni, in 30 anni sono stati trovati tutti i bug, e non è necessario conoscere tutto: funziona come una scatola nera e funziona sempre. Tutti sanno dove infilare il cacciavite diagnostico, quale tcpdump avviare in un determinato momento. Tutti conoscono bene gli strumenti diagnostici e comprendono come funziona questo insieme di componenti nel nucleo di Linux: non come è costruito, ma come si usa.
E l'incredibile Cilium non ha 30 anni, non è ancora stato collaudato. Con Kubernetes è lo stesso, è una copia. Sia che Cilium venga installato magnificamente, sia che Kubernetes venga installato magnificamente, ma quando qualcosa va storto in produzione, sarete in grado di capire rapidamente, in una situazione critica, cosa è andato storto?
Quando parliamo di quanto sia difficile mantenere Kubernetes, no, è molto semplice, e sì, è incredibilmente complicato. Kubernetes funziona bene da solo, ma con un miliardo di sfumature.
Sull'approccio 'Spero di avere fortuna'
— Esistono aziende dove è quasi garantito che appariranno queste sfumature? Supponiamo che Yandex decida improvvisamente di migrare tutti i servizi su Kubernetes, ci sarà un carico enorme.
Dmitrij: No, questa non è una discussione sul carico, ma su cose basilari. Ad esempio, abbiamo Kubernetes, abbiamo distribuito lì un'applicazione. Come possiamo capire se funziona? Non esiste uno strumento pronto per capire che l'applicazione non si arresta. Non esiste un sistema pronto che invii avvisi: bisogna configurare questi avvisi e ogni grafico. E noi stiamo aggiornando Kubernetes.
C'è Ubuntu 16.04. Si può dire che sia una versione vecchia, ma noi ci siamo ancora sopra perché è LTS. Ci sono systemd, il cui inconveniente è che non ripulisce i C-groups. Kubernetes avvia i pod, crea C-groups, poi elimina i pod, e in qualche modo si verifica - non ricordo i dettagli, scusate - che rimangono degli slice di systemd. Questo porta a un punto in cui, col passare del tempo, qualsiasi macchina inizia a rallentare notevolmente. Non è nemmeno una questione di highload. Se si avviano pod permanenti, ad esempio, se c'è un Cron Job che genera costantemente pod, allora la macchina con Ubuntu 16.04 dopo una settimana inizierà a rallentare. Ci sarà un load average costantemente alto a causa della creazione di un sacco di C-groups. Questo è un problema di cui chiunque installi semplicemente Ubuntu 16 e poi Kubernetes si trova a fronteggiare.
Supponiamo che in qualche modo aggiorni systemd o qualcos'altro, ma nel kernel Linux fino alla versione 4.16 è persino più divertente: quando si eliminano i C-groups, essi perdono nel kernel e in realtà non vengono rimossi. Pertanto, dopo un mese di lavoro su questa macchina sarà impossibile visualizzare le statistiche della memoria relative ai pod. Prendiamo un file, lo giriamo nel programma, e un file ci sta 15 secondi, perché il kernel calcola a lungo internamente su un milione di C-groups che sembrano essere stati rimossi, ma in realtà non lo sono - perdono.
Ci sono ancora tantissimi di questi piccoli dettagli sia qui che là. Non è una questione che le grandi aziende possono affrontare occasionalmente durante carichi molto elevati - no, è una questione di cose quotidiane. Le persone possono vivere così per mesi - hanno installato Kubernetes, hanno deploato un'applicazione - sembra funzionare. Per molti va bene. Non scopriranno mai che quell'applicazione crollerà per qualche motivo, l'allerta non arriverà, ma per loro è la norma. Prima vivevano su macchine virtuali senza monitoraggio, ora si sono trasferiti in Kubernetes anche senza monitoraggio - qual è la differenza?
Il punto è che quando camminiamo sul ghiaccio, non sappiamo mai quanto è spesso, a meno che non lo misuriamo in anticipo. Molti camminano e non si preoccupano, perché ci sono già stati.
Dal mio punto di vista, la complessità e la difficoltà nell'esploitazione di qualsiasi sistema stanno nel garantire che lo spessore del ghiaccio sia sufficientemente solido per risolvere le nostre esigenze. È di questo che si tratta.
Nell'IT, mi sembra che ci siano troppi approcci del tipo 'Mi andrà bene'. Molti installano software e usano librerie in attesa che le cose vadano bene. In generale, molte volte va bene. Probabilmente è anche per questo che funziona.
— Dal mio punto di vista pessimista, sembra così: quando i rischi sono elevati e l'applicazione deve funzionare, è necessaria assistenza da parte di 'Flant', possibilmente da Red Hat, oppure è richiesta una propria squadra interna dedicata a Kubernetes, che è pronta a gestirlo.
Dmitrij: Oggettivamente è così. Entrare da soli nella questione di Kubernetes con un piccolo team comporta alcuni rischi.
Abbiamo bisogno di container?
— Puoi raccontarmi quanto Kubernetes sia diffuso in Russia?
Dmitrij: Non ho questi dati e non sono sicuro che qualcun altro li abbia. Noi diciamo: 'Kubernetes, Kubernetes', ma ci sono altri punti di vista su questa questione. Quanto siano diffusi i container, non lo so nemmeno, ma so che secondo i rapporti online il 70% dei container è orchestrato da Kubernetes. È stata una fonte attendibile su un campione piuttosto grande a livello mondiale.
Passiamo a un'altra domanda: abbiamo davvero bisogno di container? Ho la sensazione personale e in generale la posizione dell'azienda 'Flant' è che Kubernetes è lo standard de facto.
Non ci sarà nulla oltre Kubernetes.
È un vero game-changer nel campo della gestione delle infrastrutture. Davvero assoluto: basta Ansible, Chef, macchine virtuali, Terraform. Non parlo nemmeno dei vecchi metodi improvvisati. Kubernetes è un cambiamento assoluto, e ora sarà solo così.
È chiaro che alcuni avranno bisogno di un paio d'anni, altri un paio di decenni, per rendersi conto di questo. Non ho dubbi che non ci sarà nulla oltre Kubernetes e questa nuova visione: non rimuoviamo più il sistema operativo, ma utilizziamo infrastructure as code, solo non con codice, ma con yml - un'infrastruttura descritta in modo dichiarativo. Ho la sensazione che sarà sempre così.
— Quindi le aziende che non sono ancora passate a Kubernetes, devono sicuramente farlo, o rimarranno nel dimenticatoio. Ho capito correttamente?
Dmitrij: Anche questo non è del tutto corretto. Ad esempio, se abbiamo il compito di lanciare un server DNS, può funzionare su FreeBSD 4.10 e può funzionare perfettamente per 20 anni. Semplicemente funziona e basta. È possibile che in 20 anni sia necessario aggiornare qualcosa una sola volta. Se parliamo di software che abbiamo lanciato e che funziona realmente per anni senza aggiornamenti, senza modifiche, ovviamente, non ci sarà Kubernetes. Non è necessario.
Tutto ciò che riguarda CI/CD - ovunque ci sia bisogno di Continuous Delivery, dove è necessario aggiornare le versioni, apportare modifiche attive, ovunque sia necessario costruire tolleranza ai guasti - solo Kubernetes.
Sui microservizi
— Qui ho un piccolo dissonanza. Per lavorare con Kubernetes, è necessaria un supporto esterno o interno - questo è il primo punto. Secondo - quando iniziamo appena a sviluppare, siamo una piccola startup, non abbiamo ancora nulla, lo sviluppo sotto Kubernetes o sotto l'architettura a microservizi può essere complicato e non sempre giustificato economicamente. Sono interessato alla tua opinione: è necessario che le startup inizino subito a scrivere sotto Kubernetes o si può comunque scrivere un monolite e poi passare a Kubernetes?
Dmitrij: Ottima domanda. Ho una presentazione sui microservizi Mi è capitato molte volte di vedere persone che cercano di piantare chiodi con un microscopio. Di per sé, l'approccio è corretto, stiamo progettando il nostro software interno proprio in questo modo. Ma quando lo fai, devi avere una chiara comprensione di quello che stai facendo. Ciò che odio di più nei microservizi è la parola «micro». Storicamente, questa parola è emersa e per qualche motivo le persone pensano che micro significhi molto piccolo, meno di un millimetro, come un micrometro. Non è così.
Ad esempio, c'è un monolite, scritto da 300 persone, e tutti coloro che hanno partecipato allo sviluppo capiscono che ci sono problemi e che deve essere suddiviso in micro-pezzi - circa 10, ognuno dei quali è scritto da un minimo di 30 persone. Questo è importante, necessario e fantastico. Ma quando ci arriva una startup, dove 3 ragazzi molto bravi e talentuosi hanno scritto 60 microservizi a mano, ogni volta cerco il Corvalol.
Mi sembra che se ne sia già parlato mille volte: abbiamo ottenuto un monolite distribuito in una forma o nell'altra. Questo non è economicamente giustificato, è molto difficile in generale. Semplicemente, l'ho visto così tante volte che mi fa male, quindi continuo a parlarne.
Ritornando alla domanda iniziale, c'è un conflitto tra il fatto che, da un lato, utilizzare Kubernetes è spaventoso, perché non è chiaro cosa possa rompersi o non funzionare, dall'altro lato, è evidente che tutto sta andando in quella direzione e niente, tranne Kubernetes, ci sarà. La risposta è valutare il volume dei benefici che si ottiene, il volume delle attività che puoi risolvere. Questo è da un lato della bilancia. Dall'altro lato ci sono i rischi legati ai tempi di inattività o alla diminuzione del tempo di risposta, del livello di disponibilità, alla diminuzione delle metriche di performance.
La situazione è questa: o ci muoviamo rapidamente, e Kubernetes consente di fare molte cose molto più velocemente e meglio, oppure utilizziamo soluzioni affidabili e collaudate, ma ci muoviamo molto più lentamente. Questa scelta deve essere fatta da ogni azienda. Si può considerare come un sentiero nella giungla: quando ci si va la prima volta, si può incontrare un serpente, una tigre o un tasso arrabbiato, ma dopo esserci andati 10 volte, si crea un sentiero, si rimuovono i rami e si cammina più facilmente. Ogni volta il sentiero diventa più ampio. Poi diventa una strada asfaltata, e successivamente un bel viale.
Kubernetes non resta fermo. Ancora una volta la domanda: Kubernetes, da un lato, sono 4-5 binari, dall'altro lato, è tutto un ecosistema. È un sistema operativo che abbiamo sulle macchine. Cos'è? Ubuntu o Curios? È il kernel Linux, una miriade di componenti aggiuntivi. Tutte queste cose qui hanno scartato un serpente velenoso dalla strada, là hanno messo una recinzione. Kubernetes si sta sviluppando molto rapidamente e dinamicamente, e il volume dei rischi, il volume dell'ignoto, diminuisce ogni mese e, di conseguenza, questi pesi si riequilibrano.
Rispondendo alla domanda su cosa fare per una startup, direi: venite da "Flant", pagate 150.000 rubli e ottenete un servizio DevOps easy service chiavi in mano. Se siete una piccola startup con pochi sviluppatori, questo funziona. Invece di assumere il vostro DevOps, che dovrà imparare a risolvere i vostri problemi e a cui dovrete pagare uno stipendio nel frattempo, riceverete una soluzione a tutte le questioni chiavi in mano. Sì, ci sono alcuni svantaggi. Noi, come outsourcer, non possiamo essere così coinvolti e non possiamo reagire rapidamente ai cambiamenti. Ma abbiamo molta esperienza e pratiche pronte. Garantiamo che in qualsiasi situazione ci organizzeremo rapidamente e recupereremo qualsiasi Kubernetes dall'aldilà.
Raccomando categoricamente l'outsourcing per le startup e le aziende consolidate fino a quando non potete dedicare un team di 10 persone alla gestione, perché altrimenti non ha senso. Ha assolutamente senso esternalizzare.
Su Amazon e Google
È possibile considerare le soluzioni di hosting da Amazon o Google come outsourcing?
Dmitrij: Sì, certamente, questo risolve alcune questioni. Ma ci sono comunque delle sfumature. Bisogna comunque capire come utilizzarle. Ad esempio, ci sono mille piccoli dettagli nel lavoro con Amazon AWS: bisogna riscaldare il Load Balancer o inviare una richiesta in anticipo dicendo "ragazzi, ci arriverà traffico, per favore riscaldateci il Load Balancer!" Queste sfumature bisogna conoscerle.
Quando ti rivolgi a persone che si specializzano in questo, ottieni quasi tutte le cose standard messe a posto. Adesso abbiamo 40 ingegneri e entro la fine dell'anno probabilmente saranno 60 — siamo sicuri di aver già affrontato tutte queste cose. Anche se su un progetto troviamo di nuovo questo problema, chiediamo già rapidamente tra di noi e sappiamo come risolverlo.
Probabilmente la risposta è: certo, la storia dell'hosting facilita una parte di questo. La domanda è: siete pronti a fidarvi di questi fornitori di hosting, e risolveranno i vostri problemi? Amazon e Google si sono dimostrati efficaci. Per tutti i nostri casi, sicuramente. Altrimenti non abbiamo avuto esperienze positive. Tutti gli altri cloud con cui abbiamo provato a lavorare hanno creato molti problemi — sia Ager che tutto ciò che esiste in Russia, e vari OpenStack in diverse implementazioni: Headster, Overage — tutto ciò che vuoi. Creano tutti problemi che non si ha voglia di affrontare.
Pertanto, la risposta è sì, ma in effetti non ci sono molte soluzioni hosted mature.
A chi serve Kubernetes?
— E comunque, a chi serve Kubernetes? Chi dovrebbe già passare a Kubernetes, chi è il cliente tipico di "Flanta" che viene proprio per Kubernetes?
Dmitrij: È una domanda interessante, perché adesso molti ci contattano proprio in un momento in cui Kubernetes è di tendenza: "Ragazzi, sappiamo che fate Kubernetes, fatelo per noi!". Noi rispondiamo: "Signori, non facciamo Kubernetes, facciamo produzione e tutto ciò che con esso è collegato". Perché fare produzione senza dedicarsi a tutto il CI/CD e a tutta questa storia è semplicemente impossibile al giorno d'oggi. Tutti si sono allontanati dalla divisione tra sviluppo e operazioni.
I nostri clienti si aspettano cose diverse, ma tutti sperano in qualche miracolo, che possano avere problemi e adesso — hop! — Kubernetes li risolverà. La gente crede nei miracoli. Sa razionalmente che non ci sarà un miracolo, ma spera con il cuore — e se questo Kubernetes ora ci risolvesse tutto, ne parlano tanto! E se fosse ora — ecco! — la pallottola d'argento, ecco! — e avremmo un uptime del 100%, tutti gli sviluppatori potrebbero rilasciare quello che vogliono in produzione 50 volte e non cadrebbe. In generale, un miracolo!
Quando queste persone ci contattano, diciamo: "Ci scusiamo, ma i miracoli non esistono". Per essere in salute, bisogna mangiare bene e fare sport. Per avere una produzione affidabile, bisogna costruirla in modo affidabile. Per avere un CI/CD conveniente, bisogna crearlo in quel modo. C'è molto lavoro da fare.
Rispondendo alla domanda a chi serve Kubernetes — Kubernetes non serve a nessuno.
Alcune persone hanno la falsa impressione di avere bisogno di Kubernetes. La gente ha bisogno di smettere di pensare, occuparsi e interessarsi a tutti i problemi infrastrutturali e ai problemi di avvio delle loro applicazioni. Vogliono che le applicazioni funzionino semplicemente e si distribuiscano senza problemi. Per loro Kubernetes è la speranza di smettere di sentire storie come "eravamo in difficoltà" o "non possiamo rilasciare", o altro.
Di solito, ci contatta un direttore tecnico. Da lui ci si aspetta due cose: da un lato, vogliamo le funzionalità, dall'altro — stabilità. Noi proponiamo di prenderci questa responsabilità e fare. La pallottola d'argento, o meglio, la pallottola argentata, consiste nel fatto che smetterai di pensare a questi problemi e di perdere tempo. Avrai persone speciali che si occuperanno di questa questione.
La formulazione che noi o qualcuno abbiamo bisogno di Kubernetes è errata.
Kubernetes è molto utile per gli amministratori, perché è un giocattolo veramente interessante con cui giocare e sperimentare. Siamo onesti: a tutti piacciono i giocattoli. Siamo tutti bambini in qualche modo e quando vediamo qualcosa di nuovo, vogliamo giocarci. Alcuni di noi lo hanno superato, per esempio nel mondo dell'amministrazione, perché ci siamo già divertiti e ci siamo stancati tanto che non abbiamo più voglia. Ma non è che questo interesse sia completamente spento per chiunque. Ad esempio, se mi sono già annoiato dei giochi nel campo dell'amministrazione di sistemi e del DevOps, continuo comunque ad amare i giocattoli e ne acquisto di nuovi.
Non bisogna giocare con la produzione. Quello che io categoricamente non consiglio di fare e che vedo ora accadere molto spesso è: "Oh, un nuovo giocattolo!" e correte a comprarlo, comprato e poi: "Prendiamolo subito a scuola, mostriamo a tutti i nostri amici". Non fatelo. Mi scuso, ho solo dei bambini che crescono, vedo continuamente cose nei bambini, me ne accorgo in me stesso e poi generalizzo sugli altri.
Risposta definitiva: non hai bisogno di Kubernetes. Devi risolvere i tuoi problemi.
Puoi ottenere che:
- la produzione non crolli;
- anche se cerca di crollare, lo sappiamo in anticipo e possiamo fare qualcosa;
- possiamo modificarla alla velocità di cui abbiamo bisogno per il business e farlo in modo conveniente senza problemi.
Le reali necessità sono due: affidabilità e dinamicità/flessibilità nel rilascio. Tutti coloro che ora realizzano progetti IT, indipendentemente dal settore in cui operano — software per semplificare il mondo — e chi comprende questo, deve risolvere queste necessità. Kubernetes, con il giusto approccio, la giusta comprensione e un'esperienza sufficiente, consente di affrontarle.
Su serverless
— Se guardiamo un po' più lontano nel futuro, cercando di risolvere il problema della mancanza di mal di testa con l'infrastruttura, con la velocità di rilascio e con la velocità di cambiamento dell'applicazione, emergono nuove soluzioni, come serverless. Senti qualche potenziale in questa direzione e, per così dire, un pericolo per Kubernetes e soluzioni simili?
Dmitrij: Qui bisogna di nuovo fare un'osservazione, che io non sono un veggente, che guarda avanti e dice - sarà così! Anche se ho appena fatto la stessa cosa. Guardo sotto i piedi e vedo un sacco di problemi, per esempio, come funzionano i transistor nei computer. È ridicolo, vero? Ci scontriamo con qualche bug nella CPU.
Realizzare un serverless in modo affidabile, economico, efficiente e conveniente, risolvendo tutte le questioni ecologiche. Qui sono d'accordo con Elon Musk, che serve un secondo pianeta per garantire la resilienza per l'umanità. Anche se non so quello che dice, capisco che non sono pronto a viaggiare su Marte e che non sarà domani.
Con il serverless è chiaro che è una cosa ideologicamente corretta, come la resilienza per l'umanità - avere due pianeti è meglio che uno. Ma come farlo ora? Mandare una spedizione - non è un problema se si concentrano gli sforzi su questo. Inviare diverse spedizioni e colonizzare lì diverse migliaia di persone, penso sia anche realistico. Tuttavia, realizzare completamente la resilienza in modo che metà dell'umanità viva là, mi sembra attualmente impossibile, non fattibile.
Con il serverless è un po' la stessa cosa: è una cosa fantastica, ma è lontana dai problemi del 2019. Più vicino al 2030 - vediamo di arrivarci. Non ho dubbi che ci arriveremo, ci arriveremo sicuramente (ripetetelo prima di dormire), ma ora dobbiamo affrontare altri problemi. È come credere in un pony magico chiamato Arcobaleno. Sì, alcuni casi vengono risolti, e vengono risolti benissimo, ma soggettivamente il serverless - è un arcobaleno... Per me questo argomento è troppo lontano e troppo poco chiaro. Non sono pronto a parlare. Nel 2019 non puoi scrivere nessuna applicazione con il serverless.
Come si svilupperà Kubernetes
— Mentre ci dirigiamo verso questo potenzialmente meraviglioso e lontano futuro, cosa pensi, come si svilupperà Kubernetes e l'ecosistema attorno ad esso?
Dmitrij: Ho pensato molto a questo e ho una risposta chiara. Primo: fare statefull è comunque più difficile che fare stateless. Kubernetes ha investito di più in questo fin dall'inizio. Lo stateless funziona praticamente perfettamente su Kubernetes, non c'è proprio nulla di cui lamentarsi. Ci sono ancora un sacco di problemi, o meglio, di dettagli con statefull. A noi funziona già tutto splendidamente, ma questo siamo noi. Per farlo funzionare per tutti ci vorranno almeno ancora un paio d'anni. Non è una stima precisa, ma è una mia sensazione.
In breve, lo statefull deve e si svilupperà molto, perché tutte le nostre applicazioni conservano uno stato, non esistono applicazioni stateless. È un'illusione, serve sempre qualche database e qualcos'altro. Statefull è l'approccio di semplificare tutto ciò che è possibile, risolvere tutti i bug, migliorare tutti i problemi che si affrontano attualmente - chiamiamolo adoption.
Il livello di ciò che non è ancora stato esplorato, il livello dei problemi irrisolti, il livello della probabilità di imbattersi in qualcosa, diminuirà notevolmente. È una storia importante. E gli operatori - tutto ciò che riguarda la codificazione della logica di amministrazione, la logica di gestione, per ottenere un servizio facile: servizio facile MySQL, servizio facile RabbitMQ, servizio facile Memcache, - tutti questi componenti che ci servono per ottenere un funzionamento garantito 'out of the box'. Questo affronta esattamente quel dolore di cui abbiamo bisogno: un database che non vogliamo amministrare, o un Kubernetes che non vogliamo amministrare.
Questa storia dello sviluppo degli operatori, in una forma o nell'altra, sarà importante nei prossimi due anni.
Penso che la semplicità di utilizzo dovrebbe aumentare considerevolmente - il dispositivo diventerà sempre più e più 'black box', sempre più e più affidabile, con sempre più semplici manopole.
Una volta ho ascoltato un'intervista di Isaac Asimov degli anni '80 su YouTube nello show Saturday Night Live - un programma simile a quello di Urgant, ma più interessante. Gli chiedevano del futuro dei computer. Ha detto che il futuro sta nella semplicità, come era con la radio. La radio era inizialmente una cosa complessa. Per catturare una frequenza, dovevi girare manopole per 15 minuti, ruotare dispositivi e sapere come funzionava tutto, comprendere la fisica della trasmissione delle onde radio. Alla fine, nella radio è rimasta solo una manopola.
Adesso nel 2019 quale radio? Nella macchina il sintonizzatore radio trova tutte le frequenze, i nomi delle stazioni. La fisica del processo non è cambiata in 100 anni, è cambiata la semplicità d'uso. Adesso, e non solo adesso, già nel 1980, quando ci fu l'intervista con Asimov, tutti usavano la radio e nessuno si chiedeva come funzionasse. Ha sempre funzionato—è una realtà.
Asimov allora diceva che con i computer sarà analogamente— la semplicità d'uso aumenterà. Se nel 1980 era necessario avere una formazione speciale per premere i tasti su un computer, in futuro non sarà più così.
Ho la sensazione che con Kubernetes e con l'infrastruttura la semplicità d'uso aumenterà notevolmente. Questo, a mio avviso, è evidente—è sotto gli occhi di tutti.
Cosa fare con gli ingegneri?
— E cosa ne sarà degli ingegneri, degli amministratori di sistema che supportano Kubernetes?
Dmitrij: E cosa è successo con il contabile dopo l'arrivo di 1C? Più o meno la stessa cosa. Prima si contava su carta—ora nel programma. La produttività è aumentata notevolmente, ma il lavoro non è scomparso. Se prima servivano 10 ingegneri per avvitare una lampadina, ora ne basterà uno.
Il numero di software e il numero di compiti, mi sembra, ora cresce con una velocità maggiore rispetto a quella con cui compaiono nuovi DevOps e aumenta l'efficienza. Adesso c'è una carenza specifica sul mercato e durerà a lungo. Più avanti tutto tornerà a una certa norma, il che porterà a un aumento dell'efficienza lavorativa, ci saranno sempre più soluzioni serverless, a Kubernetes verrà integrata un'intelligenza artificiale che gestirà tutte le risorse proprio come necessario, e in generale farà tutto da sola, come deve—l'uomo si allontani e non disturbi.
Ma le decisioni dovranno comunque essere prese da qualcuno. È chiaro che il livello di qualificazione e specializzazione di questa persona sarà più alto. Adesso nel reparto contabilità non hai bisogno di 10 dipendenti che tengano i registri contabili per non affaticarsi la mano. Semplicemente non è necessario. Molti documenti vengono scansionati automaticamente, riconosciuti dal sistema di gestione elettronica dei documenti. Basta un bravo capo contabile, con molte più competenze e una buona comprensione.
In generale, questo è il cammino in tutti i settori. Anche con le automobili: una volta l'auto era accompagnata da un meccanico e tre conducenti. Ora guidare un'auto è un processo semplicissimo, in cui tutti noi partecipiamo ogni giorno. Nessuno si rende conto che un'auto è qualcosa di complesso.
DevOps o ingegneria dei sistemi non scompariranno: l'alto livello e l'efficienza del lavoro aumenteranno.
— Ho sentito un'idea interessante, che in realtà il lavoro aumenterà.
Dmitrij: Certamente, cento percento! Perché la quantità di software che scriviamo cresce costantemente. Il numero di problemi che risolviamo con il software cresce costantemente. La quantità di lavoro sta aumentando. Ora il mercato DevOps è estremamente saturo. Questo si può osservare nelle aspettative salariali. In teoria, senza entrare nei dettagli, dovrebbero esserci junior che chiedono X, mid che chiedono 1,5X e senior che chiedono 2X. E ora, se si guarda al mercato di Mosca per i salari dei DevOps, un junior chiede da X a 3X e un senior chiede da X a 3X.
Nessuno sa quanto vale. Il livello salariale è misurato dalla tua fiducia: è una vera follia, se devo essere onesto, un mercato estremamente saturo.
Certo, questa situazione cambierà molto presto: deve esserci una certa saturazione. Con lo sviluppo del software non è così: nonostante i buoni sviluppatori siano richiesti ovunque, il mercato sa chi vale cosa: il settore si è stabilizzato. Con DevOps ora non è così.
— Da ciò che ho sentito, ho concluso che il sistemista attuale non deve preoccuparsi troppo, ma è tempo di migliorare le competenze e prepararsi al fatto che domani ci sarà più lavoro, ma sarà di qualifica superiore.
Dmitrij: Assolutamente. In generale, viviamo nel 2019 e la regola della vita è questa: lifetime learning — impariamo per tutta la vita. Mi sembra che ora lo sappiano e lo sentano tutti, ma sapere non basta: bisogna agire. Ogni giorno dobbiamo cambiare. Se non lo facciamo, prima o poi ci lasceranno ai margini della professione.
Sii pronto a bruschi cambi di direzione a 180 gradi. Non escludo situazioni in cui qualcosa possa cambiare radicalmente, possano inventare qualcosa di nuovo — accade. Ecco! — e ora agiamo in modo diverso. È importante essere pronti a questo e non preoccuparsi. Potrebbe succedere che domani tutto ciò che faccio diventi superfluo — va bene, ho imparato per tutta la vita e sono pronto a imparare qualcosa di diverso. Non è un problema. Non c'è motivo di temere la sicurezza lavorativa, ma bisogna essere pronti a imparare costantemente qualcosa di nuovo.
Auguri e un momento di pubblicità
— Hai qualche desiderio?
Dmitrij: Sì, ho alcuni desideri.
Il primo e più mercantile — iscriviti a . Cari lettori, andate su YouTube e iscrivetevi al nostro canale. Tra circa un mese inizieremo un'espansione attiva sul servizio video — avremo una tonnellata di contenuti didattici su Kubernetes, aperti e variegati: dalle cose pratiche, fino ai laboratori, ai principi teorici profondi e a come applicare Kubernetes a livello di principi e modelli.
Il secondo desiderio mercantile — andate su e mettete delle stelle, perché ci nutriamo di esse. Se non ci mettete stelle, non avremo nulla da mangiare. È come la manna in un videogioco. Facciamo qualcosa, ci impegniamo, qualcuno dice che sono delle brutte bici, qualcun altro che è tutto sbagliato, ma continuiamo e agiamo in modo assolutamente onesto. Vediamo un problema, lo risolviamo e condividiamo la nostra esperienza. Quindi regalateci una stella, non vi costerà nulla, ma a noi porterà beneficio, perché ci nutriamo di esse.
Il terzo, importante, e già non mercantile desiderio — smettetela di credere alle favole. Voi siete professionisti. DevOps è una professione molto seria e responsabile. Smettete di giocare al lavoro. Può essere fastidioso per alcuni, ma è molto probabile che non riguardi voi, ma qualcun altro. Dite agli altri di smettere anche loro. Questo rovina veramente la vita a tutti noi — molti iniziano a trattare gli amministratori e i DevOps come tizi che hanno di nuovo rotto qualcosa. Questo "hanno rotto" è più spesso causato dal fatto che siamo andati a giocare, invece di aver guardato con lucidità come stanno realmente le cose.
Questo non significa che non si debba esperimentare. Bisogna esperimentare, lo facciamo noi stessi. A essere onesti, a volte ci divertiamo anche noi — questo, ovviamente, è molto male, ma nulla di umano ci è estraneo. Dichiareremo il 2019 anno di esperimenti seri e ben pensati, e non giochi in produzione. Probabilmente sarebbe così.
— Grazie mille!
Dmitrij: Grazie a te, Vitalij, sia per il tempo che per l'intervista. Cari lettori, vi ringraziamo tanto, se siete arrivati a questo punto. Speriamo di avervi portato almeno un paio di spunti.
Nell'intervista, Dmitrij ha toccato il tema di werf. Ora è un coltellino svizzero universale che risolve quasi tutti i problemi. Ma non è sempre stato così. Al festival Dmitrij Stolyarov parlerà di questo strumento in dettaglio. Nella relazione ci sarà tutto: problemi e sfide nascoste di Kubernetes, opzioni per risolvere queste difficoltà e l'implementazione attuale di werf in dettaglio. Unitevi a noi il 27 e 28 maggio, creeremo strumenti perfetti.
Fonte: habr.com
