In anticipazione Vitali Khabarov intervistato Dmitry Stolyarov (), direttore tecnico e cofondatore dell'azienda Flant. Vitaly ha chiesto a Dmitry cosa fa Flant, Kubernetes, sviluppo dell'ecosistema, supporto. Abbiamo discusso del motivo per cui Kubernetes è necessario e se è effettivamente necessario. E ancora di microservizi, Amazon AWS, l'approccio "Sarò fortunato" a DevOps, il futuro di Kubernetes stesso, perché, quando e come conquisterà il mondo, le prospettive di DevOps e a cosa dovrebbero prepararsi gli ingegneri nel futuro. Un futuro luminoso e prossimo con la semplificazione e le reti neurali.
ascolta come podcast su DevOps Deflop: un podcast in lingua russa su DevOps, e di seguito è riportata la versione testuale.
Qui e sotto pone domande ingegnere di Express42.
A proposito di "Flant"
- Ciao Dima. Tu sei il direttore tecnico"" e anche il suo fondatore. Per favore, dicci cosa fa l'azienda e cosa fai?
Dmitry: Dall'esterno sembra che noi siamo quelli che vanno in giro a installare Kubernetes per tutti e a farci qualcosa. Ma non è vero. Abbiamo iniziato come azienda che si occupa di Linux, ma per molto tempo la nostra attività principale è stata al servizio della produzione e di progetti chiavi in mano ad alto carico. Di solito costruiamo l'intera infrastruttura da zero e poi ne siamo responsabili per molto, molto tempo. Pertanto, il lavoro principale svolto da "Flant", per il quale riceve denaro, è assumersi la responsabilità e implementare la produzione chiavi in mano.
Io, in qualità di direttore tecnico e uno dei fondatori dell'azienda, passo tutto il giorno e la notte cercando di capire come aumentare l'accessibilità della produzione, semplificarne il funzionamento, rendere più facile la vita degli amministratori e più piacevole la vita degli sviluppatori .
Informazioni su Kubernetes
— Ultimamente ho visto molti rapporti da Flant e su Kubernetes. Come ci sei arrivato?
Dmitry: Ne ho già parlato molte volte, ma non mi dispiace affatto ripeterlo. Credo sia giusto ripetere questo argomento perché c’è confusione tra causa ed effetto.
Avevamo davvero bisogno di uno strumento. Abbiamo affrontato molti problemi, lottato, superati con varie stampelle e sentito il bisogno di uno strumento. Abbiamo esaminato molte opzioni diverse, costruito le nostre biciclette e acquisito esperienza. A poco a poco siamo arrivati al punto in cui abbiamo iniziato a utilizzare Docker non appena è apparso, intorno al 2013. Al momento della sua comparsa, avevamo già molta esperienza con i container, avevamo già scritto un analogo di "Docker" - alcune delle nostre stampelle in Python. Con l'avvento di Docker è stato possibile abbandonare le stampelle e utilizzare una soluzione affidabile e supportata dalla comunità.
Con Kubernetes la storia è simile. Quando ha iniziato a prendere slancio - per noi questa è la versione 1.2 - avevamo già un sacco di stampelle sia su Shell che su Chef, che in qualche modo abbiamo cercato di orchestrare con Docker. Stavamo seriamente guardando a Rancher e varie altre soluzioni, ma poi è apparso Kubernetes, in cui tutto è implementato esattamente come avremmo fatto noi o anche meglio. Non c'è niente di cui lamentarsi.
Sì, c'è una sorta di imperfezione qui, c'è una sorta di imperfezione lì - ci sono molte imperfezioni e 1.2 è generalmente terribile, ma... Kubernetes è come un edificio in costruzione: guardi il progetto e capisci che sarà bello. Se l'edificio ora ha fondamenta e due piani, allora capisci che è meglio non trasferirsi ancora, ma non ci sono problemi del genere con il software: puoi già usarlo.
Non abbiamo avuto un momento in cui abbiamo pensato se utilizzare Kubernetes o meno. Lo stavamo aspettando molto prima che apparisse e abbiamo provato a creare noi stessi degli analoghi.
Informazioni su Kubernetes
— Sei direttamente coinvolto nello sviluppo di Kubernetes stesso?
Dmitry: Mediocre. Piuttosto, partecipiamo allo sviluppo dell’ecosistema. Inviamo un certo numero di richieste pull: a Prometheus, a vari operatori, a Helm - all'ecosistema. Sfortunatamente non sono in grado di tenere traccia di tutto ciò che facciamo e potrei sbagliarmi, ma non esiste un solo pool da noi al centro.
— Allo stesso tempo, sviluppi molti dei tuoi strumenti attorno a Kubernetes?
Dmitry: La strategia è questa: andiamo a fare richieste a tutto ciò che già esiste. Se le richieste pull non vengono accettate lì, semplicemente le forniamo noi stessi e viviamo finché non vengono accettate con le nostre build. Quindi, quando raggiunge la versione a monte, torniamo alla versione a monte.
Ad esempio, abbiamo un operatore Prometheus, con il quale probabilmente siamo già passati 5 volte avanti e indietro verso l'upstream del nostro assembly. Abbiamo bisogno di qualche tipo di funzionalità, abbiamo inviato una richiesta pull, dobbiamo implementarla domani, ma non vogliamo aspettare che venga rilasciata a monte. Di conseguenza, assembliamo noi stessi, distribuiamo il nostro assemblaggio con la nostra funzionalità, di cui abbiamo bisogno per qualche motivo, a tutti i nostri cluster. Poi, ad esempio, ce lo consegnano a monte con le parole: "Ragazzi, facciamolo per un caso più generale", noi, o qualcun altro, lo finiamo e col tempo si fonde di nuovo.
Cerchiamo di sviluppare tutto ciò che esiste. Molti elementi che non esistono ancora, non sono stati ancora inventati o sono stati inventati ma non hanno avuto il tempo di implementarli: lo stiamo facendo. E non perché ci piaccia il processo o la costruzione di biciclette come industria, ma semplicemente perché abbiamo bisogno di questo strumento. Spesso ci viene posta la domanda: perché abbiamo fatto questa o quella cosa? La risposta è semplice: sì, perché dovevamo andare oltre, risolvere qualche problema pratico e l'abbiamo risolto con questa tula.
Il percorso è sempre così: cerchiamo con molta attenzione e, se non troviamo alcuna soluzione su come fare un filobus con una pagnotta di pane, allora facciamo la nostra pagnotta e il nostro filobus.
Strumenti Flanta
— So che Flant ora dispone di operatori aggiuntivi, operatori di shell e strumenti dapp/werf. A quanto ho capito, questo è lo stesso strumento in diverse incarnazioni. Capisco anche che ci sono molti altri strumenti diversi all'interno di Flaunt. Questo è vero?
Dmitry: Abbiamo molto di più su GitHub. Da quello che ricordo ora, abbiamo una statusmap, un pannello per Grafana che tutti hanno incontrato. Viene menzionato in quasi un articolo su due sul monitoraggio di Kubernetes su Medium. È impossibile spiegare brevemente cos'è una statusmap: necessita di un articolo separato, ma è una cosa molto utile per monitorare lo stato nel tempo, poiché in Kubernetes spesso abbiamo bisogno di mostrare lo stato nel tempo. Abbiamo anche LogHouse: è una cosa basata su ClickHouse e sulla magia nera per la raccolta dei log in Kubernetes.
Tante utilità! E ce ne saranno ancora di più, perché quest'anno verranno rilasciate numerose soluzioni interne. Di quelli molto grandi basati sull'operatore addon, ci sono un sacco di addon per Kubernetes, come installare correttamente sert manager - uno strumento per gestire i certificati, come installare correttamente Prometheus con un sacco di accessori - ce ne sono circa venti diversi binari che esportano dati e raccolgono qualcosa, per questo Prometheus ha la grafica e gli avvisi più sorprendenti. Tutto questo è solo un mucchio di componenti aggiuntivi di Kubernetes, che vengono installati in un cluster, e da semplici si trasforma in interessanti, sofisticati, automatici, in cui molti problemi sono già stati risolti. Sì, facciamo molto.
Sviluppo dell'ecosistema
"Mi sembra che questo sia un grande contributo allo sviluppo di questo strumento e delle sue modalità di utilizzo." Potete stimare approssimativamente chi altro darebbe lo stesso contributo allo sviluppo dell’ecosistema?
Dmitry: In Russia, delle aziende che operano nel nostro mercato, nessuna è nemmeno vicina. Naturalmente questa è un'affermazione forte, perché ci sono grandi attori come Mail e Yandex - stanno anche facendo qualcosa con Kubernetes, ma anche loro non si avvicinano al contributo di aziende in tutto il mondo che fanno molto più di noi. È difficile confrontare Flant, che ha uno staff di 80 persone, e Red Hat, che ha 300 ingegneri per solo Kubernetes, se non sbaglio. È difficile fare paragoni. Abbiamo 6 persone nel reparto RnD, me compreso, che tagliano tutti i nostri strumenti. 6 persone contro 300 ingegneri Red Hat: è in qualche modo difficile fare paragoni.
- Ma quando anche queste 6 persone riescono a fare qualcosa di veramente utile e alienante, quando si trovano di fronte a un problema pratico e ne danno la soluzione alla comunità - un caso interessante. Capisco che nelle grandi aziende tecnologiche, dove hanno il proprio team di sviluppo e supporto Kubernetes, in linea di principio è possibile sviluppare gli stessi strumenti. Questo è per loro un esempio di cosa si può sviluppare e donare alla comunità, dando slancio a tutta la comunità che utilizza Kubernetes.
Dmitry: Questa è probabilmente una caratteristica dell'integratore, la sua peculiarità. Abbiamo tanti progetti e vediamo tante situazioni diverse. Per noi, il modo principale per creare valore aggiunto è analizzare questi casi, trovare punti in comune e renderli il più economici possibile per noi. Stiamo lavorando attivamente su questo. È difficile per me parlare della Russia e del mondo, ma in azienda abbiamo circa 40 ingegneri DevOps che lavorano su Kubernetes. Non penso che ci siano molte aziende in Russia con un numero paragonabile di specialisti che capiscano Kubernetes, se non addirittura nessuna.
Capisco tutto del titolo di ingegnere DevOps, tutti capiscono tutto e sono abituati a chiamare ingegneri DevOps ingegneri DevOps, non ne discuteremo. Tutti questi 40 straordinari ingegneri DevOps affrontano e risolvono problemi ogni giorno, noi analizziamo semplicemente questa esperienza e proviamo a generalizzare. Comprendiamo che se rimane dentro di noi, tra un anno o due lo strumento sarà inutile, perché da qualche parte nella comunità apparirà una Tula già pronta. Non ha senso accumulare questa esperienza internamente: sta semplicemente prosciugando energia e tempo in dev/null. E non ce ne dispiace affatto. Pubblichiamo tutto con grande piacere e comprendiamo che deve essere pubblicato, sviluppato, promosso, promosso in modo che le persone lo utilizzino e aggiungano la propria esperienza - poi tutto cresce e vive. Poi dopo due anni lo strumento non va nella spazzatura. Non è un peccato continuare a dare forza, perché è chiaro che qualcuno sta usando il tuo strumento e dopo due anni lo usano tutti.
Questo fa parte della nostra grande strategia con dapp/werf. Non ricordo quando abbiamo iniziato a realizzarlo, sembra 3 anni fa. Inizialmente era generalmente sul guscio. È stata una super prova di concetto, abbiamo risolto alcuni dei nostri problemi particolari: ha funzionato! Ma ci sono problemi con la shell, è impossibile espanderla ulteriormente, programmare sulla shell è un altro compito. Avevamo l'abitudine di scrivere in Ruby, di conseguenza, abbiamo rifatto qualcosa in Ruby, sviluppato, sviluppato, sviluppato e ci siamo imbattuti nel fatto che la comunità, la folla che non dice "lo vogliamo o non lo vogliamo, ” storce il naso davanti a Ruby, quanto è divertente? Ci siamo resi conto che dovremmo scrivere tutte queste cose in Go solo per soddisfare il primo punto della checklist: Lo strumento DevOps dovrebbe essere un file binario statico. Essere Go o meno non è così importante, ma un binario statico scritto in Go è meglio.
Abbiamo speso le nostre energie, abbiamo riscritto il dapp in Go e lo abbiamo chiamato werf. La Dapp non è più supportata, non è sviluppata, funziona nella versione più recente, ma esiste un percorso di aggiornamento assoluto verso l'alto e puoi seguirlo.
Perché è stato creato il dapp?
— Puoi raccontarci brevemente perché è nata la dapp, quali problemi risolve?
Dmitry: Il primo motivo è nell'assemblea. Inizialmente, abbiamo avuto seri problemi con la build poiché Docker non disponeva di funzionalità multistadio, quindi abbiamo creato il multistadio da soli. Poi abbiamo avuto molti altri problemi con la pulizia dell'immagine. Chiunque faccia CI/CD, prima o poi, si trova ad affrontare il problema che ci sono un sacco di immagini raccolte, è necessario in qualche modo ripulire ciò che non è necessario e lasciare ciò che è necessario.
Il secondo motivo è la distribuzione. Sì, c'è Helm, ma risolve solo alcuni problemi. Stranamente, è scritto che "Helm è il gestore dei pacchetti per Kubernetes". Esattamente quello che “il”. Ci sono anche le parole "Package Manager": qual è la solita aspettativa da un Package Manager? Diciamo: "Gestione pacchetti: installa il pacchetto!" e ci aspettiamo che ci dica: “Il pacco è stato consegnato”.
È interessante che diciamo: "Timone, installa il pacchetto" e quando risponde di averlo installato, si scopre che ha appena avviato l'installazione - ha indicato Kubernetes: "Avvia questa cosa!", e se è iniziata o meno , che funzioni o meno, Helm non risolve affatto questo problema.
Si scopre che Helm è solo un preprocessore di testo che carica i dati in Kubernetes.
Ma come parte di qualsiasi distribuzione, vogliamo sapere se l'applicazione è stata rilasciata per la produzione oppure no? Implementato su prod significa che l'applicazione è stata spostata lì, la nuova versione è stata distribuita e almeno non si blocca lì e risponde correttamente. Helm non risolve questo problema in alcun modo. Per risolverlo, è necessario dedicare molti sforzi, perché è necessario dare a Kubernetes il comando per l'implementazione e monitorare ciò che sta accadendo lì, indipendentemente dal fatto che sia stato distribuito o implementato. E ci sono anche molte attività legate alla distribuzione, alla pulizia e all'assemblaggio.
Piani
Quest’anno inizieremo lo sviluppo locale. Vogliamo ottenere ciò che prima era in Vagrant: abbiamo digitato "vagrant up" e abbiamo distribuito macchine virtuali. Vogliamo arrivare al punto in cui c'è un progetto in Git, lì scriviamo "werf up" e verrà visualizzata una copia locale di questo progetto, distribuita in un mini-Kub locale, con tutte le directory utili per lo sviluppo collegate . A seconda del linguaggio di sviluppo ciò avviene in modo diverso, ma comunque in modo che lo sviluppo locale possa essere eseguito comodamente con i file montati.
Il prossimo passo per noi è investire in comodità per gli sviluppatori. Per distribuire rapidamente un progetto localmente con un unico strumento, svilupparlo, inserirlo in Git e verrà anche implementato in fase o test, a seconda delle pipeline, quindi utilizzare lo stesso strumento per andare in produzione. Questa unità, unificazione, riproducibilità delle infrastrutture dall'ambiente locale alle vendite è per noi un punto molto importante. Ma questo non è ancora previsto: stiamo solo progettando di farlo.
Ma il percorso verso dapp/werf è sempre stato lo stesso di Kubernetes all’inizio. Abbiamo riscontrato problemi, li abbiamo risolti con soluzioni alternative: abbiamo trovato alcune soluzioni per noi stessi sulla shell, su qualsiasi cosa. Quindi hanno provato a raddrizzare in qualche modo queste soluzioni alternative, generalizzandole e consolidandole in binari in questo caso, che semplicemente condividiamo.
C'è un altro modo di guardare tutta questa storia, con analogie.
Kubernetes è un telaio di automobile con un motore. Non ci sono porte, vetri, radio, alberi di Natale: niente di niente. Solo telaio e motore. E c'è il timone: questo è il volante. Fantastico: c'è un volante, ma hai anche bisogno di un perno dello sterzo, di una cremagliera, di un cambio e di ruote e non puoi farne a meno.
Nel caso di werf, questo è un altro componente di Kubernetes. Solo ora nella versione alpha di werf, ad esempio, Helm è compilato all'interno di werf, perché siamo stanchi di farlo da soli. Ci sono molte ragioni per farlo, ti dirò in dettaglio il motivo per cui abbiamo compilato l'intero timone insieme alla barra del timone all'interno del werf .
Ora werf è un componente più integrato. Otteniamo un volante finito, un perno dello sterzo: non sono molto bravo con le macchine, ma questo è un blocco di grandi dimensioni che risolve già una gamma abbastanza ampia di problemi. Non abbiamo bisogno di sfogliare noi stessi il catalogo, selezionare una parte per un'altra, pensare a come avvitarli insieme. Otteniamo una mietitrebbia già pronta che risolve un gran numero di problemi contemporaneamente. Ma al suo interno è costruito con gli stessi componenti open source, utilizza ancora Docker per l'assemblaggio, Helm per alcune funzionalità e ci sono molte altre librerie. Questo è uno strumento integrato per ottenere CI/CD interessanti pronti all'uso in modo rapido e conveniente.
Kubernetes è difficile da mantenere?
— Parli dell'esperienza che hai iniziato a utilizzare Kubernetes, questo è un telaio per te, un motore, e su cui puoi appendere molte cose diverse: un corpo, un volante, pedali avvitati, sedili. La domanda sorge spontanea: quanto è difficile per te il supporto di Kubernetes? Hai molta esperienza, quanto tempo e risorse dedichi al supporto di Kubernetes separatamente da tutto il resto?
Dmitry: Questa è una domanda molto difficile e per rispondere dobbiamo capire cos'è il supporto e cosa vogliamo da Kubernetes. Forse puoi rivelare?
— Per quanto ne so e vedo, ora molti team vogliono provare Kubernetes. Tutti si attaccano ad esso, lo mettono in ginocchio. Ho la sensazione che le persone non sempre comprendano la complessità di questo sistema.
Dmitry: È come questo.
— Quanto è difficile prendere e installare Kubernetes da zero in modo che sia pronto per la produzione?
Dmitry: Quanto pensi che sia difficile trapiantare un cuore? Capisco che sia una domanda compromettente. Usare un bisturi e non commettere errori non è così difficile. Se ti dicono dove tagliare e dove cucire, la procedura in sé non è complicata. È difficile garantire di volta in volta che tutto funzionerà.
Installare Kubernetes e farlo funzionare è facile: pulcino! — installato, ci sono molti metodi di installazione. Ma cosa succede quando sorgono problemi?
Sorgono sempre domande: cosa non abbiamo ancora preso in considerazione? Cosa non abbiamo ancora fatto? Quali parametri del kernel Linux sono stati specificati in modo errato? Signore, li abbiamo almeno menzionati?! Quali componenti Kubernetes abbiamo fornito e quali no? Sorgono migliaia di domande e per rispondere è necessario trascorrere 15-20 anni in questo settore.
Ho un esempio recente su questo argomento che potrebbe rivelare il significato del problema "Kubernetes è difficile da mantenere?" Qualche tempo fa abbiamo considerato seriamente se provare a implementare Cilium come rete in Kubernetes.
Lascia che ti spieghi cos'è Cilium. Kubernetes ha molte diverse implementazioni del sottosistema di rete e una di queste è molto interessante: Cilium. Qual è il suo significato? Nel kernel, qualche tempo fa è diventato possibile scrivere hook per il kernel, che in un modo o nell'altro invadono il sottosistema di rete e vari altri sottosistemi e consentono di bypassare grossi pezzi del kernel.
Storicamente il kernel Linux ha un ip rout, un overfilter, bridge e molti vecchi componenti diversi che hanno 15, 20, 30 anni. In generale, funzionano, va tutto benissimo, ma ora hanno ammucchiato i contenitori e sembra una torre di 15 mattoni uno sopra l'altro e tu ci stai sopra su una gamba: una strana sensazione. Questo sistema si è storicamente sviluppato con molte sfumature, come l'appendice nel corpo. In alcune situazioni, ad esempio, si verificano problemi di prestazioni.
C'è un meraviglioso BPF e la possibilità di scrivere hook per il kernel: i ragazzi hanno scritto i propri hook per il kernel. Il pacchetto entra nel kernel Linux, lo estraggono direttamente all'input, lo elaborano da soli come dovrebbe senza bridge, senza TCP, senza stack IP - in breve, bypassando tutto ciò che è scritto nel kernel Linux e poi sputano fuori nel contenitore.
Quello che è successo? Prestazioni davvero interessanti, funzionalità interessanti: semplicemente fantastico! Ma guardiamo questo e vediamo che su ogni macchina c'è un programma che si connette all'API Kubernetes e, in base ai dati che riceve da questa API, genera codice C e compila binari che carica nel kernel in modo che questi hook funzionino nello spazio del kernel.
Cosa succede se qualcosa va storto? Noi non sappiamo. Per capirlo, devi leggere tutto questo codice, comprenderne tutta la logica ed è sorprendente quanto sia difficile. Ma d'altra parte ci sono questi bridge, filtri di rete, ip rout: non ho letto il loro codice sorgente, e nemmeno i 40 ingegneri che lavorano nella nostra azienda. Forse solo pochi capiscono alcune parti.
E qual è la differenza? Si scopre che c'è ip rout, il kernel Linux, e c'è un nuovo strumento: che differenza fa, non capiamo l'uno o l'altro. Ma abbiamo paura di usare qualcosa di nuovo: perché? Perché se lo strumento ha 30 anni, in 30 anni sono stati trovati tutti i bug, tutti gli errori sono stati calpestati e non è necessario sapere tutto: funziona come una scatola nera e funziona sempre. Tutti sanno quale cacciavite diagnostico attaccare in quale posto, quale tcpdump eseguire in quale momento. Tutti conoscono bene le utilità diagnostiche e comprendono come funziona questo insieme di componenti nel kernel Linux: non come funziona, ma come usarlo.
E il fantastico Cilium non ha 30 anni, non è ancora invecchiato. Kubernetes ha lo stesso problema, copia. Che Cilium è installato perfettamente, che Kubernetes è installato perfettamente, ma quando qualcosa va storto in produzione, sei in grado di capire velocemente in una situazione critica cosa è andato storto?
Quando diciamo che è difficile mantenere Kubernetes, no, è molto semplice e sì, è incredibilmente difficile. Kubernetes funziona benissimo da solo, ma con un miliardo di sfumature.
Riguardo all’approccio “Sarò fortunato”.
— Ci sono aziende in cui è quasi garantito che queste sfumature appaiano? Supponiamo che Yandex trasferisca improvvisamente tutti i servizi a Kubernetes, lì ci sarà un carico enorme.
Dmitry: No, questa non è una conversazione sul carico, ma sulle cose più semplici. Ad esempio, abbiamo Kubernetes, abbiamo distribuito l'applicazione lì. Come fai a sapere che funziona? Semplicemente non esiste uno strumento già pronto per capire che l'applicazione non si blocca. Non esiste un sistema già pronto che invii avvisi; è necessario configurare questi avvisi e ogni pianificazione. E stiamo aggiornando Kubernetes.
Ho Ubuntu 16.04. Puoi dire che questa è una vecchia versione, ma la stiamo ancora utilizzando perché è LTS. Esiste systemd, la cui sfumatura è che non ripulisce i gruppi C. Kubernetes avvia i pod, crea gruppi C, quindi elimina i pod e in qualche modo si scopre - non ricordo i dettagli, mi dispiace - che le sezioni systemd rimangono. Ciò porta al fatto che nel tempo qualsiasi macchina inizia a rallentare fortemente. Questa non è nemmeno una questione di carico elevato. Se vengono avviati pod permanenti, ad esempio, se c'è un Cron Job che genera costantemente pod, allora la macchina con Ubuntu 16.04 inizierà a rallentare dopo una settimana. Ci sarà un carico medio costantemente elevato a causa del fatto che sono stati creati numerosi gruppi C. Questo è il problema che dovrà affrontare chiunque installi semplicemente Ubuntu 16 e Kubernetes.
Diciamo che in qualche modo aggiorna systemd o qualcos'altro, ma nel kernel Linux fino alla 4.16 è ancora più divertente: quando elimini i gruppi C, perdono nel kernel e non vengono effettivamente eliminati. Pertanto, dopo un mese di lavoro su questa macchina, sarà impossibile guardare le statistiche di memoria dei focolari. Tiriamo fuori un file, lo lanciamo nel programma e un file gira per 15 secondi, perché il kernel impiega molto tempo per contare al suo interno un milione di gruppi C, che sembrano essere cancellati, ma no: stanno perdendo .
Ci sono ancora molte di queste piccole cose qua e là. Questo non è un problema che le grandi aziende possono talvolta affrontare sotto carichi molto pesanti: no, è una questione di cose di tutti i giorni. Le persone possono vivere così per mesi: hanno installato Kubernetes, distribuito l'applicazione, sembra che funzioni. Per molte persone questo è normale. Non sapranno nemmeno che questa applicazione andrà in crash per qualche motivo, non riceveranno un avviso, ma per loro questa è la norma. Prima vivevamo su macchine virtuali senza monitoraggio, ora siamo passati a Kubernetes, anch'esso senza monitoraggio: qual è la differenza?
La questione è che quando camminiamo sul ghiaccio non ne conosciamo mai lo spessore a meno che non lo misuriamo in anticipo. Molte persone camminano e non si preoccupano, perché hanno già camminato prima.
Dal mio punto di vista, la sfumatura e la complessità del funzionamento di qualsiasi sistema consiste nel garantire che lo spessore del ghiaccio sia esattamente sufficiente a risolvere i nostri problemi. Questo è ciò di cui stiamo parlando.
Nell’IT, mi sembra, ci sono troppi approcci del tipo “sarò fortunato”. Molte persone installano software e utilizzano librerie software nella speranza di avere fortuna. In generale, molte persone sono fortunate. Probabilmente è per questo che funziona.
— Dalla mia valutazione pessimistica, sembra così: quando i rischi sono alti e l'applicazione deve funzionare, allora è necessario il supporto di Flaunt, magari di Red Hat, oppure è necessario un proprio team interno dedicato specificamente a Kubernetes, che è pronto per tirarlo fuori.
Dmitry: Oggettivamente è così. Entrare da soli nella storia di Kubernetes per un piccolo team comporta una serie di rischi.
Abbiamo bisogno di contenitori?
— Puoi dirci quanto è diffuso Kubernetes in Russia?
Dmitry: Non ho questi dati e non sono sicuro che qualcun altro li abbia. Diciamo: “Kubernetes, Kubernetes”, ma esiste un altro modo di considerare la questione. Inoltre non so quanto siano diffusi i container, ma conosco un dato da rapporti su Internet secondo cui il 70% dei container sono orchestrati da Kubernetes. Era una fonte affidabile per un campione abbastanza ampio in tutto il mondo.
Poi un'altra domanda: abbiamo bisogno di contenitori? La mia sensazione personale e la posizione generale dell'azienda Flant è che Kubernetes sia uno standard de facto.
Non ci sarà altro che Kubernetes.
Si tratta di un punto di svolta assoluto nel campo della gestione delle infrastrutture. Semplicemente assoluto: tutto qui, niente più Ansible, Chef, macchine virtuali, Terraform. Non sto parlando dei vecchi metodi della fattoria collettiva. Kubernetes è un cambiamento assoluto, e ora sarà solo così.
È chiaro che per alcuni ci vogliono un paio d’anni, e per altri un paio di decenni, per rendersene conto. Non ho dubbi che non ci sarà altro che Kubernetes e questa nuova veste: non danneggiamo più il sistema operativo, ma utilizziamo infrastruttura come codice, solo non con codice, ma con yml, un'infrastruttura descritta in modo dichiarativo. Ho la sensazione che sarà sempre così.
— Cioè, quelle aziende che non sono ancora passate a Kubernetes lo passeranno sicuramente o rimarranno nell'oblio. ti ho capito bene?
Dmitry: Anche questo non è del tutto vero. Ad esempio, se abbiamo il compito di gestire un server DNS, allora potrà essere eseguito su FreeBSD 4.10 e potrà funzionare perfettamente per 20 anni. Basta lavorare e basta. Forse tra 20 anni qualcosa dovrà essere aggiornato una volta. Se parliamo di software nel formato che abbiamo lanciato e funziona effettivamente per molti anni senza aggiornamenti, senza apportare modifiche, allora, ovviamente, non ci sarà Kubernetes. Non c'è bisogno di lui lì.
Tutto ciò che riguarda CI/CD - ovunque sia necessaria la consegna continua, dove sia necessario aggiornare versioni, apportare modifiche attive, ovunque sia necessario creare tolleranza agli errori - solo Kubernetes.
Informazioni sui microservizi
- Qui ho una leggera dissonanza. Per lavorare con Kubernetes hai bisogno di supporto esterno o interno: questo è il primo punto. In secondo luogo, quando abbiamo appena iniziato lo sviluppo, siamo una piccola startup, non abbiamo ancora nulla, lo sviluppo per Kubernetes o l’architettura dei microservizi in generale può essere difficile e non sempre giustificato economicamente. Mi interessa la tua opinione: le startup devono iniziare immediatamente a scrivere per Kubernetes da zero o possono ancora scrivere un monolite e poi arrivare solo a Kubernetes?
Dmitry: Bella domanda. Ho una conversazione sui microservizi Molte volte ho incontrato persone che cercavano di piantare chiodi con un microscopio. L'approccio in sé è corretto: progettiamo noi stessi il nostro software interno in questo modo. Ma quando lo fai, devi capire chiaramente cosa stai facendo. La parola che odio di più riguardo ai microservizi è “micro”. Storicamente, questa parola ha avuto origine lì, e per qualche motivo la gente pensa che micro sia molto piccolo, meno di un millimetro, come un micrometro. Questo è sbagliato.
Ad esempio, c'è un monolite scritto da 300 persone e tutti coloro che hanno partecipato allo sviluppo capiscono che ci sono problemi lì e dovrebbe essere suddiviso in micro-pezzi - circa 10 pezzi, ognuno dei quali è scritto da 30 persone in una versione minima. Questo è importante, necessario e interessante. Ma quando viene da noi una startup, dove 3 ragazzi molto bravi e talentuosi hanno scritto 60 microservizi in ginocchio, ogni volta cerco Corvalol.
Mi sembra che se ne sia già parlato migliaia di volte: abbiamo ottenuto un monolite distribuito in una forma o nell'altra. Questo non è economicamente giustificato, in generale è molto difficile in tutto. L’ho visto così tante volte che mi fa davvero male, quindi continuo a parlarne.
Alla domanda iniziale c'è un conflitto tra il fatto che, da un lato, Kubernetes è spaventoso da usare, perché non è chiaro cosa potrebbe rompersi o non funzionare, dall'altro è chiaro che tutto va lì e non esisterà altro che Kubernetes. Risposta - valutare la quantità di benefici che ne derivano, la quantità di compiti che puoi risolvere. Questo è su un lato della bilancia. D'altra parte, ci sono rischi associati ai tempi di inattività o alla diminuzione dei tempi di risposta, del livello di disponibilità - con una diminuzione degli indicatori di prestazione.
Eccolo: o ci muoviamo rapidamente e Kubernetes ci consente di fare molte cose molto più velocemente e meglio, oppure utilizziamo soluzioni affidabili e testate nel tempo, ma ci muoviamo molto più lentamente. Questa è una scelta che ogni azienda deve fare. Puoi pensarlo come un sentiero nella giungla: quando cammini per la prima volta, puoi incontrare un serpente, una tigre o un tasso pazzo, e quando hai camminato 10 volte, hai percorso il sentiero, rimosso i rami e camminare più facilmente. Ogni volta il percorso si allarga. Poi è una strada asfaltata e poi un bel viale.
Kubernetes non si ferma. Ancora una domanda: Kubernetes, da un lato, è 4-5 binari, dall'altro è l'intero ecosistema. Questo è il sistema operativo che abbiamo sulle nostre macchine. Cos'è questo? Ubuntu o Curioso? Questo è il kernel Linux, un mucchio di componenti aggiuntivi. Tutte queste cose qui, un serpente velenoso è stato gettato fuori dalla strada, lì è stata eretta una recinzione. Kubernetes si sta sviluppando in modo molto rapido e dinamico e il volume dei rischi, il volume dell'ignoto diminuisce ogni mese e, di conseguenza, queste scale si stanno riequilibrando.
Rispondendo alla domanda su cosa dovrebbe fare una startup, direi: vieni a Flaunt, paga 150mila rubli e ottieni un facile servizio DevOps chiavi in mano. Se sei una piccola startup con pochi sviluppatori, funziona. Invece di assumere i tuoi DevOps, che dovranno imparare a risolvere i tuoi problemi e pagare uno stipendio in questo momento, otterrai una soluzione chiavi in mano a tutti i problemi. Sì, ci sono alcuni svantaggi. Noi, come outsourcer, non possiamo essere così coinvolti e rispondere rapidamente ai cambiamenti. Ma abbiamo molta esperienza e pratiche già pronte. Garantiamo che in ogni situazione lo scopriremo sicuramente rapidamente e resusciteremo qualsiasi Kubernetes dalla morte.
Consiglio vivamente l'outsourcing alle startup e alle aziende affermate fino a una dimensione in cui è possibile dedicare un team di 10 persone alle operazioni, perché altrimenti non ha senso. Ha sicuramente senso esternalizzare questo compito.
A proposito di Amazon e Google
— Un host di una soluzione di Amazon o Google può essere considerato un outsourcing?
Dmitry: Sì, certo, questo risolve una serie di problemi. Ma ancora una volta ci sono delle sfumature. Devi ancora capire come usarlo. Ad esempio, ci sono mille piccole cose nel lavoro di Amazon AWS: il Load Balancer deve essere riscaldato oppure è necessario scrivere in anticipo una richiesta che "ragazzi, riceveremo traffico, riscaldate il Load Balancer per noi!" Devi conoscere queste sfumature.
Quando ti rivolgi a persone specializzate in questo, ottieni quasi tutte le cose tipiche chiuse. Ora abbiamo 40 ingegneri, entro la fine dell'anno saranno probabilmente 60: abbiamo sicuramente riscontrato tutte queste cose. Anche se incontriamo nuovamente questo problema su qualche progetto, ci interroghiamo rapidamente e sappiamo come risolverlo.
Probabilmente la risposta è: ovviamente, una storia ospitata rende alcune parti più semplici. La domanda è se sei pronto a fidarti di questi hoster e se risolveranno i tuoi problemi. Amazon e Google hanno fatto bene. Per tutti i nostri casi - esattamente. Non abbiamo più esperienze positive. Tutti gli altri cloud con cui abbiamo provato a lavorare creano molti problemi: Ager e tutto ciò che è in Russia e tutti i tipi di OpenStack in diverse implementazioni: Headster, Overage - qualunque cosa tu voglia. Tutti creano problemi che non vuoi risolvere.
Pertanto la risposta è sì, ma in realtà non esistono molte soluzioni ospitate mature.
Chi ha bisogno di Kubernetes?
— Eppure, chi ha bisogno di Kubernetes? Chi dovrebbe già passare a Kubernetes, chi è il tipico client Flaunt che viene appositamente per Kubernetes?
Dmitry: Questa è una domanda interessante, perché proprio adesso, sulla scia di Kubernetes, molte persone vengono da noi: “Ragazzi, sappiamo che state facendo Kubernetes, fatelo per noi!” Rispondiamo loro: "Signori, non facciamo Kubernetes, facciamo prod e tutto ciò che è connesso ad esso". Perché attualmente è semplicemente impossibile realizzare un prodotto senza fare tutto il CI/CD e tutta questa storia. Tutti si sono allontanati dalla divisione secondo cui abbiamo sviluppo per sviluppo e quindi sfruttamento per sfruttamento.
I nostri clienti si aspettano cose diverse, ma tutti aspettano qualche buon miracolo quando hanno determinati problemi, e ora - salta! — Kubernetes li risolverà. Le persone credono nei miracoli. Nelle loro menti capiscono che non ci sarà alcun miracolo, ma nelle loro anime sperano: e se questo Kubernetes ora risolvesse tutto per noi, ne parlano così tanto! All'improvviso lui ora - starnutisce! - e una soluzione miracolosa, starnuto! - e abbiamo un tempo di attività del 100%, tutti gli sviluppatori possono rilasciare qualunque cosa entri in produzione 50 volte e non si blocca. In generale, un miracolo!
Quando queste persone vengono da noi, diciamo: “Ci dispiace, ma non esistono miracoli”. Per essere in salute è necessario mangiare bene e fare attività fisica. Per avere un prodotto affidabile, deve essere realizzato in modo affidabile. Per avere un CI/CD conveniente, è necessario realizzarlo in questo modo. C'è molto lavoro da fare.
Rispondendo alla domanda su chi ha bisogno di Kubernetes: nessuno ha bisogno di Kubernetes.
Alcune persone credono erroneamente di aver bisogno di Kubernetes. Le persone hanno bisogno, hanno un profondo bisogno di smettere di pensare, studiare e interessarsi a tutti i problemi delle infrastrutture e ai problemi di gestione delle loro applicazioni. Vogliono che le applicazioni funzionino e vengano semplicemente distribuite. Per loro, Kubernetes è la speranza che smettano di sentire la storia che “eravamo lì”, o “non possiamo lanciarlo”, o qualcos’altro.
Di solito viene da noi il direttore tecnico. Gli chiedono due cose: da un lato darci caratteristiche, dall'altro stabilità. Ti suggeriamo di prendertene la responsabilità e di farlo. La soluzione miracolosa, o meglio placcata d’argento, è che smetterai di pensare a questi problemi e di perdere tempo. Avrai persone speciali che chiuderanno questa questione.
La frase secondo cui noi o chiunque altro abbiamo bisogno di Kubernetes non è corretta.
Gli amministratori hanno davvero bisogno di Kubernetes, perché è un giocattolo molto interessante con cui puoi giocare e armeggiare. Siamo onesti: tutti amano i giocattoli. Siamo tutti bambini da qualche parte e quando ne vediamo uno nuovo, vogliamo giocarci. Per alcuni questo è stato scoraggiato, ad esempio nell’amministrazione, perché hanno già giocato abbastanza e sono già stanchi al punto che semplicemente non vogliono. Ma questo non è completamente sfuggito a nessuno. Ad esempio, se sono stanco da molto tempo dei giocattoli nel campo dell'amministrazione di sistema e di DevOps, allora adoro ancora i giocattoli, ne compro ancora di nuovi. Tutte le persone, in un modo o nell'altro, vogliono ancora qualche tipo di giocattolo.
Non c'è bisogno di giocare con la produzione. Quello che consiglio categoricamente di non fare e quello che vedo ora in massa: "Oh, un nuovo giocattolo!" – sono corsi a comprarlo, l’hanno comprato e: “Adesso portiamolo a scuola e facciamolo vedere a tutti i nostri amici”. Non farlo. Mi scuso, i miei figli stanno appena crescendo, vedo costantemente qualcosa nei bambini, lo noto in me stesso e poi lo generalizzo agli altri.
La risposta finale è: non hai bisogno di Kubernetes. Devi risolvere i tuoi problemi.
Ciò che puoi ottenere è:
- il pungolo non cade;
- anche se tenta di cadere, lo sappiamo in anticipo e possiamo inserirci qualcosa;
- possiamo cambiarlo alla velocità con cui la nostra attività lo richiede, e possiamo farlo comodamente; non ci crea alcun problema.
Le esigenze reali sono due: affidabilità e dinamismo/flessibilità del rollout. Tutti coloro che attualmente stanno realizzando qualche tipo di progetto IT, indipendentemente dal tipo di attività, sono morbidi per facilitare il mondo e chi lo capisce, deve risolvere queste esigenze. Kubernetes con il giusto approccio, con la giusta comprensione e con sufficiente esperienza ti permette di risolverli.
A proposito di serverless
— Se si guarda un po' più lontano nel futuro, cercando di risolvere il problema dell'assenza di grattacapi con l'infrastruttura, con la velocità di implementazione e la velocità dei cambiamenti delle applicazioni, appaiono nuove soluzioni, ad esempio serverless. Senti qualche potenziale in questa direzione e, diciamo, un pericolo per Kubernetes e soluzioni simili?
Dmitry: Anche qui dobbiamo rimarcare che io non sono un veggente che guarda avanti e dice: sarà così! Anche se ho appena fatto la stessa cosa. Guardo i miei piedi e vedo un sacco di problemi lì, ad esempio, come funzionano i transistor in un computer. È divertente, vero? Stiamo riscontrando alcuni bug nella CPU.
Rendi il serverless abbastanza affidabile, economico, efficiente e conveniente, risolvendo tutti i problemi dell'ecosistema. Qui sono d’accordo con Elon Musk sul fatto che è necessario un secondo pianeta per creare tolleranza agli errori per l’umanità. Anche se non so cosa stia dicendo, capisco che non sono pronto per volare su Marte e non accadrà domani.
Con il serverless è chiaramente chiaro che questa è una cosa ideologicamente corretta, come la tolleranza agli errori per l'umanità: avere due pianeti è meglio di uno. Ma come farlo adesso? Inviare una spedizione non è un problema se concentri i tuoi sforzi su di essa. Anche l'invio di diverse spedizioni e l'insediamento di diverse migliaia di persone lì, penso, sia realistico. Ma renderlo completamente tollerante ai guasti in modo che metà dell'umanità viva lì, mi sembra ora impossibile, non preso in considerazione.
Con serverless uno contro uno: la cosa è bella, ma è lontana dai problemi del 2019. Più vicini al 2030: viviamo abbastanza per vederlo. Non ho dubbi che vivremo, vivremo sicuramente (ripeto prima di andare a letto), ma ora dobbiamo risolvere altri problemi. È come credere nel pony delle fiabe Arcobaleno. Sì, un paio di per cento dei casi vengono risolti e vengono risolti perfettamente, ma soggettivamente il serverless è un arcobaleno... Per me questo argomento è troppo distante e troppo incomprensibile. Non sono pronto a parlare. Nel 2019 non è possibile scrivere una singola applicazione con serverless.
Come si evolverà Kubernetes
— Mentre ci muoviamo verso questo futuro lontano, potenzialmente meraviglioso, come pensi che si svilupperanno Kubernetes e l'ecosistema che lo circonda?
Dmitry: Ci ho pensato molto e ho una risposta chiara. Il primo è stateful: dopo tutto, stateless è più semplice da realizzare. Kubernetes inizialmente ha investito di più in questo, tutto è iniziato con quello. Stateless funziona quasi perfettamente in Kubernetes, non c'è proprio nulla di cui lamentarsi. Ci sono ancora molti problemi, o meglio, sfumature. Tutto lì funziona già alla grande per noi, ma siamo noi. Ci vorranno almeno ancora un paio d’anni perché funzioni per tutti. Questo non è un indicatore calcolato, ma la mia sensazione dalla mia testa.
In breve, statefull dovrebbe - e lo farà - svilupparsi molto fortemente, perché tutte le nostre applicazioni memorizzano lo stato; non esistono applicazioni stateless. Questa è un'illusione; hai sempre bisogno di una sorta di database e qualcos'altro. Statefull riguarda il miglioramento di tutto ciò che è possibile, la correzione di tutti i bug, il miglioramento di tutti i problemi attualmente affrontati: chiamiamola adozione.
Il livello dell'ignoto, il livello dei problemi irrisolti, il livello di probabilità di incontrare qualcosa diminuiranno in modo significativo. Questa è una storia importante E gli operatori - tutto ciò che riguarda la codifica della logica di amministrazione, la logica di controllo per ottenere un servizio facile: servizio facile MySQL, servizio facile RabbitMQ, servizio facile Memcache - in generale, tutti questi componenti di cui dobbiamo essere sicuri che funzionino la scatola. Questo risolve semplicemente il problema di volere un database, ma non vogliamo amministrarlo, o di voler Kubernetes, ma non vogliamo amministrarlo.
Questa storia di sviluppo degli operatori in una forma o nell'altra sarà importante nei prossimi due anni.
Penso che la facilità d'uso dovrebbe aumentare notevolmente: la scatola diventerà sempre più nera, sempre più affidabile, con manopole sempre più semplici.
Una volta ho ascoltato una vecchia intervista con Isaac Asimov degli anni '80 su YouTube nello spettacolo Saturday Night Live - un programma come Urgant, solo interessante. Gli hanno chiesto del futuro dei computer. Ha detto che il futuro è nella semplicità, proprio come la radio. Il ricevitore radio era originariamente una cosa complessa. Per catturare un'onda, dovevi girare le manopole per 15 minuti, girare gli spiedini e in generale sapere come funziona tutto, comprendere la fisica della trasmissione delle onde radio. Di conseguenza, nella radio era rimasta solo una manopola.
Ora nel 2019 quale radio? In macchina il ricevitore radio trova tutte le onde ed i nomi delle stazioni. La fisica del processo non è cambiata in 100 anni, ma la facilità d'uso sì. Adesso, e non solo adesso, già nel 1980, quando ci fu un'intervista ad Azimov, tutti usavano la radio e nessuno pensava a come funzionasse. Ha sempre funzionato, questo è un dato di fatto.
Azimov ha poi detto che sarebbe stato lo stesso con i computer: la facilità d'uso aumenterà. Mentre nel 1980 dovevi essere addestrato a premere i pulsanti di un computer, in futuro non sarà più così.
Ho la sensazione che con Kubernetes e con l'infrastruttura ci sarà anche un enorme aumento della facilità d'uso. Questo, secondo me, è ovvio: si trova in superficie.
Cosa fare con gli ingegneri?
— Cosa accadrà allora agli ingegneri e agli amministratori di sistema che supportano Kubernetes?
Dmitry: Cosa è successo al contabile dopo l'avvento di 1C? Piu 'o meno lo stesso. Prima contavano sulla carta, ora nel programma. La produttività del lavoro è aumentata in modo significativo, ma il lavoro in sé non è scomparso. Se prima per avvitare una lampadina occorrevano 10 ingegneri, ora ne basterà uno solo.
Mi sembra che la quantità di software e il numero di attività stiano crescendo a un ritmo più rapido rispetto alla comparsa dei nuovi DevOps e l'efficienza sta aumentando. C’è una carenza specifica nel mercato in questo momento e durerà a lungo. Più tardi, tutto tornerà a una sorta di normalità, in cui l'efficienza del lavoro aumenterà, ci saranno sempre più serverless, un neurone sarà collegato a Kubernetes, che selezionerà tutte le risorse esattamente come necessario, e in generale lo farà fai tutto da solo, come dovrebbe: la persona si allontana e non interferisce.
Ma qualcuno dovrà ancora prendere delle decisioni. È chiaro che il livello di qualifica e specializzazione di questa persona è più alto. Al giorno d'oggi, nel reparto contabilità, non sono necessari 10 dipendenti che tengono i libri in modo che le loro mani non si stanchino. Semplicemente non è necessario. Molti documenti vengono scansionati e riconosciuti automaticamente dal sistema di gestione elettronica dei documenti. Basta un capo contabile intelligente, già con competenze molto maggiori, con una buona comprensione.
In generale, questa è la strada da percorrere in tutti i settori. Con le auto è lo stesso: prima arrivava un’auto con un meccanico e tre autisti. Al giorno d'oggi, guidare un'auto è un processo semplice a cui tutti partecipiamo ogni giorno. Nessuno pensa che un'auto sia qualcosa di complicato.
DevOps o ingegneria dei sistemi non scompariranno: il lavoro di alto livello e l’efficienza aumenteranno.
— Ho anche sentito un'idea interessante secondo cui il lavoro aumenterà effettivamente.
Dmitry: Naturalmente, al cento per cento! Perché la quantità di software che scriviamo è in costante crescita. Il numero di problemi che risolviamo con il software è in costante crescita. La quantità di lavoro sta crescendo. Ora il mercato DevOps è terribilmente surriscaldato. Questo può essere visto nelle aspettative salariali. In senso buono, senza entrare nei dettagli, dovrebbero esserci junior che vogliono X, intermedi che vogliono 1,5X e senior che vogliono 2X. E ora, se si guarda al mercato salariale DevOps di Mosca, un junior vuole da X a 3X e un senior vuole da X a 3X.
Nessuno sa quanto costa. Il livello salariale è misurato dalla tua fiducia: un manicomio completo, a dire il vero, un mercato terribilmente surriscaldato.
Naturalmente, questa situazione cambierà molto presto: dovrebbe verificarsi una certa saturazione. Questo non è il caso dello sviluppo del software: nonostante tutti abbiano bisogno di sviluppatori e tutti abbiano bisogno di buoni sviluppatori, il mercato capisce chi vale cosa, il settore si è stabilizzato. Al giorno d'oggi non è più il caso di DevOps.
— Da quello che ho sentito, ho concluso che l’attuale amministratore di sistema non dovrebbe preoccuparsi troppo, ma è tempo di aggiornare le sue competenze e prepararsi al fatto che domani ci sarà più lavoro, ma sarà più qualificato.
Dmitry: Cento per cento. In generale, viviamo nel 2019 e la regola di vita è questa: apprendimento permanente: impariamo durante tutta la vita. Mi sembra che ormai tutti lo sappiano e lo sentano già, ma non basta saperlo, devi farlo. Ogni giorno dobbiamo cambiare. Se non lo facciamo, prima o poi saremo relegati ai margini della professione.
Preparati a brusche virate di 180 gradi. Non escludo una situazione in cui qualcosa cambia radicalmente, viene inventato qualcosa di nuovo: succede. Salto! - e ora agiamo diversamente. È importante essere preparati e non preoccuparsi. Può succedere che domani tutto ciò che faccio si riveli superfluo: niente, ho studiato tutta la vita e sono pronto a imparare qualcos'altro. Non è un problema. Non bisogna aver paura della sicurezza del lavoro, ma bisogna essere pronti a imparare costantemente qualcosa di nuovo.
Auguri e un minuto di pubblicità
- Hai qualche desiderio?
Dmitry: Sì, ho diversi desideri.
Primo e mercantile: iscriviti a . Cari lettori, andate su YouTube e iscrivetevi al nostro canale. Tra circa un mese inizieremo l'espansione attiva del servizio video, avremo tanti contenuti didattici su Kubernetes, aperti e variegati: dalle cose pratiche, fino ai laboratori, fino agli approfondimenti teorici fondamentali e all'uso di Kubernetes a livello globale. livello di principi e modelli.
Il secondo desiderio mercantile: vai a e mettiamo le stelle perché ci nutriamo di loro. Se non ci dai le stelle non avremo niente da mangiare. È come il mana in un gioco per computer. Facciamo qualcosa, lo facciamo, ci proviamo, qualcuno dice che queste sono biciclette terribili, qualcuno che è tutto completamente sbagliato, ma noi continuiamo e agiamo in modo assolutamente onesto. Vediamo un problema, lo risolviamo e condividiamo la nostra esperienza. Dateci dunque una stella, non si allontanerà da te, ma verrà a noi, perché di esse ci nutriamo.
Terzo desiderio, importante e non più mercantile: smettila di credere alle favole. Siete professionisti. DevOps è una professione molto seria e responsabile. Smetti di giocare sul posto di lavoro. Lascia che scatti per te e lo capirai. Immagina di venire in ospedale e lì il dottore sta facendo degli esperimenti su di te. Capisco che questo possa essere offensivo per qualcuno, ma, molto probabilmente, non riguarda te, ma qualcun altro. Di' anche agli altri di fermarsi. Questo rovina davvero la vita a tutti noi: molti iniziano a trattare le operazioni, gli amministratori e i DevOps come ragazzi che hanno rotto di nuovo qualcosa. Questo è stato "rotto" molto spesso a causa del fatto che andavamo a giocare e non guardavamo con fredda consapevolezza che è così, ed è così.
Questo non significa che non dovresti sperimentare. Dobbiamo sperimentare, lo facciamo da soli. Ad essere onesti, noi stessi a volte giochiamo: questo, ovviamente, è molto brutto, ma nulla di umano ci è estraneo. Dichiariamo il 2019 un anno di esperimenti seri e ben ponderati e non di giochi in produzione. Probabilmente è così.
- Grazie mille!
Dmitry: Grazie, Vitaly, sia per il tempo che per l'intervista. Cari lettori, grazie mille se siete arrivati improvvisamente a questo punto. Spero di avervi portato almeno un paio di pensieri.
Nell'intervista, Dmitry ha toccato la questione del werf. Ora questo è un coltello svizzero universale che risolve quasi tutti i problemi. Ma non è stato sempre così. SU al festival Dmitry Stolyarov ti parlerà di questo strumento in dettaglio. nel rapporto ci sarà di tutto: problemi e sfumature nascoste di Kubernetes, opzioni per risolvere queste difficoltà e l'attuale implementazione di werf in dettaglio. Unisciti a noi il 27 e 28 maggio, creeremo gli strumenti perfetti.
Fonte: habr.com