In de aanloop naar Vitaly Khabarov had een interview met Dmitry Stolyarov (), technisch directeur en medeoprichter van het bedrijf «Flant». Vitaly vroeg Dmitry naar wat «Flant» doet, over Kubernetes, de ontwikkeling van het ecosysteem, ondersteuning. Ze bespraken de noodzaak van Kubernetes en of het ĂŒberhaupt nodig is. En ook over microservices, Amazon AWS, de benadering 'Ik heb geluk' in DevOps, de toekomst van Kubernetes, waarom, wanneer en hoe het de wereld zal veroveren, de vooruitzichten van DevOps en waar engineers zich op moeten voorbereiden in de nabije toekomst met vereenvoudiging en neurale netwerken.
is te beluisteren als podcast op DevOps Deflope â een Russischtalige podcast over DevOps, en hieronder is de tekstversie.
Hier en verder stelt hij vragen een engineer van Express42.
Over «Flant»
â Dima, hallo. Jij bent de technisch directeur van «» en ook de oprichter ervan. Vertel alsjeblieft, waar houdt het bedrijf zich mee bezig en wat doe jij daarin?
Dmitry: Van buitenaf lijkt het alsof wij de jongens zijn die overal Kubernetes installeren en daar iets mee doen. Maar dat is niet zo. We zijn begonnen als een bedrijf dat zich bezighield met Linux, maar al geruime tijd is onze belangrijkste activiteit het beheren van productie- en highload-projecten op maat. Gewoonlijk bouwen we de hele infrastructuur vanaf nul en zijn vervolgens verantwoordelijk voor het onderhoud daarvan. Daarom is het belangrijkste werk dat «Flant» doet, en waarvoor we betaald worden â het nemen van verantwoordelijkheid en het realiseren van productie op maat.
Ik, als technisch directeur en een van de oprichters van het bedrijf, houd me de klok rond bezig met het verzinnen van manieren om de beschikbaarheid van productie te verhogen, het gebruik ervan te vereenvoudigen, het leven van administrators te vergemakkelijken, en het leven van ontwikkelaars aangenamer te maken.
Over Kubernetes
â De laatste tijd zie ik veel presentaties van «Flant» en over Kubernetes. Hoe zijn jullie daarbij gekomen?
Dmitry: Ik heb hier al veel over verteld, maar ik heb er totaal geen bezwaar tegen om het te herhalen. Ik vind het belangrijk om dit onderwerp te herhalen, omdat er verwarring ontstaat tussen oorzaak en gevolg.
We really needed a tool. We faced a lot of problems, struggled, overcame them with various workarounds, and felt the need for a tool. We sifted through many options, built our own solutions, and gained experience. Gradually, we started using Docker almost as soon as it appearedâaround 2013. By the time it launched, we already had a lot of experience with containers; we had even written our own version of âDockerââsome workarounds in Python. With the emergence of Docker, we could discard our workarounds and use a reliable, community-supported solution.
The story with Kubernetes is similar. By the time it started gaining tractionâspecifically version 1.2âwe already had a bunch of workarounds both in Shell and Chef, which we were trying to orchestrate Docker with. We were seriously looking into Rancher and various other solutions, but then Kubernetes appeared, implemented exactly as we would have done, or even better. There's nothing to criticize.
Yes, there are some unfinished parts here, some unfinished parts thereâlots of unfinished items, and 1.2 was really rough, but... Kubernetes is like a building under constructionâyou look at the project and understand that it will be great. If the building currently has a foundation and two floors, you realize that itâs better not to move in just yet, but with software, there are no such issuesâyou can already use it.
We never had a moment where we thought about whether to use Kubernetes or not. We were waiting for it long before it appeared and were even trying to create our own analogs.
About Kubernetes
â Are you directly involved in the development of Kubernetes itself?
Dmitry: Indirectly. We are more involved in developing the ecosystem. We send a certain number of pull requests: to Prometheus, various operators, Helmâin the ecosystem. Unfortunately, I canât keep track of everything we do and may be mistaken, but we havenât sent any pools to the core.
â At the same time, are you developing many of your own tools around Kubernetes?
Dmitry: The strategy is this: we contribute and pull request everything that already exists. If pull requests are not accepted there, we simply fork them for ourselves and live with our builds until they are accepted. Then, when it gets to upstream, we return to the upstream version.
Bijvoorbeeld, we hebben de Prometheus-operator, waarmee we al een keer of vijf heen en weer hebben geschakeld naar de upstream van onze build. We hebben een bepaalde functie nodig, we hebben een pull request verzonden, we moeten deze morgen uitrollen, en we willen niet wachten tot het in de upstream wordt uitgebracht. Daarom verzamelen we onze eigen functie, rollen we onze build met onze functie, die we om een of andere reden nodig hebben, uit naar al onze clusters. Dan wordt dit, bijvoorbeeld, in de upstream teruggegeven met de woorden: "Jongens, laten we dit voor een breder geval doen," en wij, of iemand anders, maken het af en uiteindelijk wordt het weer samengevoegd.
Alles wat bestaat, proberen we verder te ontwikkelen.. Veel elementen die er nog niet zijn, of die zijn uitgevonden maar nog niet zijn gerealiseerd â die maken we. En niet omdat we het proces zelf of het bouwen van fietsen als industrie leuk vinden, maar gewoon omdat we dit hulpmiddel nodig hebben. Vaak wordt de vraag gesteld waarom we dit of dat hebben gemaakt? Het antwoord is eenvoudig â omdat we verder moesten gaan, een praktisch probleem moesten oplossen, en deze tool heeft dat probleem opgelost.
De weg is altijd zo: we zoeken heel zorgvuldig en als we geen oplossing kunnen vinden, hoe je van een brood (deeg) een trolleybus maakt, dan maken we ons eigen brood en onze eigen trolleybus.
De tools van Flant
â Ik weet dat Flant momenteel addon-operators, shell-operators en dapp/werf-tools heeft. Zoals ik het begrijp, is dit dezelfde tool in verschillende incarnaties. Ook begrijp ik dat er binnen Flant nog veel verschillende tools zijn. Klopt dat?
Dmitry: We hebben nog veel meer op GitHub. Wat ik me nu herinner, is dat we statusmap hebben - een paneel voor Grafana dat iedereen heeft aangesproken. Het wordt bijna in elk tweede artikel over de monitoring van Kubernetes op Medium genoemd. Het is moeilijk om kort uit te leggen wat statusmap is - daarvoor is een apart artikel nodig, maar het is een zeer nuttige tool voor tijdsgebonden statusmonitoring, aangezien we in Kubernetes vaak de status over tijd moeten tonen. We hebben ook LogHouse - dit is een ding gebaseerd op ClickHouse en zwarte magie voor het verzamelen van logs in Kubernetes.
Veel tools! En er zullen er nog meer komen, omdat een aantal interne oplossingen dit jaar zal worden gelanceerd. Van de grote op basis van de addon-operator zijn er tal van addons voor Kubernetes, zoals hoe je de sert manager instelt - een hulpmiddel voor het beheren van certificaten, en hoe je Prometheus instelt met tal van extra's - dat zijn ongeveer twintig verschillende binaires die gegevens exporteren en iets verzamelen. Met Prometheus krijg je bovendien prachtige grafieken en meldingen. Dit alles zijn gewoon een heleboel addons voor Kubernetes die in de cluster worden geĂŻnstalleerd, waardoor het van een eenvoudige naar een geavanceerde, automatische omgeving verandert, waarin veel vraagstukken al zijn opgelost. Ja, we doen veel.
Ontwikkeling van het ecosysteem
â Ik denk dat dit een zeer grote bijdrage is aan de ontwikkeling van dit hulpmiddel en de methoden van gebruik. Kun je ongeveer inschatten wie nog zo'n bijdrage zou leveren aan de ontwikkeling van het ecosysteem?
Dmitry: In Rusland, van de bedrijven die op onze markt actief zijn - niemand komt zelfs maar in de buurt.. Natuurlijk is dit een gemotiveerde uitspraak, omdat er grote spelers zijn, zoals Mail en Yandex - zij doen ook iets met Kubernetes, maar zelfs zij komen niet in de buurt van de bijdragen van wereldwijde bedrijven die veel meer doen dan wij. Het is moeilijk om "Flant" te vergelijken met een team van 80 mensen en Red Hat, waarin, als ik me niet vergis, alleen al voor Kubernetes 300 ingenieurs werken. Het is moeilijk te vergelijken. In onze R&D-afdeling hebben we 6 mensen, inclusief mij, die al onze tools ontwikkelen. 6 mensen tegen 300 ingenieurs van Red Hat - dat is lastig te vergelijken.
â Toch, wanneer zelfs deze 6 mensen iets echt nuttigs en overdraagbaars kunnen creĂ«ren, wanneer ze worden geconfronteerd met een praktische taak en de oplossing aan de gemeenschap geven - dat is een interessant geval. Ik begrijp dat in grote technologiebedrijven, waar eigen ontwikkeling en een ondersteuningsteam voor Kubernetes zijn, in principe vergelijkbare tools kunnen worden ontwikkeld. Dit is voor hen een voorbeeld dat ze iets kunnen ontwikkelen en aan de gemeenschap kunnen geven, waardoor ze een impuls geven aan de hele gemeenschap die Kubernetes gebruikt.
Dmitry: Het is waarschijnlijk een functie van de integrator, zijn eigenschap. Wij hebben veel projecten en zien veel verschillende situaties. Voor ons is de belangrijkste manier om toegevoegde waarde te creëren het analyseren van deze gevallen, het vinden van gemeenschappelijke elementen en het zo kostenefficiënt mogelijk maken. Hier zijn we actief mee bezig. Het is moeilijk voor mij om over Rusland en de wereld te praten, maar we hebben ongeveer 40 DevOps-engineers in het bedrijf die zich met Kubernetes bezighouden. Ik denk niet dat er in Rusland veel bedrijven zijn met een vergelijkbaar aantal specialisten die zich met Kubernetes bezighouden, als ze er al zijn.
Ik begrijp alles over de functietitel DevOps-engineer, iedereen begrijpt het en is gewend om DevOps-engineers DevOps-engineers te noemen, daar zullen we niet over discussiëren. Al deze 40 geweldige DevOps-engineers stuiten elke dag op problemen en lossen die op; wij analyseren gewoon deze ervaring en proberen te generaliseren. We begrijpen dat als deze kennis bij ons binnen blijft, het over een jaar of twee onbruikbaar wordt, omdat er ergens in de community een kant-en-klaar hulpmiddel verschijnt. Het heeft geen zin om deze ervaring intern op te bouwen - het is gewoon een verspilling van kracht en tijd in dev/null. Aan de andere kant is het voor ons helemaal niet erg. We publiceren alles met veel plezier en begrijpen dat we het moeten publiceren, ontwikkelen, promoten en verspreiden, zodat mensen het gebruiken en hun ervaringen toevoegen - dan groeit en leeft alles. Dan gaat het hulpmiddel over twee jaar niet naar de vuilnisbak. Het is geen probleem om kracht te blijven investeren, omdat je ziet dat iemand je hulpmiddel gebruikt, en over twee jaar doet iedereen dat al.
Dit is onderdeel van onze grote strategie met dapp/werf. Ik kan me niet herinneren wanneer we begonnen zijn met het maken, het lijkt wel drie jaar geleden. Aanvankelijk was het helemaal in shell. Het was een super proof of concept; we hebben enkele van onze particuliere taken opgelost - het is gelukt! Maar er zijn problemen met shell, je kunt het daar niet verder opbouwen; programmeren in shell is iets anders. We hadden de gewoonte om in Ruby te schrijven, dus hebben we iets omgevormd in Ruby, ontwikkeld, ontwikkeld, ontwikkeld, maar we liepen tegen het punt aan dat de community, de menigte die zegt: 'we wensen of willen niet', de neus ophaalt voor Ruby, hoe grappig dat ook mag klinken. We hebben begrepen dat we al deze zaken in Go moeten schrijven om simpelweg aan het eerste punt in de checklist te voldoen: Een DevOps-hulpmiddel moet een statisch binaire bestand zijn.Of Go or not Go does not matter so much, but it is better to have a static binary written in Go.
We spent effort to rewrite the dapp in Go and named it werf. The dapp is no longer supported or developed, it works in some last version, but there is an absolute upgrade path upward, and it can be followed.
Why was the dapp created?
â Can you briefly explain why the dapp was created and what problems it solves?
Dmitry: The first reason is in the build process. Initially, we had significant problems with the build when Docker did not support multi-stage builds, and we created a multi-stage build ourselves. Then we had a bunch of questions regarding image cleanup. Everyone who does CI/CD sooner or later encounters the issue that there are a lot of built images, and we need to find a way to clean up what is unnecessary and keep what is needed.
The second reason is in the deploy process. Yes, there is Helm, but it only solves part of the tasks. Strangely enough, it is written that âHelm is the Package Manager for Kubernetes.â Indeed, it is âthe.â There are also the words âPackage Managerâ â what do we typically expect from a Package Manager? We say: âPackage Manager, install the package!â and expect it to respond: âPackage installed.â
Interestingly, we say: âHelm, install the package,â and when it responds that it has installed it, it turns out that it has only just started the installation â it instructed Kubernetes: âRun this thing!â but whether it has started or not, whether it works or not, Helm does not address this issue at all.
It turns out that Helm is just a text preprocessor that loads data into Kubernetes.
But within any deploy, we want to know â has the application been rolled out to production or not? Rolled out to production means that the application has been deployed there, a new version has been rolled out, and at least it is not crashing and is responding correctly. Helm does not solve this task at all. To solve it, we need to spend a lot of effort because we must give Kubernetes a command to deploy and monitor what is happening â whether it has been deployed, whether it has rolled out. And there are also many tasks related to deployment, cleaning up, and building.
Plannen
Dit jaar gaan we over op lokale ontwikkeling. We willen een situatie bereiken zoals vroeger met Vagrant â je typt "vagrant up" en je had je virtuele machines draaien. We willen het zo maken dat je een project hebt in Git, je typt daar "werf up" en het maakt lokaal een kopie van dat project in een lokale mini-Kub, met alle directories die handig zijn voor ontwikkeling gekoppeld. Afhankelijk van de programmeertaal gebeurt dit op verschillende manieren, maar we willen dat het gemakkelijk is om lokaal te ontwikkelen met gemonteerde bestanden.
De volgende stap voor ons is om aanzienlijk te investeren in de gebruiksvriendelijkheid voor ontwikkelaars. Met Ă©Ă©n tool gemakkelijk een project lokaal opzetten, ontwikkelen, naar Git pushen, en het zal op dezelfde manier worden uitgerold naar staging of tests, afhankelijk van de pipelines, en daarna met dezelfde tool naar productie gaan. Deze eenheid, uniformiteit en reproduceerbaarheid van infrastructuur van de lokale omgeving naar productie is voor ons een zeer belangrijk punt. Maar dat is momenteel nog niet aanwezig in werf â we zijn het alleen maar aan het plannen.
Maar de weg naar dapp/werf was altijd dezelfde als die voor Kubernetes in het begin. We stuitten op problemen, losten ze op met omwegen - we verzonnen oplossingen op shell, of wat dan ook. Daarna probeerden we deze omwegen te vereenvoudigen, te generaliseren en te consolideren in binaries die we vervolgens gewoon delen.
Er is ook een ander perspectief op dit hele verhaal, met analogieën.
Kubernetes is het chassis van een auto met de motor. Er zijn geen deuren, geen ramen, geen radio, helemaal niets. Alleen het frame en de motor. En daar is Helm - dat is het stuur. Geweldig - het stuur is er, maar we hebben ook een stuurpen, stuurinrichting, versnellingsbak en wielen nodig, anders kan het niet.
In het geval van werf - dit is nog een component voor Kubernetes. Alleen hebben we nu in de alpha versie van werf, bijvoorbeeld, Helm volledig in werf gecompileerd, omdat we het vervelend vonden om dit zelf te doen. Veel redenen om het zo te doen, en uitgebreid over waarom we helm volledig samen met tiller in werf hebben gecompileerd, zal ik net .
Tegenwoordig is werf een meer geĂŻntegreerde oplossing. We krijgen een kant-en-klare stuurinrichting, een stuurpin - ik ben niet erg bedreven in auto's, maar het is een groot blok dat al een behoorlijk scala aan taken oplost. We hoeven zelf niet door de catalogus te gaan, stukken bij elkaar te zoeken en na te denken over hoe ze aan elkaar te bevestigen. We krijgen een kant-en-klaar geheel dat meteen een groot aantal taken oplost. Maar van binnen is het nog steeds opgebouwd uit dezelfde open-sourcecomponenten, het gebruikt ook Docker voor de opbouw, Helm voor een deel van de functionaliteit, en er zijn nog een paar andere bibliotheken. Dit is een geĂŻntegreerde tool om snel en gemakkelijk een geavanceerd CI/CD-systeem uit de doos te krijgen.
Is het moeilijk om Kubernetes te onderhouden?
â Je vertelt over je ervaring met het gebruik van Kubernetes, dat het voor jullie een chassis, een motor is, en dat je er allemaal verschillende dingen aan kunt toevoegen: een behuizing, een stuur, pedalen, stoelen. De vraag rijst - hoe moeilijk is het voor jullie om Kubernetes te onderhouden? Jullie hebben veel ervaring, hoeveel tijd en middelen besteden jullie specifiek aan het onderhoud van Kubernetes naast alles andere?
Dmitry: Dit is een zeer moeilijke vraag en om te antwoorden, moet je begrijpen wat onderhoud inhoudt en wat we van Kubernetes willen. Misschien kun je dat uitleggen?
â Voor zover ik weet en zoals ik zie, willen veel teams tegenwoordig Kubernetes uitproberen. Iedereen stort zich erop en installeert het improviserend. Ik heb het gevoel dat mensen niet altijd de complexiteit van dit systeem begrijpen.
Dmitry: Dat klopt.
â Hoe moeilijk is het om Kubernetes van de grond af op te zetten, zodat het productieklaar is?
Dmitry: Hoe denk je dat het is om een harttransplantatie uit te voeren? Ik begrijp dat dit een confronterende vraag is. Met een scalpel werken en geen fouten maken is niet zo moeilijk. Als je te horen krijgt waar je moet snijden en waar je moet hechten, dan is de procedure op zich niet moeilijk. Het is moeilijk om keer op keer te garanderen dat alles goed gaat.
Kubernetes installeren en aan de praat krijgen is eenvoudig: hop! - het is geĂŻnstalleerd, er zijn veel manieren om te installeren. Maar wat gebeurt er als er problemen optreden?
Er komen altijd vragen op: wat hebben we nog niet overwogen? Wat hebben we nog niet gedaan? Welke parameters van de Linux-kernel hebben we verkeerd ingesteld? Mijn God, hebben we ze ĂŒberhaupt ingesteld?! Welke Kubernetes-componenten hebben we geĂŻnstalleerd en welke niet? Er rijzen duizenden vragen, en om ze te beantwoorden heb je 15-20 jaar ervaring in deze industrie nodig.
Ik heb een recent voorbeeld over dit onderwerp dat de essentie van het probleem "Is het moeilijk om Kubernetes te ondersteunen?" kan verduidelijken. Enige tijd geleden overwogen we serieus of we Cilium als netwerk in Kubernetes moesten implementeren.
Laat me uitleggen wat Cilium is. In Kubernetes zijn er veel verschillende implementaties van het netwerksysteem, en een daarvan is behoorlijk indrukwekkend: dat is Cilium. Wat is de essentie ervan? In de kernel is enige tijd geleden de mogelijkheid ontstaan om hooks voor de kernel te schrijven die op de een of andere manier in het netwerksysteem en in verschillende andere subsystemen ingrijpen, waardoor grote delen van de kernel kunnen worden omzeild.
Historisch gezien zijn er in de Linux-kernel ip rout, netfilters, bridges en veel andere oude componenten die 15, 20 of zelfs 30 jaar oud zijn. Over het algemeen werken ze goed, alles is prima, maar tegenwoordig zijn we omringd door containers, en dat lijkt op een toren van 15 stenen bovenop elkaar, terwijl jij op Ă©Ă©n been staat â een vreemde gewaarwording. Dit systeem heeft zich historisch ontwikkeld met veel nuances, als een appendix in het lichaam. In bepaalde situaties zijn er problemen met de prestaties, bijvoorbeeld.
Er is een geweldige BPF en de mogelijkheid om hooks voor de kernel te schrijven â de jongens hebben hun eigen hooks voor de kernel geschreven. Het pakket komt de Linux-kernel binnen, ze verwijderen het direct bij de ingang, verwerken het zoals nodig zonder bridges, zonder TCP, zonder IP-stack â kortom, omzeilen alles wat in de Linux-kernel is geschreven, en spugen het onmiddellijk in de container.
Wat is het resultaat? Heel goede prestaties, geweldige functies â gewoon fantastisch! Maar we kijken hiernaar en zien dat op elke machine een programma staat dat verbinding maakt met de Kubernetes API en op basis van de gegevens die het uit deze API ontvangt C-code genereert en binaries compileert die in de kernel worden geladen, zodat deze hooks in de kernelruimte werken.
Wat gebeurt er als er iets misgaat? We weten het niet. Om dat te begrijpen, moeten we de hele code lezen, de hele logica begrijpen, en dat is ongelooflijk moeilijk. Maar aan de andere kant zijn er deze bridges, netfilters, ip rout â ik heb hun broncode niet gelezen, en 40 ingenieurs die in ons bedrijf werken ook niet. Misschien begrijpen maar een paar mensen bepaalde delen.
En wat maakt het uit? Het blijkt dat er een ip rout is, de Linux-kernel, en er is een nieuw hulpmiddel - wat maakt het uit, we begrijpen geen van beide. Maar we zijn bang om het nieuwe te gebruiken - waarom? Omdat als een hulpmiddel 30 jaar oud is, dat in 30 jaar alle bugs zijn gevonden, en we niet alles hoeven te weten - het werkt als een zwarte doos, en het werkt altijd. Iedereen weet hoe je de diagnostische schroevendraaier op de goede plek steekt, welk tcpdump je op welk moment moet starten. Iedereen kent de diagnostische hulpmiddelen goed en begrijpt hoe deze set componenten in de Linux-kern werkt - niet hoe het is opgebouwd, maar hoe je het gebruikt.
Maar de geweldig coole Cilium is nog geen 30 jaar oud, het is nog niet geëvolueerd. Met Kubernetes is het hetzelfde probleem, een kopie. Zowel Cilium als Kubernetes kunnen prima worden geïnstalleerd, maar als er iets misgaat in productie, ben je dan in staat om in een kritieke situatie snel te begrijpen wat er misgaat?
Wanneer we vragen of het moeilijk is om Kubernetes te ondersteunen - nee, het is heel eenvoudig, en ja, het is ongelooflijk ingewikkeld. Kubernetes werkt prima op zichzelf, maar met een miljard nuances.
Over de aanpak 'Ik heb geluk'
- Zijn er bedrijven waar deze nuances bijna gegarandeerd zullen verschijnen? Stel dat Yandex opeens alle diensten naar Kubernetes migreert, daar zal een enorme belasting zijn.
Dmitry: Nee, dit gesprek gaat niet over belasting, maar over de eenvoudigste dingen. Bijvoorbeeld, we hebben Kubernetes, we hebben daar een applicatie gedeployd. Hoe weten we of het werkt? Er is geen kant-en-klaar hulpmiddel om te begrijpen dat de applicatie niet crasht. Er is geen kant-en-klare systeem dat alerts verstuurt - nee, we moeten die alerts en elke grafiek instellen. En ondertussen updaten we Kubernetes.
Er is Ubuntu 16.04. Je zou kunnen zeggen dat het een oude versie is, maar we draaien er nog steeds op omdat het LTS is. Het heeft systemd, waarvan het nuancepunt is dat het de C-groepen niet opruimt. Kubernetes start pods, creëert C-groepen, verwijdert vervolgens de pods, en zo ontstaat het, ik weet de details niet meer, sorry, dat er slices van systemd blijven bestaan. Dit leidt ertoe dat elke machine na verloop van tijd flink gaat trager worden. Dit is zelfs geen kwestie van highload. Als er constante pods draaien, bijvoorbeeld als er een Cron Job is die continu pods genereert, dan zal de machine met Ubuntu 16.04 na een week beginnen te vertragen. De load average zal constant hoog zijn vanwege de hoop C-groepen die zijn aangemaakt. Dit is een probleem waar iedereen mee te maken krijgt die gewoon Ubuntu 16 installeert en daarbovenop Kubernetes draait.
Stel dat iemand systemd of iets anders heeft geĂŒpdatet, maar in de Linux-kernel tot 4.16 is het nog grappiger - bij het verwijderen van C-groepen blijven ze in de kernel hangen en worden ze eigenlijk niet verwijderd. Daarom is het na een maand werken op deze machine onmogelijk om statistieken over het geheugen voor de pods te bekijken. We halen een bestandje eruit, draaien het in een programma, en Ă©Ă©n bestandje draait 15 seconden omdat de kernel heel lang nodig heeft om intern te rekenen met miljoenen C-groepen die zogenaamd verwijderd zijn, maar dat zijn ze niet - ze blijven hangen.
Er zijn nog steeds heel veel van zulke kleine dingen hier en daar. Dit is geen probleem waarmee grote bedrijven soms geconfronteerd worden bij zeer hoge belasting - nee, dit zijn dagelijkse dingen. Mensen kunnen maandenlang zo leven - ze hebben Kubernetes geĂŻnstalleerd, de applicatie gedeployed - het lijkt te werken. Voor velen is dat prima. Het feit dat deze applicatie op een gegeven moment om de een of andere reden misschien zal crashen, zullen ze nooit weten, de alert zal niet komen, maar voor hen is dit normaal. Vroeger leefden ze op virtuele machines zonder monitoring, nu zijn ze naar Kubernetes verhuisd, ook zonder monitoring - wat maakt het uit?
Het probleem is dat wanneer we over ijs lopen, we nooit weten hoe dik het is, tenzij we het van tevoren gemeten hebben. Veel mensen lopen gewoon en maken zich geen zorgen, omdat ze het eerder ook hebben gedaan.
Vanuit mijn perspectief is de nuance en complexiteit van het beheren van elk systeem dat we moeten garanderen dat de dikte van het ijs voldoende is om onze taken uit te voeren. Daar gaat het over.
In IT, it seems to me that there are too many approaches of 'I'll get lucky.' Many people install software, use programming libraries hoping that they'll get lucky. Overall, luck is on many people's side. Perhaps that's why it works.
-- From my pessimistic assessment, it looks like this: when the risks are high and the application needs to work, support from 'Flant' is necessary, possibly from Red Hat, or a dedicated internal team for Kubernetes is required, which is ready to handle it.
Dmitry: Objectively, that's true. For a small team to dive into the Kubernetes saga on their own is a considerable amount of risk.
Do we need containers?
-- Can you tell me how widespread Kubernetes is in Russia?
Dmitry: I don't have that data, and I'm not sure that anyone really does. We say 'Kubernetes, Kubernetes', but there is another perspective on this issue. I don't know how prevalent containers are, but I do know from reports online that 70% of containers are orchestrated by Kubernetes. That was a reliable source from a quite large sample worldwide.
Next questionâdo we need containers? My personal feeling and the overall stance of 'Flant' is that Kubernetes is the de facto standard.
Nothing but Kubernetes will remain.
This is an absolute game-changer in the field of infrastructure management. Just absoluteâno more Ansible, Chef, virtual machines, Terraform. I'm not even mentioning the old collective farming methods. Kubernetes is an absolute changer, and now it will be only like this.
It's clear that some need a couple of years, while others might take a few decades to realize this. I have no doubt there will be nothing but Kubernetes and this new perspective: we no longer attack the operating system but use infrastructure as code, just not with code, but with ymlâa declaratively described infrastructure. I have a feeling that this will always be the case.
-- So, those companies that have not yet transitioned to Kubernetes will either inevitably switch to it or be left in obscurity. Did I understand you correctly?
Dmitry: Dat is ook niet helemaal correct. Bijvoorbeeld, als we de taak hebben om een dns-server te starten, kan dit op FreeBSD 4.10 en kan het 20 jaar lang prima functioneren. Gewoon functioneren, en dat is het. Misschien is er na 20 jaar Ă©Ă©n keer iets nodig om te updaten. Als we het hebben over software in de zin dat we het opstarten en het jarenlang zonder updates of wijzigingen werkt, dan is daar natuurlijk geen Kubernetes bij nodig. Het is daar niet nodig.
Wat betreft CI/CD â overal waar Continuous Delivery nodig is, waar versies moeten worden bijgewerkt, waar actieve wijzigingen vereist zijn, overal waar fouttolerantie moet worden opgebouwd - alleen Kubernetes.
Over microservices
â Hier krijg ik een klein dissonantie. Om met Kubernetes te werken, is externe of interne ondersteuning nodig - dat is het eerste punt. Ten tweede - wanneer we net beginnen met ontwikkelen, zijn we een kleine startup, we hebben nog niets, de ontwikkeling onder Kubernetes of ĂŒberhaupt onder een microservices-architectuur kan complex zijn, en is niet altijd economisch gerechtvaardigd. Ik ben benieuwd naar jouw mening - moeten startups vanaf nul direct voor Kubernetes schrijven of kunnen ze eerst een monolith schrijven, en daarna pas naar Kubernetes overstappen?
Dmitry: Geweldige vraag. Ik heb een lezing over microservices. Ik ben vaak tegengekomen dat mensen met een microscoop spijkers proberen in te slaan. De aanpak is op zich juist, wij ontwerpen ook onze interne software op deze manier. Maar als je dat doet, moet je goed begrijpen wat je doet. Het meest aan microservices dat ik haat, is het woord âmicroâ. Het heeft historisch zo gewerkt dat dit woord is ontstaan, en om de een of andere reden denken mensen dat micro betekent dat het heel klein is, minder dan een millimeter, zoals een micrometer. Dat is niet het geval.
Bijvoorbeeld, er is een monolith die door 300 mensen wordt geschreven, en iedereen die aan de ontwikkeling heeft deelgenomen, begrijpt dat er problemen zijn, en deze moet in micro-stukjes worden opgesplitst - ongeveer 10, waarvan elk in de minimale variant door 30 mensen wordt geschreven. Dat is belangrijk, nodig en geweldig. Maar wanneer een startup met ons komt waar 3 erg geweldige en getalenteerde jongens 60 microservices op de knieën hebben geschreven, zoek ik elke keer naar kalmeringsmiddelen.
Ik denk dat hier al duizenden keren over is gesproken - we hebben een gedistribueerde monolith in de een of andere hoedanigheid gekregen. Dit is economisch niet verantwoord, erg moeilijk in het algemeen. Ik heb dit zo vaak gezien dat het me gewoon pijn doet, daarom blijf ik erover praten.
Over de initiële vraag, dat er een conflict is tussen, aan de ene kant, het gebruik van Kubernetes dat angstaanjagend is omdat het onduidelijk is wat er kapot kan gaan of niet kan werken, en aan de andere kant, het is duidelijk dat alles daarheen gaat en er niets anders dan Kubernetes zal zijn. Het antwoord is - de hoeveelheid voordeel die binnenkomt, de hoeveelheid taken die je kunt oplossen. Dit is de ene kant van de schaal. Aan de andere kant zijn er de risico's die verband houden met stilstand of een vermindering van de responstijd, het niveau van beschikbaarheid - met een vermindering van prestatie-indicatoren.
Het is als volgt - of we moeten snel vooruitkijken, en Kubernetes stelt ons in staat veel dingen veel sneller en beter uit te voeren, of we gebruiken betrouwbare, door de tijd geteste oplossingen, maar bewegen veel langzamer. Dit is een keuze die elk bedrijf moet maken. Je kunt dit beschouwen als een pad door de jungle - als je de eerste keer gaat, kun je een slang, een tijger of een dolle das tegenkomen, en als je het 10 keer hebt gedaan - heb je het pad geëffend, takken verwijderd en is het gemakkelijker om te lopen. Met elke keer wordt het pad breder. Daarna is het een geasfalteerde weg, en later een mooie boulevard.
Kubernetes staat niet stil. Weer de vraag: Kubernetes, aan de ene kant, zijn dat 4-5 binaire bestanden, aan de andere kant is dat het hele ecosysteem. Dat is het besturingssysteem dat op onze machines draait. Wat is dit? Ubuntu of Curios? Het is de Linux-kern, een heleboel extra componenten. Al deze dingen hebben hier een giftige slang van de weg gegooid, daar is een hek geplaatst. Kubernetes ontwikkelt zich zeer snel en dynamisch, en de hoeveelheid risico's, de hoeveelheid onbekends vermindert met elke maand en, dienovereenkomstig, worden deze schalen opnieuw in balans gebracht.
Als reactie op de vraag wat een startup moet doen, zou ik zeggen: kom naar "Flant", betaal 150.000 roebel en ontvang een kant-en-klare DevOps easy service. Als je een kleine startup bent met een paar ontwikkelaars, is dit een werkbare oplossing. In plaats van je eigen DevOps in te huren, die leren moet om je problemen op te lossen en gedurende die tijd een salaris betaald moet krijgen, krijg je een kant-en-klare oplossing voor al je vragen. Ja, er zijn enkele nadelen. Als outsourcer kunnen we niet zo betrokken zijn en snel reageren op wijzigingen. Maar we hebben een berg expertise en kant-en-klare praktijken. We garanderen dat we in elke situatie snel reageren en elke Kubernetes weer operationeel krijgen.
Ik raadt ten zeerste aan om uit te besteden, zowel voor startups als bestaande bedrijven, tot het punt waarop je een team van 10 mensen kunt aanwijzen voor de operationele taken, want anders is het niet logisch. Het is absoluut zinnig om uit te besteden.
Over Amazon en Google
â Kun je de hostingoplossingen van Amazon of Google als outsourcing beschouwen?
Dmitry: Ja, absoluut, dat lost enkele problemen op. Maar er zijn weer nuances. Je moet nog steeds begrijpen hoe je het moet gebruiken. Bijvoorbeeld, er zijn duizend kleine dingen bij Amazon AWS: Load Balancer moet je opwarmen of van tevoren een aanvraag indienen, waarin je zegt: "jongens, we krijgen verkeer, warm de Load Balancer voor ons op!" Deze nuances moeten bekend zijn.
Wanneer je contact opneemt met mensen die hierin gespecialiseerd zijn, krijg je bijna alle standaardzaken opgelost. We hebben nu 40 ingenieurs, en tegen het einde van het jaar zullen dat er waarschijnlijk 60 zijn - we hebben zeker met al deze zaken te maken gehad. Zelfs als we op een project weer tegen hetzelfde probleem aanlopen, vragen we snel aan elkaar en weten we hoe we het moeten oplossen.
Waarschijnlijk is het antwoord zo: natuurlijk vergemakkelijkt de hosted-geschiedenis een deel ervan. De vraag is of je deze hosters wilt vertrouwen en of ze je problemen zullen oplossen. Amazon en Google hebben zich goed bewezen. Voor al onze gevallen - zeker. We hebben verder geen positieve ervaringen. Alle andere clouds waarmee we hebben geprobeerd te werken, creëren veel problemen - zowel Ager als alles wat er in Rusland is, en allerlei OpenStack-implementaties: Headster, Overage - noem maar op. Allemaal creëren ze problemen die je liever niet wilt oplossen.
Daarom is het antwoord ja, maar in feite zijn er niet veel volwassen hosted-oplossingen.
Wie kan Kubernetes gebruiken?
â En toch, wie heeft Kubernetes nodig? Wie moet nu al overstappen naar Kubernetes? Wie is de typische klant van 'Flant' die specifiek voor Kubernetes komt?
Dmitry: Een interessante vraag, want op dit moment komen er veel mensen naar ons toe met de hype rond Kubernetes: "Heren, wij weten dat jullie Kubernetes doen, maak dat voor ons!". We antwoorden: "Dames en heren, wij maken geen Kubernetes, wij maken productie en alles wat daarmee verband houdt". Want het is tegenwoordig gewoon onmogelijk om productie te maken zonder CI/CD en al die zaken. Iedereen is afgeweken van de gedachte dat wij ontwikkeling een apart iets hebben, en vervolgens exploitatie ook.
Onze klanten verwachten verschillende dingen, maar iedereen hoopt op een soort wonder dat ze bepaalde problemen hebben, en nu, hop!, Kubernetes zal deze oplossen. Mensen geloven in wonderen. Ze begrijpen met hun verstand dat er geen wonder zal zijn, maar hopen met hun ziel â misschien zal Kubernetes ons nu alles oplossen, er wordt zoveel over gesproken! Misschien is het nu een snuifje! â en het zilveren kogel, snuifje! â en we hebben 100% uptime, alle ontwikkelaars kunnen 50 keer iets op productie releasen zonder dat het crasht. Kortom, een wonder!
Wanneer zulke mensen bij ons komen, zeggen we: "Sorry, maar er zijn geen wonderen". Om gezond te zijn, moet je goed eten en sporten. Om betrouwbare productie te hebben, moet je het betrouwbaar opzetten. Om een comfortabele CI/CD te hebben, moet je het zo maken. Dat is veel werk dat gedaan moet worden.
Als we de vraag beantwoorden wie Kubernetes nodig heeft â heeft niemand Kubernetes nodig.
Sommige mensen hebben de verkeerde indruk dat ze Kubernetes nodig hebben. Mensen hebben de diepgaande behoefte om niet na te denken, zich bezig te houden of zich te interesseren voor alle infrastructuurproblemen en de problematiek van het draaien van hun applicaties. Ze willen gewoon dat de applicaties werken en eenvoudig te implementeren zijn. Voor hen is Kubernetes de hoop dat ze niet meer hoeven te horen dat "we daar aan het rommelen waren", of "we kunnen niet naar productie", of iets dergelijks.
Meestal komt de technische directeur naar ons toe. Van hem worden twee dingen gevraagd: aan de ene kant, geef ons functies, aan de andere kant â stabiliteit. Wij stellen voor om dit voor hen op te pakken en het te realiseren. De zilveren kogel, eerder een verzilverde, is dat je niet meer hoeft na te denken over deze problemen en tijd te besteden. Je krijgt speciale mensen die deze kwestie oplossen.
De formulering dat wij of iemand anders Kubernetes nodig hebben, is verkeerd.
Kubernetes is heel belangrijk voor beheerders, omdat het een zeer interessante speeltje is waar je mee kunt spelen en prutsen. Laten we eerlijk zijn - iedereen houdt van speeltjes. We zijn allemaal ergens kinderen, en wanneer we iets nieuws zien - willen we ermee spelen. Voor sommigen is dit eraf gehaald, bijvoorbeeld bij het beheer, omdat ze al genoeg hebben gespeeld en het gewoon vervelend is geworden. Maar dat is niet bij iedereen volledig het geval. Bijvoorbeeld, als ik al een lange tijd klaar ben met speeltjes in systeembeheer en DevOps, dan hou ik nog steeds van speeltjes, en koop ik toch nieuwe dingen. Iedereen wil op een bepaalde manier toch wat speeltjes.
Je moet niet spelen met productie. Wat ik categorisch niet zou aanbevelen om te doen en wat ik momenteel vaak zie: "Oh, een nieuw speeltje!" - we renden om het te kopen, kochten het en: "Laten we het nu meenemen naar school, laten we het aan al onze vrienden laten zien." Doe dat niet. Sorry, mijn kinderen groeien op, ik zie constant iets in kinderen, bemerk het in mezelf, en veralgemeen het vaak naar anderen.
Het definitieve antwoord: je hebt Kubernetes niet nodig. Je moet jouw problemen oplossen.
Je kunt bereiken dat:
- de productie niet valt;
- zelfs als het probeert te vallen, weten we dat van tevoren, en kunnen we iets onderbreken;
- we kunnen het veranderen met de snelheid die we nodig hebben voor het bedrijf, en dit op een gemakkelijke manier doen, het veroorzaakt ons geen problemen.
Er zijn twee echte behoeften: betrouwbaarheid en dynamiek/ flexibiliteit van de uitrol. Iedereen die momenteel aan IT-projecten werkt, ongeacht in welke sector - soft voor het vergemakkelijken van de wereld, en die dit begrijpen, moeten deze behoeften oplossen. Kubernetes, met de juiste aanpak, goed begrip en voldoende ervaring, maakt deze oplossingen mogelijk.
Over serverless
- Als we iets verder in de toekomst kijken, dan ontstaan er nieuwe oplossingen, zoals serverless, die proberen het probleem van hoofdpijn door infrastructuur, snelheid van uitrol en snel verandering van de applicatie op te lossen. Voel je potentieel in deze richting en, laten we zeggen, een bedreiging voor Kubernetes en soortgelijke oplossingen?
Dmitry: Hier moet weer een opmerking worden gemaakt dat ik geen waarzegger ben die in de toekomst kijkt en zegt - zo zal het gaan! Hoewel ik net hetzelfde heb gedaan. Ik kijk onder mijn voeten en zie daar een hoop problemen, bijvoorbeeld hoe transistors in een computer werken. Te grappig, nietwaar? We stuiten op bepaalde bugs in de CPU.
Om serverless betrouwbaar, goedkoop, efficiënt en gebruiksvriendelijk te maken, moeten alle ecosysteemproblemen worden opgelost. Hier ben ik het eens met Elon Musk dat er een tweede planeet nodig is om de veerkracht van de mensheid te waarborgen. Hoewel ik niet weet wat hij zegt, begrijp ik dat ik niet bereid ben zelf naar Mars te vliegen en dat dit niet morgen zal gebeuren.
Met serverless is het duidelijk dat dit ideologisch de juiste aanpak is, net zoals veerkracht voor de mensheid - twee planeten hebben is beter dan één. Maar hoe doe je dat nu? Eén expeditie sturen - geen probleem als je je inspanningen daarop concentreert. Meerdere expedities sturen en daar enkele duizenden mensen vestigen lijkt me ook realistisch. Maar om echte veerkracht te creëren zodat een deel van de mensheid daar zou wonen, lijkt me momenteel onmogelijk en niet doordacht.
Het is met serverless precies hetzelfde: het is een geweldige zaak, maar het staat ver af van de problemen van 2019. Dichter bij 2030 - laten we hopen dat we het halen. Ik twijfel er niet aan dat we het halen, we zullen het zeker halen (herhaal dit voor het slapengaan), maar nu moeten we andere problemen oplossen. Het is als geloven in een mythische eenhoorn. Ja, een paar procent van de gevallen worden opgelost, en dat wordt uitstekend gedaan, maar subjectief is serverless - dat is een eenhoorn... Voor mij is dit onderwerp te ver weg en te onduidelijk. Ik ben niet bereid om erover te praten. In 2019 kun je met serverless geen enkele applicatie schrijven.
Hoe Kubernetes zich zal ontwikkelen.
â Terwijl we op weg zijn naar deze potentieel prachtige verre toekomst, wat denk jij dat de ontwikkeling van Kubernetes en het ecosysteem eromheen zal zijn?
Dmitry: Ik heb hier veel over nagedacht en ik heb een duidelijk antwoord. Ten eerste â stateful â het is eigenlijk gemakkelijker om stateless te maken. Kubernetes heeft hier aanvankelijk meer in geĂŻnvesteerd, daar is het allemaal mee begonnen. Stateless werkt vrijwel perfect in Kubernetes, er is gewoon niets op aan te merken. Er zijn nog tal van problemen en nuances met stateful. Bij ons werkt alles daar al prima, maar dat zijn wij. Om dit voor iedereen goed te laten werken, hebben we nog minstens een paar jaar nodig. Dit is geen berekende indicator, maar mijn gevoel uit mijn hoofd.
Kortom, stateful moet zich enorm ontwikkelen â en zal dat ook doen â omdat al onze applicaties status opslaan, er bestaan geen stateless-applicaties. Dat is een illusie, er is altijd een soort database en nog iets anders nodig. Stateful is het rechtzetten van alles wat mogelijk is, het verhelpen van alle bugs, het verbeteren van alle problemen waar we momenteel tegenaan lopen â laten we het adoptie noemen.
Het niveau van het onbekende, het niveau van onopgeloste problemen, het niveau van de waarschijnlijkheid om met iets geconfronteerd te worden, zal sterk afnemen. Dit is een belangrijk verhaal. En de operators â alles wat te maken heeft met het codificeren van administratieloÂgiek, beheerslogica, om een eenvoudige service te krijgen: MySQL eenvoudige service, RabbitMQ eenvoudige service, Memcache eenvoudige service, â eigenlijk al deze componenten die we nodig hebben om gegarandeerd werkend 'out of the box' te krijgen. Dit lost net die problemen op dat we een database willen, maar niet willen beheren, of we willen Kubernetes, maar willen het niet beheren.
Dit verhaal over de ontwikkeling van operators in welke vorm dan ook zal de komende paar jaar belangrijk zijn.
Ik denk dat de eenvoud van het gebruik sterk zal toenemen â de doos wordt steeds meer en meer een 'black box', steeds betrouwbaarder, met steeds eenvoudigere bedieningsknoppen.
Ik hoorde ooit een oud interview met Isaac Asimov uit de jaren '80 op YouTube in de show Saturday Night Live â een show zoals die van Urgant, maar dan interessant. Hij werd daar gevraagd over de toekomst van computers. Hij zei dat de toekomst eenvoudiger zal zijn, zoals dat met de radio was. De radio was aanvankelijk een ingewikkeld apparaat. Om een signaal te vangen, moest je 15 minuten draaien aan de knoppen, draaien aan de schakelaars en echt begrijpen hoe alles werkte, de fysica van radiogolven begrijpen. Uiteindelijk bleef er Ă©Ă©n knop over op de radio.
Wat voor radio is er nu in 2019? In de auto vindt de radio alle golven en de namen van de stations. De fysica van het proces is in 100 jaar niet veranderd, maar de gebruiksvriendelijkheid wel. Nu, en ook al in 1980, tijdens een interview met Asimov, gebruikten iedereen radio en dachten ze niet na over hoe het werkte. Het werkte altijd - dat is een feit.
Asimov zei toen dat het met computers hetzelfde zou zijn - de gebruiksvriendelijkheid zal toenemen. Als men in 1980 een speciale opleiding nodig had om op de knoppen van een computer te drukken, zal dat in de toekomst niet meer zo zijn.
Ik heb het gevoel dat ook de eenvoud van gebruik bij Kubernetes en infrastructuur sterk zal toenemen. Dat ligt, naar mijn mening, voor de hand.
Wat te doen met ingenieurs?
- Maar wat gebeurt er dan met ingenieurs, systeembeheerders die Kubernetes ondersteunen?
Dmitry: Wat gebeurde er met boekhouders na de komst van 1C? Ongeveer hetzelfde. Voorheen werd er op papier gerekend - nu in een programma. De arbeidsproductiviteit is enorm gestegen, maar het werk is niet verdwenen. Waar voor het vervangen van een gloeilamp 10 ingenieurs nodig waren, is nu Ă©Ă©n genoeg.
Het aantal software en taken groeit, naar mijn idee, nu sneller dan het aantal nieuwe DevOps'ers en de efficiëntie toenemen. Er is momenteel een specifiek tekort op de markt en dat zal langdurig aanhouden. Later zal alles weer in een bepaalde norm komen, waarbij de efficiëntie van het werk zal toenemen, er zal steeds meer serverless zijn, en er komt een neurale netwerk aan Kubernetes die alle middelen automatisch zal toewijzen zoals nodig, en alles zelf doet zoals het hoort - de mens hoeft alleen weg te blijven en niet in de weg te staan.
Maar er moeten nog steeds beslissingen worden genomen door iemand. Het is duidelijk dat het niveau van kwalificatie en specialisatie van deze persoon hoger is. In de boekhoudafdeling heb je momenteel geen 10 medewerkers nodig die de boekhouding bijhouden, zodat hun handen niet moe worden. Dat is gewoon niet nodig. Veel documenten worden automatisch gescand en door het elektronisch documentbeheersysteem herkend. EĂ©n slimme hoofdboekhouder met veel betere vaardigheden en een goed begrip is genoeg.
Over het algemeen is deze ontwikkeling in alle sectoren te zien. Ook bij auto's: vroeger hoorde bij een auto een monteur en drie chauffeurs. Tegenwoordig is autorijden een heel eenvoudig proces waar we allemaal elke dag aan deelnemen. Niemand denkt na over het feit dat een auto iets ingewikkelds is.
DevOps of systeem engineering zal niet verdwijnen - de hoogwaardigheid en effectiviteit van het werk zullen toenemen.
- Ik heb ook een interessante gedachte gehoord dat in feite ook het werk zal toenemen.
Dmitry: Zeker weten, honderd procent! Omdat de hoeveelheid software die we schrijven constant toeneemt. Het aantal vragen dat we met software oplossen, neemt constant toe. De hoeveelheid werk groeit. De DevOps-markt is momenteel extreem oververhit. Dat is te zien aan de salarisverwachtingen. Eigenlijk, zonder in details te treden, zouden er junioren moeten zijn die X willen, mid-levels die 1,5X willen, en seniors die 2X willen. Maar nu, als je naar de salarismarkt voor DevOps in Moskou kijkt, wil een junior van X tot 3X en een senior van X tot 3X.
Niemand weet hoeveel het kost. Het salarisniveau wordt gemeten aan de hand van je zelfvertrouwen - het is complete waanzin, eerlijk gezegd, een extreem oververhitte markt.
Natuurlijk zal deze situatie heel snel veranderen - er moet een zekere verzadiging komen. Met softwareontwikkeling gaat het niet zo - ondanks dat ontwikkelaars overal nodig zijn en goede ontwikkelaars gewenst zijn, begrijpt de markt wie wat waard is - de sector heeft zich genormaliseerd. Met DevOps is het nu anders.
- Op basis van wat ik heb gehoord, concludeer ik dat de huidige systeembeheerder zich niet al te veel zorgen moet maken, maar het is tijd om vaardigheden te ontwikkelen en je voor te bereiden op het feit dat er morgen meer werk zal zijn, maar dat het werk meer gekwalificeerd zal zijn.
Dmitry: Honderd procent. Over het algemeen leven we in 2019 en de levensregel is: life long learning - we leren ons hele leven. Ik denk dat nu iedereen dit al weet en voelt, maar het is niet genoeg om te weten - je moet ook handelen. Elke dag moeten we veranderen. Als we dat niet doen, zullen we vroeg of laat aan de kant van ons beroep worden gezet.
Wees voorbereid op scherpe wendingen van 180 graden. Ik sluit situaties niet uit waarin er iets radicaal verandert, of iets nieuws wordt uitgevonden â dat gebeurt. Hups! â en we handelen nu anders. Het is belangrijk om hierop voorbereid te zijn en je er niet druk om te maken. Het kan zo zijn dat morgen alles wat ik doe overbodig is â dat is geen probleem, ik heb mijn hele leven geleerd en ben bereid om iets anders te leren. Het is geen probleem. Maak je geen zorgen over baangarantie, maar wees bereid om voortdurend iets nieuws te leren.
Wensen en een momentje reclame
â Heb je een wens?
Dmitry: Ja, ik heb een paar wensen.
De eerste en mercantiele â abonneer je op . Geachte lezers, ga naar YouTube en abonneer je op ons kanaal. Over een maand beginnen we een actieve uitbreiding op de videoservice; we hebben een boel educatieve content over Kubernetes, van praktisch tot diepgaand theoretisch, en hoe Kubernetes toe te passen op het niveau van principes en patronen.
De tweede mercantiele wens â ga naar en geef ons sterren, want daarvan leven we. Als je ons geen sterren geeft, hebben we niets om van te leven. Het is als manna in een computerspel. We doen iets, doen ons best, sommigen zeggen dat het vreselijke fietsen zijn, anderen vinden dat alles gewoon verkeerd is, maar we gaan door en handelen volledig eerlijk. We zien een probleem, lossen het op en delen onze ervaringen. Dus geef ons een ster, het kost jou niets, maar het voegt voor ons iets toe, want daarvan leven we.
De derde, belangrijke, en al niet mercantiele wens â stop met geloven in sprookjes. Jullie zijn professionals. DevOps is een zeer serieus en verantwoordelijk beroep. Stop met spelen op de werkplek. Laat je door de waarheid raken, en je zult het begrijpen. Stel je voor dat je naar het ziekenhuis komt, en de dokter experimenteert op jou. Ik begrijp dat dit voor sommigen kwetsend kan zijn, maar waarschijnlijk is dit niet over jou, maar over iemand anders. Zeg tegen anderen dat ze ook moeten stoppen. Dit verstoort echt ons leven â velen beginnen DevOps, beheerders en exploitatie als mensen te beschouwen die weer iets kapotgemaakt hebben. Dat 'kapotgemaakt' gebeurt vaak omdat we zijn gaan spelen, en niet met een nuchter bewustzijn hebben gekeken naar wat hier zo en daar zo is.
Dit betekent niet dat je niet moet experimenteren. Experimenteren moet, dat doen wij ook. Om eerlijk te zijn, soms spelen we ook â dat is natuurlijk niet goed, maar niets menselijks is ons vreemd. Laten we 2019 uitroepen tot het jaar van serieuze, doordachte experimenten, en geen spelletjes op productie. Misschien zo.
â Hartelijk dank!
Dmitry: Dank je wel, Vitaly, voor je tijd en het interview. Beste lezers, hartelijk dank als jullie tot dit moment zijn gekomen. Ik hoop dat we jullie minstens een paar gedachten hebben gebracht.
In het interview sprak Dmitry over de vraag werf. Momenteel is dit een universeel Zwitsers mes dat bijna alle taken oplost. Maar dat was niet altijd zo. Tijdens  het festival zal Dmitry Stolyarov deze tool in detail bespreken. In de presentatie zal alles aan bod komen: problemen en verborgen nuances van Kubernetes, oplossingen voor deze uitdagingen en de huidige implementatie van werf in detail. Sluit je aan op 27 en 28 mei, laten we perfecte tools creëren.
Bron: habr.com
