In vista di Vitalij Chabarov ha intervistato Dmitrij Stolyarov (), direttore tecnico e cofondatore dell'azienda "Flant". Vitalij ha chiesto a Dmitrij cosa fa la "Flant", di Kubernetes, dello sviluppo dell'ecosistema e del supporto. Hanno discusso del perché Kubernetes sia importante e se sia davvero necessario. E anche dei microservizi, di Amazon AWS, dell'approccio "Mi va bene" in DevOps, del futuro di Kubernetes e del perché, quando e come conquisterà il mondo, delle prospettive per DevOps e di cosa devono prepararsi gli ingegneri in un futuro prossimo con semplificazioni e reti neurali.
puoi ascoltarla nel formato podcast su DevOps Deflope — il podcast in lingua russa su DevOps, e qui sotto trovi la versione testuale.
Qui e oltre le domande sono poste da un ingegnere di Express42.
Su "Flant"
— Dima, ciao. Sei il direttore tecnico di "" e anche il suo fondatore. Raccontami, per favore, di cosa si occupa l'azienda e quale ruolo hai tu?
Dmitrij: All'esterno sembriamo degli esperti che si occupano di Kubernetes e ne sfruttano le potenzialità. Ma non è così. Siamo nati come azienda specializzata in Linux, ma da molto tempo ci concentriamo principalmente sulla gestione di progetti high-load e di produzione chiavi in mano. Di solito costruiamo l'intera infrastruttura da zero e poi ci occupiamo di essa a lungo termine. Pertanto, il lavoro principale che svolge «Флант» e per cui viene remunerata è prenderci la responsabilità e realizzare produzioni chiavi in mano.
Io, come CTO e uno dei fondatori dell'azienda, passo le mie giornate a pensare a come aumentare l'affidabilità della produzione, semplificarne la gestione e rendere la vita degli amministratori più facile, mentre quella degli sviluppatori più piacevole.
Riguardo a Kubernetes
— Ultimamente da «Флант» vedo molti interventi e sul Kubernetes. Come ci siete arrivati?
Dmitrij: Ne ho parlato molte volte, ma non mi dispiace ripeterlo. Credo sia giusto ripetere questo argomento, poiché si crea confusione tra causa ed effetto.
Avevamo davvero bisogno di uno strumento. Ci siamo trovati ad affrontare molte problematiche, lottando e superando ostacoli con varie soluzioni di fortuna, e sentivamo il bisogno di un vero strumento. Abbiamo esplorato molte opzioni diverse, ci siamo adattati e accumulato esperienza. Siamo giunti al punto in cui abbiamo iniziato a utilizzare Docker quasi subito dopo la sua uscita — intorno al 2013. Al momento della sua introduzione, avevamo già molta esperienza con i container e avevamo persino scritto una sorta di 'Docker' — una nostra soluzione provvisoria in Python. Con l'arrivo di Docker, abbiamo potuto abbandonare queste soluzioni temporanee a favore di una soluzione solida e supportata dalla comunità.
La storia con Kubernetes è simile. Quando ha iniziato a guadagnare attenzione — per noi la versione 1.2 — avevamo già un sacco di soluzioni comuni, sia in Shell che in Chef, che stavamo cercando di orchestrare con Docker. Abbiamo preso seriamente in considerazione Rancher e altre soluzioni, ma a quel punto è arrivato Kubernetes, realizzato esattamente come lo avremmo fatto noi, se non addirittura meglio. Non c'è nulla di cui lamentarsi.
Sì, ci sono dei bug, molti bug, e la versione 1.2 è un disastro, ma... Kubernetes somiglia a un edificio in costruzione: guardi al progetto e capisci che sarà fantastico. Se l'edificio ha già una base e due piani, capisci che è meglio non trasferirsi ancora, ma per il software non ci sono problemi: è già utilizzabile.
Non c'è mai stato un momento in cui ci siamo chiesti se utilizzare Kubernetes o meno. Lo aspettavamo da molto tempo prima che apparisse e cercavamo di costruire analoghi da soli.
Circa Kubernetes
— Partecipate direttamente allo sviluppo di Kubernetes stesso?
Dmitrij: Indirettamente. Piuttosto partecipiamo allo sviluppo dell'ecosistema. Inviamo un certo numero di pull request: in Prometheus, in vari operatori, in Helm — nell'ecosistema. Sfortunatamente, non sono in grado di seguire tutto ciò che facciamo e potrei sbagliarmi, ma non abbiamo inviato alcun pull request al 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 già esiste. Se non vengono accettati pull request, semplicemente li forkamo per noi stessi e continuiamo a vivere, finché non vengono accettati con le nostre build. Poi, quando questo arriva nell’upstream, torniamo alla versione upstream.
Ad esempio, abbiamo un operatore Prometheus, con il quale abbiamo switchato su e giù nella nostra build upstream già circa 5 volte. Abbiamo bisogno di una certa funzione, abbiamo inviato un pull request, dobbiamo implementarla domani, e non vogliamo aspettare il suo rilascio nell’upstream. Pertanto, ci costruiamo la nostra versione con la funzione di cui abbiamo bisogno, su tutti i nostri cluster. Poi, per esempio, questo viene riportato nell’upstream con le parole: «Ragazzi, facciamolo per un caso più generale», noi, o qualcun altro, lo completiamo e col tempo viene nuovamente integrato.
Tutto ciò che esiste, cerchiamo di svilupparlo.. Molti elementi che non esistono ancora non sono stati ancora inventati o sono stati inventati ma non sono stati implementati - noi lo facciamo. E non perché ci piaccia il processo stesso o la costruzione di biciclette come settore, ma semplicemente perché abbiamo bisogno di questo strumento. Ci viene spesso chiesto perché abbiamo realizzato questo o quel cosa. La risposta è semplice: perché dovevamo andare avanti, risolvere un problema pratico, e l'abbiamo risolto con questo strumento.
Il percorso è sempre lo stesso: 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 di 'Flanta'
— So che ora 'Flanta' ha operatori addon, operatori shell, strumenti dapp/werf. Se ho capito bene, si tratta dello stesso strumento in diverse incarnazioni. Inoltre, capisco che all'interno di 'Flanta' ci sono molti altri strumenti diversi. È così?
Dmitrij: Su GitHub abbiamo ancora molte altre cose. Tra quelle che ricordo, abbiamo statusmap — un pannello per Grafana che è piaciuto a tutti. Viene menzionato quasi in ogni secondo articolo riguardante il monitoraggio di Kubernetes su Medium. È impossibile spiegare brevemente cos'è statusmap — serve un articolo a parte, ma è uno strumento molto utile per il monitoraggio dello stato nel tempo, poiché in Kubernetes è spesso necessario mostrare lo stato nel tempo. Abbiamo anche LogHouse — è una soluzione basata su ClickHouse e un po' di magia nera per la raccolta dei log in Kubernetes.
Tante utility! E ce ne saranno ancora di più, poiché alcune soluzioni interne saranno rilasciate quest'anno. Tra le più importanti, ci sono molte addon per Kubernetes come, ad esempio, come installare correttamente il cert-manager — uno strumento per la gestione dei certificati, oppure come installare Prometheus con una serie di componenti aggiuntivi — ci sono circa venti diversi binari che esportano dati e raccolgono informazioni. Con Prometheus, ottieni grafica fantastica e allerta. Tutto questo è un insieme di addon per Kubernetes, che vengono installati nel cluster, trasformandolo da semplice a avanzato, automatico, dove molte questioni sono già risolte. Sì, stiamo facendo molte cose.
Sviluppo dell'ecosistema
— Mi sembra un contributo molto significativo allo sviluppo di questo strumento e dei suoi metodi di utilizzo. Puoi fare un'idea di chi altro potrebbe contribuire in modo simile allo sviluppo dell'ecosistema?
Dmitrij: In Russia, tra le aziende che operano nel nostro mercato — nessuno anche lontanamente.. Certamente, è un'affermazione audace, perché ci sono grandi attori come Mail e Yandex che stanno lavorando su Kubernetes, ma anche loro non si avvicinano al contributo delle aziende a livello globale, che è molto maggiore del nostro. È difficile confrontare Flant con un team di 80 persone e Red Hat, che conta circa 300 ingegneri solo per Kubernetes, se non sbaglio. È complicato fare il paragone. Nel nostro dipartimento R&D ci sono 6 persone, me compreso, che sviluppano tutti i nostri strumenti. 6 persone contro 300 ingegneri di Red Hat è un confronto piuttosto difficile.
— Tuttavia, quando anche queste 6 persone riescono a creare qualcosa di veramente utile e trasferibile, quando affrontano una sfida concreta e offrono la soluzione alla comunità, è un caso interessante. Capisco che nelle grandi aziende tecnologiche, dove ci sono team di sviluppo e supporto per Kubernetes, si possano sviluppare strumenti simili. Questo per loro è un esempio di cosa si può sviluppare e offrire alla comunità, dando uno slancio a tutto il gruppo che utilizza Kubernetes.
Dmitrij: Probabilmente è una caratteristica dell'integratore, una sua peculiarità. Noi gestiamo molti progetti e vediamo molte situazioni diverse. Per noi, il principale modo di creare valore aggiunto è analizzare questi casi, trovare delle somiglianze e ridurre al minimo i costi per noi. Su questo ci impegniamo attivamente. È difficile per me parlare della Russia e del mondo, ma abbiamo circa 40 ingegneri DevOps nell'azienda che si occupano di Kubernetes. Non credo che in Russia ci siano molte aziende con un numero comparabile di specialisti esperti in Kubernetes, se ci sono.
Comprendo tutto riguardo il titolo di DevOps Engineer, tutti lo capiscono e sono abituati a chiamare gli ingegneri DevOps così, non discuteremo di questo. Questi 40 straordinari ingegneri DevOps affrontano problemi ogni giorno e li risolvono; noi semplicemente analizziamo questa esperienza e cerchiamo di generalizzarla. Capisco che se rimane con noi, tra un anno o due lo strumento diventa inutile, perché da qualche parte nella community ne apparirà uno pronto. Non ha senso accumulare questa esperienza all'interno — è solo uno spreco di energie e tempo nel dev/null. In questo modo, non ci dispiace affatto. Pubblicizziamo tutto con grande piacere e capiamo che è necessario pubblicare, sviluppare, fare PR, promuovere, affinché le persone possano usarlo e aggiungere la loro esperienza — così tutto cresce e vive. Tra due anni, lo strumento non finisce nella spazzatura. Non ci dispiace continuare a investire energie, perché è chiaro che qualcuno sta usando 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 svilupparlo, sembra passato circa 3 anni. Inizialmente era totalmente in shell. Era un super proof of concept, abbiamo risolto alcune delle nostre questioni interne — e ha funzionato! Ma ci sono problemi con shell, non è possibile espanderlo ulteriormente, programmare in shell è un vero e proprio impegno. Avevamo l'abitudine di scrivere in Ruby, quindi abbiamo riscritto alcune cose, evolvendo, crescendo, crescendo, ma ci siamo scontrati con la realtà che la community, la gente, non dice 'vogliamo o non vogliamo', fa una smorfia nei confronti di Ruby, per quanto sia strano. Abbiamo capito che dovevamo scrivere tutto questo in Go, semplicemente per rispettare il primo punto nella checklist: Il tool DevOps deve essere un binario statico. Scrivere in Go o meno non è così importante, ma è meglio avere un binario statico scritto in Go.
Abbiamo investito risorse, riscritto dapp in Go e l'abbiamo chiamato werf. Dapp non è più supportato, non viene più sviluppato, funziona in qualche ultima versione, ma c'è un percorso di upgrade assoluto da seguire.
Perché è stato creato dapp
— Puoi spiegare brevemente perché è stato creato dapp, quali problemi risolve?
Dmitrij: La prima ragione è legata alla costruzione. Inizialmente abbiamo avuto gravi problemi con la costruzione, quando Docker non supportava il multi-stage, e lo abbiamo realizzato da soli. Poi abbiamo avuto anche una serie di domande sulla pulizia delle immagini. Tutti coloro che lavorano con CI/CD, prima o poi, si trovano ad affrontare il problema di avere un sacco di immagini costruite, e quindi è necessario in qualche modo pulire ciò che non serve e mantenere ciò che è utile.
La seconda ragione riguarda il deploy. Certo, c'è Helm, ma risolve solo alcune delle questioni. Anche se può sembrare strano, è scritto che «Helm è il Package Manager per Kubernetes». Esattamente, con «il». Ci sono anche le parole «Package Manager» — quali sono le aspettative tipiche dal Package Manager? Diciamo: «Package Manager, installa il pacchetto!» e ci aspettiamo che ci risponda: «Pacchetto installato».
È interessante che diciamo: «Helm, installa il pacchetto», ma quando risponde che l'ha installato, si scopre che in realtà ha solo iniziato l'installazione — ha detto a Kubernetes: «Avvia questo!» ma se è realmente partito o meno, e se funziona o no, Helm non risolve affatto questa domanda.
Quindi, si scopre che Helm è semplicemente un pre-processore testuale che carica dati in Kubernetes.
Ma all'interno di qualsiasi deploy vogliamo sapere se l'applicazione è stata distribuita in produzione o meno. Essere in produzione significa che l'applicazione è stata rilasciata, è stata distribuita una nuova versione e questa deve stare in piedi e rispondere correttamente. Helm non risolve questa questione. Per affrontarla, è necessario investire molte energie, poiché è fondamentale dare a Kubernetes il comando di distribuire e monitorare cosa sta succedendo: è stata distribuita o meno. Inoltre, ci sono molte attività collegate al deploy, alla pulizia e alla compilazione.
Piani
Quest'anno ci muoveremo verso lo sviluppo locale. Vogliamo tornare a ciò che prima era in Vagrant: un semplice 'vagrant up' per avviare le nostre macchine virtuali. Vogliamo arrivare a uno stato in cui esiste un progetto in Git, e scriviamo 'werf up', il quale avvia una copia locale di questo progetto, disponibile in un mini-Kubernetes locale, con tutte le directory necessarie collegate, rendendo la fase di sviluppo più conveniente. A seconda del linguaggio di programmazione, questo può essere eseguito in modi diversi, ma è fondamentale poter condurre lo sviluppo locale con i file montati.
Il prossimo passo per noi è significativo investire nel comfort per gli sviluppatori. Per schierare rapidamente un progetto localmente con un solo strumento, sviluppare, pushare su Git, e questo sarà sicuramente distribuito su stage o in test, a seconda dei pipeline, e poi con lo stesso strumento andare in produzione. Questa unità, unificazione, riproducibilità dell'infrastruttura dall'ambiente locale alla produzione è un aspetto per noi molto importante. Ma questo non è ancora presente in werf — lo stiamo solo pianificando.
Ma il percorso verso dapp/werf è sempre stato lo stesso che abbiamo seguito all'inizio con Kubernetes. Ci siamo imbattuti in problemi, li abbiamo affrontati con soluzioni alternative — ideando delle soluzioni in shell, su qualsiasi cosa. Poi cercavamo di semplificare, generalizzare e consolidare queste soluzioni in binari, che poi 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, profumi d'albero — non c'è nulla. Solo il telaio e il motore. E c'è Helm — questo è il volante. È fantastico avere il volante, ma servono anche il perno del volante, la cremagliera, il cambio e le ruote, altrimenti non si può fare.
Nel caso di werf, si tratta di un ulteriore componente per Kubernetes. Adesso abbiamo in versione alpha werf, dove, per esempio, Helm è compilato direttamente all'interno di werf, perché ci siamo stancati di farlo noi stessi. Ci sono molte ragioni per farlo, e ne parlerò dettagliatamente sul perché abbiamo integrato completamente Helm insieme a Tiller all'interno di werf. .
Ora werf è un componente molto più integrato. Otteniamo un timone pronto, un perno di comando: non sono molto esperto di automobili, ma si tratta di un grande blocco che risolve un ampio spettro di problemi. Non dobbiamo più cercare nel catalogo, abbinare un pezzo all'altro, pensando a come assemblare il tutto. Riceviamo un combinato pronto che affronta subito molteplici sfide. Ma all'interno è costituito da tutti gli stessi componenti open source, utilizza ancora Docker per la compilazione, Helm per parte delle funzionalità, e ci sono anche altre librerie. È uno strumento integrato per ottenere rapidamente e facilmente un eccellente CI/CD out-of-the-box.
È difficile mantenere Kubernetes?
— Parli della tua esperienza con Kubernetes, è per voi un telaio, un motore, e su di esso si possono montare molte cose diverse: carrozzeria, volante, pedali, sedili. Sorgono domande: quanto è difficile per voi mantenere Kubernetes? Avete una grande esperienza; quanto tempo e risorse dedicate specificamente al mantenimento di Kubernetes, separatamente da tutto il resto?
Dmitrij: È una domanda molto complessa e, per rispondere, bisogna capire cosa si intende per manutenzione e cosa vogliamo da Kubernetes. Potresti chiarire?
— Per quanto ne so e come vedo, molte squadre vogliono provare Kubernetes. Tutti si stanno cimentando, installandolo in modo rudimentale. Ho l'impressione che le persone non comprendano sempre la complessità di questo sistema.
Dmitrij: Esattamente.
— Quanto è difficile installare Kubernetes da zero affinché sia production ready?
Dmitrij: Cosa ne pensi, quanto è difficile trapiantare un cuore? Capisco che la domanda è compromettente. Usare un bisturi senza errori non è così difficile. Se ti dicono dove tagliare e dove suturare, l'intera procedura non è complessa. La difficoltà sta nel garantire ogni volta che tutto funzioni.
Installare Kubernetes e farlo funzionare è semplice: clic! — è installato, ci sono molteplici metodi di installazione. Ma cosa succede quando sorgono problemi?
Sorgono sempre domande — cosa ci siamo dimenticati? Cosa non abbiamo fatto? Quali parametri del kernel Linux abbiamo impostato in modo errato? Oh cielo, li abbiamo impostati?! Quali componenti di Kubernetes abbiamo installato e quali no? Migliaia di domande si presentano, e per rispondere a queste occorrono 15-20 anni di esperienza nel settore.
Ho un esempio recente su questo tema che può rivelare il senso del problema: "È difficile mantenere Kubernetes?". Tempo fa abbiamo seriamente considerato l'idea di implementare Cilium come rete in Kubernetes.
Spiegherò cosa sia Cilium. In Kubernetes ci sono molteplici implementazioni del sottosistema di rete, e una di esse è davvero notevole: è Cilium. Qual è il suo scopo? Nel kernel, alcuni tempo fa è stata introdotta la possibilità di scrivere hook per il kernel, che in vari modi si intrecciano con il sottosistema di rete e altri sottosistemi, consentendo di bypassare grandi porzioni del kernel.
Nel kernel Linux ci sono storicamente ip rout, netfilter, bridge e molti altri componenti vecchi di 15, 20 o anche 30 anni. In generale funzionano, tutto è a posto, ma ora ci sono così tanti contenitori che sembra una torre di 15 mattoni l'uno sopra l'altro, e tu ci stai in equilibrio su una gamba — è una sensazione strana. Questo sistema si è sviluppato storicamente con molte sfumature, come un appendice nel corpo. In alcune situazioni ci sono problemi di performance, ad esempio.
C'è un fantastico BPF e la possibilità di scrivere hook per il kernel — le persone hanno scritto i loro hook per il kernel. Un pacchetto arriva nel kernel Linux, loro lo estraggono direttamente all'ingresso, lo elaborano come necessario senza bridge, senza TCP, senza lo stack IP — insomma, bypassano tutto ciò che è scritto nel kernel Linux e lo rilasciano subito nel contenitore.
Cosa ne è venuto fuori? Una performance fantastica, funzioni eccezionali — semplicemente incredibile! Ma osserviamo questo e vediamo che su ogni macchina c'è un programma che si connette all'API Kubernetes e, in base ai dati ricevuti da questa API, genera codice C e compila i binari che vengono caricati nel kernel, affinché questi hook funzionino nello spazio del kernel.
Cosa succede se qualcosa va storto? Non lo sappiamo. Per capirlo, bisogna leggere tutto questo codice, capire tutta la logica, e non è affatto facile. D'altra parte, ci sono questi bridge, net-filter, ip rout — io non ho letto il loro codice sorgente, e nemmeno i 40 ingegneri che lavorano nella nostra azienda. Forse solo alcune persone ne comprendono alcuni pezzi.
E che differenza fa? Ci sono ip rout, il kernel Linux, e c'è un nuovo strumento — che importa, non comprendiamo l'uno né l'altro. Ma abbiamo paura di usare il nuovo — perché? Perché se uno strumento ha 30 anni, in 30 anni tutti i bug sono stati trovati, si sono incontrati tutti gli ostacoli e sapere tutto non è necessario — funziona come una scatola nera, e funziona sempre. Tutti sanno quale cacciavite diagnostico infilare in quale posto, quale tcpdump avviare in quale momento. Tutti conoscono bene gli strumenti diagnostici e comprendono come questo insieme di componenti funzioni nel kernel Linux — non come è fatto, ma come utilizzarlo.
Cilium non ha 30 anni, non è ancora maturo. Lo stesso problema esiste con Kubernetes: entrambi si installano bene, ma quando qualcosa va storto in produzione, sarete in grado di comprendere rapidamente cosa sia andato storto in una situazione critica?
Quando si parla di quanto sia difficile mantenere Kubernetes, la risposta è sia semplice che incredibilmente complessa. Kubernetes funziona perfettamente da solo, ma ci sono miliardi di dettagli da considerare.
Sull'approccio del 'Tanto vale tentare'
— Ci sono aziende dove questi dettagli appariranno quasi sicuramente? Immaginiamo che Yandex decida di migrare tutti i servizi su Kubernetes; lì ci sarà un carico incredibile.
Dmitrij: No, non si tratta di carichi, ma di cose semplici. Ad esempio, supponiamo di avere Kubernetes, e abbiamo deploato un'applicazione. Come possiamo sapere se sta funzionando? Non esiste uno strumento pronto per capire se l'applicazione non va in crash. Non c'è un sistema pronto che invii avvisi: bisogna configurare questi avvisi e ogni grafico. E noi stiamo aggiornando Kubernetes.
C'è Ubuntu 16.04. Si potrebbe dire che sia una versione obsoleta, ma noi siamo ancora su di essa, perché è LTS. È presente systemd, il cui dettaglio è che non pulisce i C-group. Kubernetes avvia i pod, crea i C-group, poi elimina i pod, e in qualche modo — non ricordo i dettagli, scusate — rimangono degli slice di systemd. Questo porta al fatto che, nel tempo, qualsiasi macchina inizia a rallentare considerevolmente. Non si tratta nemmeno di highload. Se ci sono pod in esecuzione costante, ad esempio, se c'è un Cron Job che genera continuamente pod, la macchina con Ubuntu 16.04 inizierà a rallentare dopo una settimana. Ci sarà sempre un alto load average a causa della creazione di un sacco di C-group. Questo è un problema con cui si imbatte chiunque installi semplicemente Ubuntu 16 e poi Kubernetes sopra.
Immagina che in qualche modo aggiorni systemd o qualcos'altro, ma nel kernel Linux fino alla versione 4.16 è ancora più divertente: quando si rimuovono i C-group, continuano a persistere nel kernel e, di fatto, non vengono eliminati. Quindi, dopo un mese di utilizzo di questa macchina, diventa impossibile controllare le statistiche sulla memoria delle pod. Prendiamo un file, lo eseguiamo nel programma, e un file ci impiega 15 secondi, perché il kernel impiega molto tempo a contare internamente un milione di C-group che sembrano essere stati rimossi, ma non lo sono: continuano a persistere.
Ci sono ancora molte piccole cose qui e là. Non si tratta di un problema che le aziende giganti possono talvolta affrontare sotto carichi enormi: no, è una questione di cose quotidiane. Le persone possono vivere così per mesi: hanno installato Kubernetes, implementato un'applicazione: sembra funzionare. A molti va bene così. Su quando mai quell'applicazione possa cadere, non lo sapranno nemmeno, l'allerta non arriverà, ma per loro è normale. Prima vivevano su macchine virtuali senza monitoraggio, ora sono passati a Kubernetes, sempre senza monitoraggio: quale differenza?
La questione è che quando camminiamo sul ghiaccio, non sappiamo mai la sua spessore se non lo abbiamo misurato in anticipo. Molti camminano senza preoccuparsene, perché in passato l'hanno fatto.
Dal mio punto di vista, il dettaglio e la complessità nell'utilizzo di qualsiasi sistema risiedono nel garantire che lo spessore del ghiaccio sia sufficiente per risolvere i nostri compiti. Questo è il punto.
Nell'IT, mi sembra che ci siano troppi approcci basati su ‘spero di avere fortuna’. Molti installano software, utilizzano librerie software nella speranza di avere successo. In generale, a molti va bene. Probabilmente è per questo che funziona.
— Dalla mia valutazione pessimistica, sembra così: quando i rischi sono elevati e l'applicazione deve funzionare, è necessaria assistenza da 'Flant', forse da Red Hat, oppure è richiesta una propria squadra interna dedicata a Kubernetes, pronta a supportarlo.
Dmitrij: Oggettivamente è così. Entrare autonomamente nel mondo di Kubernetes per un piccolo team comporta un certo numero di rischi.
Abbiamo bisogno di contenitori?
— Puoi dirmi quanto è diffuso Kubernetes in Russia?
Dmitrij: Non ho questi dati e non sono sicuro che esista qualcuno che li abbia. Diciamo: 'Kubernetes, Kubernetes', ma ci sono anche altre opinioni su questo tema. Non so nemmeno quanto siano diffusi i container, ma so che secondo i rapporti online, il 70% dei container è orchestrato da Kubernetes. Questa era una fonte affidabile su un campione piuttosto ampio a livello mondiale.
Poi c'è un'altra domanda: abbiamo bisogno dei container? Ho la sensazione personale e, in generale, la posizione della 'Flant' è che Kubernetes sia lo standard di fatto.
Non ci sarà nulla oltre a Kubernetes.
È un assoluto game-changer nel campo della gestione dell'infrastruttura. Assolutamente — niente più Ansible, Chef, macchine virtuali, Terraform. E non parlo nemmeno dei vecchi metodi superati. Kubernetes è un vero e proprio cambio di paradigma, e d'ora in poi sarà solo così.
È chiaro che ci vorranno un paio d'anni per alcuni, o addirittura decenni per altri, per rendersi conto di questo. Non ho dubbi che non ci sarà niente oltre a Kubernetes e a questa nuova visione: non colpiremo più il sistema operativo, ma useremo infrastructure as code, solo che 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 migrate a Kubernetes, lo faranno sicuramente o scompariranno. Ho capito bene?
Dmitrij: Questo non è del tutto corretto. Ad esempio, se abbiamo il compito di avviare un server DNS, possiamo farlo su FreeBSD 4.10 e funzionerà bene per 20 anni. Solo per funzionare e basta. Forse, dopo 20 anni, sarà necessario aggiornare qualcosa una sola volta. Se parliamo di software che abbiamo avviato e che funziona davvero per molti anni senza aggiornamenti, senza modifiche, certamente lì 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 un'architettura a prova di guasto — solo Kubernetes.
Su microservizi
— Qui ho un piccolo dissonanza. Per lavorare con Kubernetes è necessaria un supporto esterno o interno — questo è il primo punto. Il secondo è che, quando iniziamo a sviluppare, siamo una piccola startup e non abbiamo nulla; lo sviluppo su Kubernetes o in generale su architetture microservizi può essere difficile e non sempre giustificato economicamente. Sono curioso del tuo punto di vista — devono le startup partire subito scrivendo per Kubernetes, o possono prima realizzare un monolite e poi eventualmente passare a Kubernetes?
Dmitrij: Ottima domanda. Ho una presentazione sui microservizi. Mi è capitato molte volte di vedere persone che cercano di piantare chiodi con il microscopio. Il metodo da solo è corretto, stiamo progettando il nostro software interno proprio in questo modo. Ma quando lo si fa, è importante avere chiaro cosa si sta facendo. Ciò che odio di più nei microservizi è la parola «micro». Storicamente, è nato questo termine 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 sanno che ci sono dei problemi, e che bisognerebbe suddividerlo in micro-pezzetti — circa 10, ognuno dei quali viene scritto da un minimo di 30 persone. Questo è importante, necessario e fantastico. Ma quando ci arriva una startup con 3 ragazzi molto bravi e talentuosi che hanno scritto in fretta 60 microservizi, ogni volta cerco un rimedio.
Mi sembra che di questo se ne sia già parlato migliaia di volte — abbiamo ottenuto un monolite distribuito in una forma o nell'altra. Questo non è economicamente sostenibile, è molto complicato 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, Kubernetes è spaventosamente complicato da usare, perché non è chiaro cosa si possa rompere o non funzionare, e dall'altro lato, è chiaro che tutto sta andando in quella direzione e non ci sarà altro che Kubernetes. La risposta è valutare il volume di benefici che arrivano, e il volume di compiti che puoi risolvere.. Questo è da un lato della bilancia. Dall'altro lato ci sono i rischi associati a tempi di inattività o a un aumento dei tempi di risposta e del livello di disponibilità, che portano a una riduzione delle prestazioni.
La questione è questa: dobbiamo muoverci rapidamente, e Kubernetes consente di fare molte cose molto più velocemente e meglio, oppure dobbiamo utilizzare soluzioni consolidate e affidabili, ma ci muoveremo molto più lentamente. Ogni azienda deve prendere questa decisione. Si può considerare come un sentiero nella giungla: la prima volta che ci si avventura, si può incontrare un serpente, una tigre o un tasso arrabbiato, ma dopo averlo fatto dieci volte, si crea un percorso, si rimuovono i rami e si cammina più facilmente. Ogni volta il sentiero diventa più ampio. Poi diventa una strada asfaltata e infine un bel boulevard.
Kubernetes non si ferma mai. Tornando alla domanda: da un lato, Kubernetes è composto da 4-5 binari, dall'altro è tutta un'ecosistema. È un sistema operativo che installiamo sulle macchine. Che cosa è? Ubuntu o Curios? È il kernel Linux, una serie di componenti aggiuntivi. Tutte queste cose hanno gettato una vipera velenosa dalla strada, hanno messo una recinzione lì. Kubernetes si sta evolvendo rapidamente e dinamicamente, e il volume dei rischi, l'ignoto, diminuisce ogni mese e, di conseguenza, questi equilibri si riequilibrano.
Rispondendo alla domanda su cosa dovrebbe fare una startup, direi: venite a «Flant», pagate 150.000 rubli e riceverete un servizio DevOps chiavi in mano. Se siete una piccola startup con alcuni sviluppatori, questo funziona. Anziché assumere un vostro DevOps, che dovrà imparare a risolvere i vostri problemi e nel frattempo essere pagato, otterrete una soluzione completa per tutte le vostre esigenze. Certo, ci sono alcuni svantaggi. Come outsourcer, non possiamo essere così coinvolti e reagire rapidamente ai cambiamenti. Tuttavia, abbiamo un'enorme esperienza e pratiche consolidate. Garantiamo che in qualsiasi situazione saremo in grado di comprendere rapidamente e sollevare qualsiasi Kubernetes da quella situazione.
Raccomando categoricamente l'outsourcing per startup e aziende consolidate fino a quando non si può assegnare un team di 10 persone per le operazioni, perché altrimenti non ha senso. Ha assolutamente senso farlo in outsourcing.
Su Amazon e Google
— È possibile considerare come outsourcing l'hosting offerto da Amazon o Google?
Dmitrij: Sì, certo, questo risolve alcune questioni. Ma ci sono sempre dei dettagli. È comunque necessario comprendere come utilizzarlo. Ad esempio, ci sono mille piccole cose nel lavoro con Amazon AWS: è necessario riscaldare il Load Balancer o inviare in anticipo una richiesta, dicendo 'ragazzi, ci arriverà del traffico, riscaldateci il Load Balancer!' Questi dettagli devono essere conosciuti.
Quando ti rivolgi a persone specializzate in questo campo, ottieni quasi tutte le questioni standard già risolte. Abbiamo attualmente 40 ingegneri e probabilmente ne avremo 60 entro fine anno – ci siamo sicuramente già confrontati con tutte queste problematiche. Anche se in un progetto ci troviamo nuovamente di fronte a questo problema, chiediamo velocemente all'uno o all'altro e sappiamo come risolverlo.
Probabilmente, la risposta è questa: certo, la storia dell'hosting facilita in qualche modo. La domanda è se sei pronto a fidarti di questi host e se risolveranno i tuoi problemi. Amazon e Google hanno dimostrato di essere affidabili. Per tutti i nostri casi, certamente. Non abbiamo altre esperienze positive. Tutti gli altri servizi cloud con cui abbiamo provato a lavorare creano moltissimi problemi: Ager, e tutto ciò che esiste in Russia, così come diversi OpenStack in varie implementazioni: Headster, Overage — tutto ciò che vuoi. Creano tutti problemi che preferiremmo non affrontare.
Quindi, la risposta è sì, ma in realtà, le soluzioni hosted mature non sono molte.
A chi serve Kubernetes?
— Eppure, a chi serve Kubernetes? Chi dovrebbe già passare a Kubernetes, chi è il tipico cliente di 'Flant' che si presenta esattamente per Kubernetes?
Dmitrij: La domanda è interessante perché ora, con la crescente popolarità di Kubernetes, molte persone ci contattano dicendo: «Ragazzi, sappiamo che lavorate con Kubernetes, fatecelo!». Noi rispondiamo: «Signori, noi non realizziamo Kubernetes, noi costruiamo produzione e tutto ciò che comporta». Perché realizzare una produzione senza impostare tutto il CI/CD e tutta questa storia è semplicemente impossibile al giorno d'oggi. Tutti hanno abbandonato la divisione tra sviluppo e operatività.
I nostri clienti hanno aspettative diverse, ma tutti sperano in una sorta di meraviglia, che possano avere determinati problemi e poi, puff! — Kubernetes li risolverà. La gente crede nei miracoli. Razionalmente capiscono che non ci sarà alcun miracolo, ma dentro di sé sperano — e se questo Kubernetes risolvesse tutto, visto che se ne parla tanto! Magari adesso è la chiave magica, puff! — e abbiamo il 100% di uptime, tutti gli sviluppatori possono rilasciare qualsiasi cosa in produzione 50 volte e non crolla. Insomma, un miracolo!
Quando persone di questo tipo vengono da noi, diciamo: «Mi dispiace, ma non ci sono miracoli». Per essere sani, è necessario mangiare bene e fare sport. Per avere un server affidabile, deve essere realizzato con cura. Per avere un CI/CD comodo, deve essere progettato in modo adeguato. Si tratta di un lavoro impegnativo che deve essere svolto.
Rispondendo alla domanda su chi ha bisogno di Kubernetes – Kubernetes non è necessario per nessuno.
Alcune persone hanno una percezione errata di aver bisogno di Kubernetes. Le persone desiderano, sentono un bisogno profondo di smettere di pensare, occuparsi e interessarsi a tutti i problemi infrastrutturali e al lancio delle loro applicazioni. Vogliono che le applicazioni funzionino semplicemente e vengano distribuite. Per loro, Kubernetes è la speranza di non dover più sentire la storia di «ci siamo arenati» o «non possiamo andare in produzione», o altro.
Di solito ci contatta il CTO. Da lui si chiedono due cose: da un lato, nuove funzionalità, dall'altro, stabilità. Noi proponiamo di prenderci carico di questo e realizzarlo. La soluzione ideale è che tu smetta di pensare a questi problemi e di perdere tempo. Avrai persone dedicate che si occuperanno di questo.
L'affermazione che a noi o a qualcun altro serva Kubernetes è sbagliata.
Kubernetes è molto importante per gli amministratori, perché è un giocattolo davvero interessante, con cui si può sperimentare. Siamo onesti: a tutti piacciono i giochi. Siamo tutti un po' bambini, e quando vediamo una novità vogliamo provarla. Alcuni ne hanno perso il fascino, ad esempio nel lavoro di amministrazione, perché ci si è già divertiti e si è stanchi. Ma nessuno l'ha completamente abbandonato. Anche se per me i giochi in ambito sistemistico e DevOps hanno perso il loro fascino da un po', continuo comunque ad amare i giocattoli ed acquisto sempre qualcosa di nuovo. Tutti, in un modo o nell'altro, vogliono sempre dei nuovi giochi.
Non dovresti giocare con la produzione. Cosa non raccomando categoricamente di fare e cosa vedo ora in massa: "Oh, un nuovo giocattolo!" — si corre a comprarlo, si compra e: "Portiamolo a scuola ora, mostriamolo a tutti gli amici". Non fatelo. Mi scuso, ma ho solo bambini che crescono, vedo costantemente qualcosa in loro, lo noto in me stesso e poi generalizzo agli altri.
Risposta definitiva: non hai bisogno di Kubernetes. Devi risolvere i tuoi problemi.
Puoi ottenere che:
- la produzione non crolla;
- anche se cerca di crollare, lo sappiamo in anticipo e possiamo farci qualcosa;
- possiamo cambiarlo con la velocità di cui abbiamo bisogno per gli affari, e farlo comodamente, senza problemi.
Ci sono due bisogni reali: affidabilità e dinamicità/flessibilità nel rilascio. A coloro che attualmente fanno progetti IT, indipendentemente dal business in cui si trovano - software per semplificare il mondo, e chi lo capisce, deve affrontare queste necessità. Kubernetes, con l'approccio giusto, la giusta comprensione e una sufficiente esperienza, permette di affrontarle.
Pro serverless
— Se guardiamo un po' più in là nel futuro, affrontando il problema dell'assenza di mal di testa legato all'infrastruttura, alla velocità di rilascio e alla rapidità di cambiamento delle applicazioni, emergono nuove soluzioni, come il serverless. Vedi del potenziale in questa direzione e, per così dire, una minaccia per Kubernetes e soluzioni simili?
Dmitrij: Qui bisogna fare nuovamente una precisazione, ovvero che non sono un veggente che guarda avanti e dice - sarà così! Anche se poco fa stavo facendo la stessa cosa. Guardo sotto ai piedi e vedo un sacco di problemi, come funzionano i transistor nei computer. È quasi ridicolo, vero? Ci troviamo ad affrontare alcuni bug nel CPU.
Rendere il serverless sufficientemente affidabile, economico, efficiente e conveniente, risolvendo tutte le problematiche dell'ecosistema. Qui sono d'accordo con Elon Musk, che serve un secondo pianeta per garantire la resilienza per l'umanità. Anche se non so cosa stia dicendo, capisco che non sono pronto per volare su Marte e che non sarà domani.
Con serverless è chiaro che sia una cosa ideologicamente corretta, come la ridondanza per l'umanità: avere due pianeti è meglio che uno. Ma come possiamo realizzarlo ora? Inviare un'ippopotamo non è un problema se si concentrano gli sforzi su questo. Manderemo più spedizioni e colonizzeremo lì diverse migliaia di persone; penso che sia realistico. Tuttavia, rendere tutto il sistema di ridondanza in modo che metà dell'umanità abiti lì, mi sembra attualmente impossibile, non fattibile.
Con serverless è la stessa cosa: è una grande idea, ma è lontana dai problemi del 2019. Verso il 2030, speriamo di arrivarci. Non ho dubbi che ci arriveremo, ci arriveremo di sicuro (ripetete prima di andare a dormire), ma ora dobbiamo affrontare altri problemi. È come credere in un unicorno. Sì, una manciata di casi si risolvono, e si risolvono splendidamente, ma soggettivamente serverless è un arco di risoluzione... Per me questo argomento è troppo distante e troppo incomprensibile. Non sono pronto per parlare. Nel 2019 non puoi scrivere nessuna applicazione con serverless.
Come si svilupperà Kubernetes
— Mentre ci dirigiamo verso questo potenziale meraviglioso futuro, come pensi che si evolutionerà Kubernetes e l'ecosistema che lo circonda?
Dmitrij: Ho riflettuto molto su questo e ho una risposta chiara. Prima di tutto, fare qualcosa di stateful è più complesso rispetto a gestire uno stateless. Kubernetes ha investito di più in questo fin dall'inizio; è da qui che tutto è cominciato. Lo stateless funziona praticamente alla perfezione in Kubernetes, non ci sono problemi. Per lo stateful ci sono ancora un sacco di problemi, o meglio, dettagli. Qui funziona già tutto benissimo, ma riguarda noi. Affinché tutti possano farlo funzionare, ci vorranno ancora almeno un paio d'anni. Non è una previsione accademica, ma un'impressione personale.
In breve, lo stateful deve – e si svilupperà – molto, perché tutte le nostre applicazioni salvano uno stato; non esistono applicazioni stateless. È un'illusione; è sempre necessaria qualche forma di database e altro. Lo stateful rappresenta l'ottimizzazione di tutto ciò che si può, la correzione di tutti i bug e il miglioramento di tutte le problematiche attuali – chiamiamolo adoption.
Il livello dell'inesplorato, il livello dei problemi irrisolti, il livello della probabilità di imbattersi in qualcosa, diminuirà drasticamente. Questa è una storia importante. E gli operatori - tutto ciò che riguarda la codificazione della logica di amministrazione, la logica di gestione, per ottenere un servizio semplice: servizio MySQL semplice, servizio RabbitMQ semplice, servizio Memcache semplice - tutti questi componenti sono esattamente ciò di cui abbiamo bisogno per garantire un funzionamento fuori dalla scatola. Questo affronta proprio i problemi che vogliamo avere un database, ma non vogliamo amministrarlo, o vogliamo Kubernetes, ma non vogliamo amministrarlo.
Questa storia dello sviluppo degli operatori, in una forma o nell'altra, sarà importante nei prossimi anni.
Penso che la semplicità di utilizzo debba aumentare notevolmente - la scatola diventerà sempre più nera, sempre più affidabile, con manopole sempre più semplici.
Una volta ascoltavo una vecchia intervista a 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. Disse che il futuro risiedeva nella semplicità, come era per la radio. Inizialmente, la radio era complicata. Per ricevere un segnale, bisognava girare i manopole per 15 minuti, conoscere il funzionamento e capire la fisica delle onde radio. Alla fine, nella radio è rimasta solo un manopola.
Ora, nel 2019, quale radio? Nella macchina, il ricevitore trova tutte le onde e i nomi delle stazioni. La fisica del processo non è cambiata negli ultimi 100 anni, è cambiata la facilità d'uso. Adesso, e non solo adesso, già nel 1980, quando c'era l'intervista con Asimov, tutti usavano la radio e nessuno si chiedeva come funzionasse. Funzionava sempre — è un dato di fatto.
Asimov all'epoca diceva che per i computer sarebbe stato simile — 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à così.
Ho la sensazione che anche con Kubernetes la facilità d'uso aumenterà notevolmente. È, a mio avviso, evidente — è chiaro.
Cosa fare con gli ingegneri?
— E cosa accadrà agli ingegneri e agli amministratori di sistema che supportano Kubernetes?
Dmitrij: E cosa è successo al contabile dopo l'arrivo di 1C? È più o meno la stessa cosa. Prima si facevano i calcoli su carta — ora si fa con il software. La produttività è aumentata enormemente, e il lavoro non è scomparso. Se prima servivano 10 ingegneri per cambiare una lampadina, ora ne basterà uno.
Il numero di software e il numero di compiti, mi sembra, crescono ora a una velocità superiore alla formazione di nuovi DevOps e al miglioramento dell'efficienza. Attualmente c'è una carenza concreta nel mercato, e questa durerà a lungo. Successivamente tutto tornerà a una certa normalità, durante la quale l'efficienza del lavoro aumenterà, ci sarà sempre più serverless, Kubernetes sarà dotato di intelligenza artificiale, che selezionerà tutte le risorse esattamente come necessario, e in generale farà tutto da sola, come serve — l'uomo dovrà solo ritirarsi e non disturbare.
Le decisioni dovranno comunque essere prese da qualcuno. È chiaro che il livello di qualificazione e specializzazione di questa persona è superiore. Attualmente, nel reparto contabilità non avete bisogno di 10 dipendenti che gestiscano i libri contabili per non affaticare la mano. Non è necessario. Molti documenti vengono automaticamente scansionati e riconosciuti dal sistema di gestione documentale. Basta un intelligente capo contabile, già dotato di competenze superiori e di una buona comprensione.
In generale, questo è un percorso comune in tutti i settori. È lo stesso con le automobili: in passato ogni auto veniva accompagnata da un meccanico e tre conducenti. Oggi, guidare un'auto è un processo semplice, in cui tutti noi partecipiamo ogni giorno. Nessuno si ferma a pensare che l'auto sia qualcosa di complicato.
DevOps o ingegneria dei sistemi non scompariranno: l'alto livello e l'efficienza del lavoro continueranno a crescere.
— Ho sentito un'idea interessante, che in realtà il lavoro aumenterà.
Dmitrij: Certo, al cento per cento! Perché il numero di software che sviluppiamo è in costante aumento. Anche le domande a cui rispondiamo con il software stanno crescendo. Il lavoro sta crescendo. Attualmente, il mercato DevOps è estremamente surriscaldato. Questo è evidente dalle aspettative salariali. In linea di massima, senza entrare nei dettagli, dovrebbero esserci dei junior che chiedono X, dei mid-level che chiedono 1,5X e dei senior che chiedono 2X. E ora, guardando il mercato dei salari DevOps a Mosca, un junior chiede da X a 3X e un senior chiede da X a 3X.
Nessuno sa quanto costa. Il livello salariale è misurato dalla tua fiducia — è un completo caos, onestamente, un mercato estremamente surriscaldato.
Certo, questa situazione cambierà molto presto — ci deve essere un certo saturamento. Con lo sviluppo del software però non è così — nonostante gli sviluppatori siano richiesti ovunque, e che ci siano bisogno di buoni sviluppatori, il mercato capisce chi vale quanto — l'industria si è stabilizzata. Con DevOps non è così.
— Da quello che ho sentito, ho concluso che il sistemista attuale non deve preoccuparsi troppo, ma è il momento di migliorare le proprie competenze e prepararsi al fatto che domani ci sarà più lavoro, ma sarà di livello più qualificato.
Dmitrij: Assolutamente. In generale viviamo nel 2019 e la regola della vita è questa: lifetime learning — apprendiamo per tutta la vita. Mi sembra che ora tutti lo sappiano e lo provino, ma sapere non basta — bisogna agire. Ogni giorno dobbiamo cambiare. Se non lo facciamo, prima o poi ci lasceranno ai margini della professione.
Siate pronti a cambiamenti repentini di 180 gradi. Non escludo situazioni in cui tutto cambierà radicalmente, verrà inventato qualcosa di nuovo — succede. E così, all’improvviso, iniziamo a comportarci in modo diverso. È importante essere pronti a tutto ciò e non preoccuparsi. Può accadere che domani tutto ciò che faccio si riveli inutile — ma va bene, ho studiato per tutta la vita e sono pronto per imparare qualcosa di nuovo. Non è un problema. Non c'è bisogno di temere per la sicurezza del lavoro, ma bisogna essere pronti ad apprendere costantemente.
Auguri e un momento di pubblicità
— Hai qualche desiderio?
Dmitrij: Sì, ho alcune richieste.
La prima e più mercenaria è di iscrivervi a . Gentili lettori, visitate il nostro canale YouTube e iscrivetevi. Tra circa un mese inizieremo un'espansione attiva sul servizio video con una grande quantità di contenuti didattici su Kubernetes, che coprirà vari aspetti: da pratiche concrete fino a laboratori e concetti teorici fondamentali, su come applicare Kubernetes a livello di principi e modelli.
La seconda richiesta mercenaria è di visitare e mettere delle stelle, perché noi ci nutriamo di esse. Se non ci metterete stelle, non avremo nulla da mangiare. È come la manna in un videogioco. Facciamo qualcosa, ci impegniamo, alcuni dicono che sono biciclette brutte, altri che è tutto sbagliato, ma continuiamo e agiamo in modo completamente onesto. Vediamo un problema, lo risolviamo e condividiamo la nostra esperienza. Quindi, mettete una stella, non vi costerà nulla e a noi porterà qualcosa, perché di esse ci nutriamo.
La terza, importante e già non mercenaria richiesta è di smettere di credere nelle favole. Вы — профессионалы. DevOps — это очень серьезная и ответственная профессия. Перестаньте играть на рабочем месте. Пусть вас щелкнет, и вы поймете это. Представьте, что вы придёте в больницу, а там доктор на вас экспериментирует. Понимаю, что кому-то это может быть обидно, но, скорее всего, это же не про вас, а про кого-то другого. Скажите другим, чтобы они тоже перестали. Это реально портит жизнь всем нам — многие начинают относиться к эксплуатации, к админам и к DevOps’ам, как к чувакам, которые опять что-то поломали. Это «поломали» чаще всего из-за того, что мы пошли играться, а не холодным сознанием посмотрели, что тут так, а тут так.
Это не означает, что не надо экспериментировать. Экспериментировать надо, мы сами так делаем. Если быть честным, мы сами еще и играемся иногда — это, конечно, очень плохо, но ничто человеческое нам не чуждо. Давайте 2019 год объявим годом серьезных продуманных экспериментов, а не игр на проде. Наверное, так.
— Большое спасибо!
Dmitrij: Grazie a te, Vitaly, per il tempo e per l'intervista. Cari lettori, grazie mille a voi se siete arrivati a questo punto. Spero che almeno un paio di riflessioni vi abbiamo portato.
Nell'intervista, Dmitry ha toccato il tema di werf. Ora è un coltellino svizzero universale che risolve quasi tutti i problemi. Ma non è sempre stato così. Su al festival Dmitry Stolyarov parlerà di questo strumento in dettaglio. Nella sua presentazione ci sarà tutto: problemi e aspetti nascosti di Kubernetes, soluzioni a queste difficoltà e l'attuale implementazione di werf in dettaglio. Unitevi a noi il 27 e 28 maggio, creeremo strumenti ideali.
Fonte: habr.com
