In afwachting Vitaly Chabarov geïnterviewd Dmitri Stolyarov (), technisch directeur en mede-oprichter van het bedrijf Flant. Vitaly vroeg Dmitry wat Flant doet, over Kubernetes, ecosysteemontwikkeling, ondersteuning. We hebben besproken waarom Kubernetes nodig is en of het überhaupt nodig is. En ook over microservices, Amazon AWS, de ‘ik heb geluk’-aanpak van DevOps, de toekomst van Kubernetes zelf, waarom, wanneer en hoe het de wereld zal overnemen, de vooruitzichten van DevOps en waar ingenieurs zich op moeten voorbereiden in de toekomst. een mooie en nabije toekomst met vereenvoudiging en neurale netwerken.
luister als podcast op DevOps Deflop - een Russischtalige podcast over DevOps, en hieronder staat de tekstversie.
Hier en beneden stelt hij vragen ingenieur van Express42.
Over "Flant"
- Hallo Dima. Jij bent de technisch directeur""en ook de oprichter. Vertel ons alstublieft wat het bedrijf doet en wat u daarin doet?
Dmitry: Van buitenaf lijkt het alsof wij de jongens zijn die Kubernetes voor iedereen installeren en er iets mee doen. Maar dat is niet waar. We zijn begonnen als een bedrijf dat zich bezighoudt met Linux, maar onze hoofdactiviteit bestaat al heel lang uit het onderhouden van productie- en turnkey-projecten met hoge belasting. Meestal bouwen we de hele infrastructuur vanaf nul op en zijn daar dan voor een lange, lange tijd verantwoordelijk voor. Daarom is het belangrijkste werk dat “Flant” doet, waarvoor het geld ontvangt, dat wel verantwoordelijkheid nemen en turn-key productie implementeren.
Ik, als technisch directeur en een van de oprichters van het bedrijf, ben de hele dag en nacht bezig met het uitzoeken hoe ik de toegankelijkheid van de productie kan vergroten, de werking ervan kan vereenvoudigen, het leven van beheerders gemakkelijker en het leven van ontwikkelaars aangenamer kan maken .
Over Kubernetes
— De laatste tijd heb ik veel rapporten gezien van Flant en over Kubernetes. Hoe ben je erbij gekomen?
Dmitry: Ik heb hier al vaak over gesproken, maar ik vind het helemaal niet erg om het te herhalen. Ik denk dat het goed is om dit onderwerp te herhalen, omdat er verwarring bestaat tussen oorzaak en gevolg.
We hadden echt een hulpmiddel nodig. We werden met veel problemen geconfronteerd, worstelden, overwonnen ze met verschillende krukken en voelden de behoefte aan een hulpmiddel. We hebben veel verschillende opties doorlopen, onze eigen fietsen gebouwd en ervaring opgedaan. Geleidelijk aan kwamen we op het punt waarop we Docker begonnen te gebruiken, vrijwel zodra het verscheen - rond 2013. Toen het verscheen, hadden we al veel ervaring met containers, we hadden al een analoog van "Docker" geschreven - enkele van onze eigen krukken in Python. Met de komst van Docker werd het mogelijk om de krukken weg te gooien en een betrouwbare en door de gemeenschap ondersteunde oplossing te gebruiken.
Bij Kubernetes is het verhaal vergelijkbaar. Tegen de tijd dat het momentum begon te winnen - voor ons is dit versie 1.2 - hadden we al een aantal krukken op zowel Shell als Chef, die we op de een of andere manier probeerden te orkestreren met Docker. We waren serieus aan het kijken naar Rancher en diverse andere oplossingen, maar toen verscheen Kubernetes, waarin alles precies is geïmplementeerd zoals wij het zouden hebben gedaan of zelfs beter. Er is niets om over te klagen.
Ja, er is hier een soort onvolkomenheid, er is een soort onvolkomenheid - er zijn veel onvolkomenheden, en 1.2 is over het algemeen verschrikkelijk, maar... Kubernetes is als een gebouw in aanbouw - je kijkt naar het project en begrijpt het dat het gaaf zal zijn. Als het gebouw nu een fundering en twee verdiepingen heeft, dan begrijp je dat het beter is om er nog niet in te trekken, maar zulke problemen zijn er niet met de software - je kunt er al gebruik van maken.
We hebben geen moment gehad waarop we erover nadachten om Kubernetes wel of niet te gebruiken. We hebben er lang op gewacht voordat het verscheen, en probeerden zelf analogen te maken.
Over Kubernetes
— Ben je direct betrokken bij de ontwikkeling van Kubernetes zelf?
Dmitry: Middelmatig. In plaats daarvan nemen we deel aan de ontwikkeling van het ecosysteem. We sturen een bepaald aantal pull-aanvragen: naar Prometheus, naar verschillende operators, naar Helm - naar het ecosysteem. Helaas kan ik niet alles bijhouden wat we doen en kan ik het mis hebben, maar er is geen enkele pool van ons naar de kern.
— Ontwikkelt u tegelijkertijd veel van uw tools rond Kubernetes?
Dmitry: De strategie is deze: we gaan verzoeken ophalen voor alles wat al bestaat. Als pull-verzoeken daar niet worden geaccepteerd, forken we ze eenvoudigweg zelf en leven we totdat ze worden geaccepteerd met onze builds. Wanneer het vervolgens de stroomopwaartse versie bereikt, gaan we terug naar de stroomopwaartse versie.
Zo hebben we bijvoorbeeld een Prometheus-operator, waarmee we waarschijnlijk al 5 keer heen en weer geschakeld zijn naar de bovenstroom van onze assemblage. We hebben een soort functie nodig, we hebben een pull-verzoek gestuurd, we moeten het morgen uitrollen, maar we willen niet wachten tot het stroomopwaarts wordt vrijgegeven. Dienovereenkomstig assembleren we voor onszelf, rollen we onze assemblage uit met onze functie, die we om de een of andere reden nodig hebben, naar al onze clusters. Vervolgens geven ze het bijvoorbeeld stroomopwaarts aan ons over met de woorden: "Jongens, laten we het doen voor een algemener geval", wij, of iemand anders, maken het af, en na verloop van tijd komt het weer samen.
We proberen alles wat bestaat te ontwikkelen. Veel elementen die nog niet bestaan, nog niet zijn uitgevonden of zijn uitgevonden, maar geen tijd hebben gehad om te implementeren - we doen het. En niet omdat we het proces van de fietsenbouw als sector leuk vinden, maar simpelweg omdat we deze tool nodig hebben. Vaak wordt de vraag gesteld: waarom hebben we dit of dat gedaan? Het antwoord is simpel: ja, omdat we verder moesten gaan, een praktisch probleem moesten oplossen, en dat hebben we met deze tula opgelost.
Het pad is altijd als volgt: we zoeken heel zorgvuldig en als we geen oplossing vinden voor hoe we van een brood een trolleybus kunnen maken, dan maken we ons eigen brood en onze eigen trolleybus.
Flanta-gereedschappen
— Ik weet dat Flant nu add-on-operators, shell-operators en dapp/werf-tools heeft. Zoals ik het begrijp, is dit hetzelfde instrument in verschillende incarnaties. Ik begrijp ook dat er binnen Flaunt veel meer verschillende tools zijn. Dit is waar?
Dmitry: We hebben nog veel meer op GitHub. Voor zover ik me nu herinner, hebben we een statusmap - een paneel voor Grafana dat iedereen wel eens is tegengekomen. Het wordt in bijna elk tweede artikel over Kubernetes-monitoring op Medium genoemd. Het is onmogelijk om in het kort uit te leggen wat een statusmap is - er is een apart artikel voor nodig, maar het is erg handig om de status in de loop van de tijd te monitoren, aangezien we in Kubernetes vaak de status in de loop van de tijd moeten tonen. We hebben ook LogHouse - dit is gebaseerd op ClickHouse en zwarte magie voor het verzamelen van logs in Kubernetes.
Veel nutsvoorzieningen! En dat zullen er nog meer worden, want dit jaar komen er een aantal interne oplossingen uit. Van de zeer grote, gebaseerd op de add-on-operator, zijn er een aantal add-ons voor Kubernetes, ala hoe je sert manager correct installeert - een tool voor het beheren van certificaten, hoe je Prometheus correct installeert met een heleboel accessoires - dit zijn ongeveer twintig verschillende binaire bestanden die gegevens exporteren en iets verzamelen, hiervoor heeft Prometheus de meest verbazingwekkende graphics en waarschuwingen. Dit zijn allemaal slechts een aantal add-ons voor Kubernetes, die in een cluster zijn geïnstalleerd, en het verandert van eenvoudig in cool, geavanceerd, automatisch, waarin veel problemen al zijn opgelost. Ja, we doen veel.
Ontwikkeling van ecosystemen
“Het lijkt mij dat dit een zeer grote bijdrage is aan de ontwikkeling van dit instrument en de gebruiksmethoden ervan.” Kun je grofweg inschatten wie nog meer dezelfde bijdrage zou leveren aan de ontwikkeling van het ecosysteem?
Dmitry: In Rusland komt van de bedrijven die op onze markt actief zijn niemand zelfs maar in de buurt. Dit is natuurlijk een luide uitspraak, want er zijn grote spelers als Mail en Yandex - die doen ook iets met Kubernetes, maar zelfs zij komen niet in de buurt van de bijdrage van bedrijven in de hele wereld die veel meer doen dan wij. Het is moeilijk om Flant, dat 80 mensen in dienst heeft, te vergelijken met Red Hat, dat alleen al 300 ingenieurs per Kubernetes heeft, als ik me niet vergis. Het is moeilijk om te vergelijken. We hebben zes mensen op de RnD-afdeling, waaronder ikzelf, die al ons gereedschap slijpen. 6 mensen versus 6 Red Hat-ingenieurs - het is op de een of andere manier moeilijk te vergelijken.
- Maar als zelfs deze zes mensen iets heel nuttigs en vervreemdends kunnen doen, als ze met een praktisch probleem worden geconfronteerd en de oplossing aan de gemeenschap geven - een interessant geval. Ik begrijp dat bij grote technologiebedrijven, waar ze hun eigen Kubernetes-ontwikkelings- en ondersteuningsteam hebben, in principe dezelfde tools kunnen worden ontwikkeld. Dit is voor hen een voorbeeld van wat er kan worden ontwikkeld en aan de gemeenschap kan worden gegeven, waardoor een impuls wordt gegeven aan de hele gemeenschap die Kubernetes gebruikt.
Dmitry: Dit is waarschijnlijk een kenmerk van de integrator, zijn eigenaardigheid. We hebben veel projecten en we zien veel verschillende situaties. Voor ons is de belangrijkste manier om toegevoegde waarde te creëren het analyseren van deze gevallen, het vinden van overeenkomsten en het zo goedkoop mogelijk maken ervan voor ons. Wij zijn hier actief mee bezig. Het is moeilijk voor mij om over Rusland en de wereld te praten, maar we hebben ongeveer veertig DevOps-ingenieurs in het bedrijf die aan Kubernetes werken. Ik denk niet dat er in Rusland veel bedrijven zijn met een vergelijkbaar aantal specialisten die Kubernetes begrijpen, of helemaal niet.
Ik begrijp alles van de functie DevOps engineer, iedereen begrijpt alles en is gewend om DevOps engineers DevOps engineers te noemen, hier gaan we niet over in discussie. Al deze 40 geweldige DevOps-ingenieurs worden elke dag geconfronteerd met problemen en lossen deze op. We analyseren deze ervaring en proberen deze te generaliseren. We begrijpen dat als het in ons blijft, de tool over een jaar of twee nutteloos zal zijn, omdat ergens in de gemeenschap een kant-en-klare Tula zal verschijnen. Het heeft geen zin om deze ervaring intern op te bouwen; het kost simpelweg energie en tijd in dev/null. En wij hebben er helemaal geen medelijden mee. We publiceren alles met veel plezier en begrijpen dat het gepubliceerd, ontwikkeld, gepromoot en gepromoot moet worden, zodat mensen het gebruiken en hun ervaring toevoegen - dan groeit en leeft alles. Dan gaat het instrument na twee jaar niet de prullenbak in. Het is niet jammer om door te gaan met het inbrengen van kracht, omdat het duidelijk is dat iemand jouw tool gebruikt, en na twee jaar gebruikt iedereen het.
Dit maakt deel uit van onze grote strategie met dapp/werf. Ik weet niet meer wanneer we ermee begonnen, het lijkt wel drie jaar geleden. Aanvankelijk zat het meestal op de schaal. Het was een super proof of concept, we hebben een aantal van onze specifieke problemen opgelost - het werkte! Maar er zijn problemen met de shell, het is onmogelijk om deze verder uit te breiden, programmeren op de shell is een andere taak. We hadden de gewoonte om in Ruby te schrijven, daarom hebben we iets opnieuw gemaakt in Ruby, ontwikkeld, ontwikkeld, ontwikkeld en kwamen we tegen het feit aan dat de gemeenschap, de menigte die niet zegt: 'we willen het of we willen het niet', ’ haalt zijn neus op naar Ruby, hoe grappig is dat? We realiseerden ons dat we al deze dingen in Go moesten schrijven, alleen maar om aan het eerste punt van de checklist te voldoen: DevOps-tool moet een statisch binair bestand zijn. Go zijn of niet is niet zo belangrijk, maar een statisch binair bestand geschreven in Go is beter.
We hebben onze energie besteed, de dapp in Go herschreven en hem werf genoemd. De Dapp wordt niet langer ondersteund, niet ontwikkeld en draait in een of andere nieuwste versie, maar er is een absoluut upgradepad naar de top, en je kunt het volgen.
Waarom is de dapp gemaakt?
— Kun je ons kort vertellen waarom de dapp is gemaakt en welke problemen deze oplost?
Dmitry: De eerste reden ligt in de montage. Aanvankelijk hadden we ernstige problemen met de build omdat Docker geen mogelijkheden voor meerdere fasen had, dus hebben we zelf meerdere fasen gemaakt. Daarna hadden we nog een aantal problemen met het opschonen van de afbeelding. Iedereen die CI/CD doet, wordt vroeg of laat geconfronteerd met het probleem dat er een heleboel verzamelde afbeeldingen zijn, dat je op de een of andere manier moet opruimen wat niet nodig is en moet laten wat nodig is.
De tweede reden is implementatie. Ja, er is Helm, maar het lost slechts enkele van de problemen op. Grappig genoeg staat er geschreven dat “Helm de pakketbeheerder voor Kubernetes is.” Precies wat “de”. Er zijn ook de woorden “Pakketbeheerder” - wat is de gebruikelijke verwachting van een Pakketbeheerder? Wij zeggen: “Pakketbeheer - installeer het pakket!” en we verwachten dat hij ons zal vertellen: “Het pakket is afgeleverd.”
Het is interessant dat we zeggen: "Helm, installeer het pakket", en als hij antwoordt dat hij het heeft geïnstalleerd, blijkt dat hij net met de installatie is begonnen - hij gaf Kubernetes aan: "Start dit ding!", en of het is gestart of niet , of het nu werkt of niet, Helm lost dit probleem helemaal niet op.
Het blijkt dat Helm slechts een tekstpreprocessor is die gegevens in Kubernetes laadt.
Maar als onderdeel van elke implementatie willen we weten of de applicatie is vrijgegeven voor productie of niet? Uitgerold naar prod betekent dat de applicatie daarheen is verplaatst, de nieuwe versie is geïmplementeerd en daar tenminste niet crasht en correct reageert. Helm lost dit probleem op geen enkele manier op. Om het op te lossen, moet je veel moeite doen, omdat je Kubernetes de opdracht moet geven om uit te rollen en te monitoren wat daar gebeurt - of het nu wordt ingezet of uitgerold. En er zijn ook veel taken die verband houden met inzet, schoonmaak en montage.
Plannen
Dit jaar starten we met de lokale ontwikkeling. We willen bereiken wat voorheen in Vagrant zat: we typten “vagrant up” en we implementeerden virtuele machines. We willen het punt bereiken waarop er een project in Git is, we schrijven daar “werf up”, en er verschijnt een lokale kopie van dit project, geïmplementeerd in een lokale mini-Kub, met alle mappen die handig zijn voor ontwikkeling verbonden . Afhankelijk van de ontwikkeltaal wordt dit anders gedaan, maar toch, zodat lokale ontwikkeling gemakkelijk onder aangekoppelde bestanden kan worden uitgevoerd.
De volgende stap voor ons is Investeer in gemak voor ontwikkelaars. Om een project snel lokaal uit te rollen met één tool, ontwikkel je het, push je het naar Git en wordt het ook uitgerold naar stage of tests, afhankelijk van de pipelines, en gebruik je vervolgens dezelfde tool om naar productie te gaan. Deze eenheid, unificatie en reproduceerbaarheid van de infrastructuur, van de lokale omgeving tot de verkoop, is voor ons een heel belangrijk punt. Maar dit is nog niet in de werf - we zijn het net van plan.
Maar het pad naar dapp/werf is altijd hetzelfde geweest als bij Kubernetes in het begin. We kwamen problemen tegen, losten ze op met tijdelijke oplossingen - we bedachten een aantal oplossingen voor onszelf op de schaal, op wat dan ook. Vervolgens probeerden ze deze oplossingen op de een of andere manier recht te trekken, te generaliseren en in dit geval te consolideren in binaire bestanden, die we eenvoudigweg delen.
Er is een andere manier om naar dit hele verhaal te kijken, met analogieën.
Kubernetes is een autoframe met een motor. Er zijn geen deuren, glas, radio, kerstboom - helemaal niets. Alleen het frame en de motor. En daar is Helm - dit is het stuur. Cool - er is een stuur, maar je hebt ook een stuurpen, stuurhuis, versnellingsbak en wielen nodig, en je kunt niet zonder.
In het geval van werf is dit een ander onderdeel van Kubernetes. Alleen nu in de alfaversie van werf wordt Helm bijvoorbeeld binnen werf gecompileerd, omdat we het beu zijn om het zelf te doen. Er zijn veel redenen om dit te doen, ik zal je in detail vertellen waarom we het hele roer samen met de helmstok binnen de werf hebben samengesteld .
Nu is werf een meer geïntegreerd onderdeel. We krijgen een afgewerkt stuur, een stuurpen - ik ben niet zo goed in auto's, maar dit is een groot blok dat al een vrij breed scala aan problemen oplost. We hoeven niet zelf de catalogus door te nemen, het ene onderdeel voor het andere te selecteren, na te denken over hoe we ze in elkaar kunnen schroeven. We krijgen een kant-en-klare maaidorser die een groot aantal problemen in één keer oplost. Maar van binnen is het opgebouwd uit dezelfde open source-componenten, het gebruikt nog steeds Docker voor de assemblage, Helm voor een deel van de functionaliteit, en er zijn verschillende andere bibliotheken. Dit is een geïntegreerde tool om snel en gemakkelijk een coole CI/CD uit de doos te halen.
Is Kubernetes moeilijk te onderhouden?
— Je vertelt over de ervaring dat je Kubernetes bent gaan gebruiken, dit is een frame voor jou, een motor, en dat je er veel verschillende dingen aan kunt hangen: een carrosserie, een stuur, schroefpedalen, stoelen. De vraag rijst: hoe moeilijk is Kubernetes-ondersteuning voor u? U heeft veel ervaring, hoeveel tijd en middelen besteedt u aan het ondersteunen van Kubernetes, los van al het andere?
Dmitry: Dit is een heel moeilijke vraag en om deze te beantwoorden moeten we begrijpen wat ondersteuning is en wat we van Kubernetes willen. Misschien kun je het onthullen?
— Voor zover ik weet en zie, willen veel teams Kubernetes proberen. Iedereen spant zich ervoor in, legt het op zijn knieën. Ik heb het gevoel dat mensen de complexiteit van dit systeem niet altijd begrijpen.
Dmitry: Zo is het.
— Hoe moeilijk is het om Kubernetes helemaal opnieuw te installeren en te installeren, zodat het productieklaar is?
Dmitry: Hoe moeilijk denk je dat het is om een hart te transplanteren? Ik begrijp dat dit een compromitterende vraag is. Een scalpel gebruiken en geen fouten maken is niet zo moeilijk. Als ze je vertellen waar je moet knippen en waar je moet naaien, dan is de procedure zelf niet ingewikkeld. Het is lastig om keer op keer te garanderen dat alles goed komt.
Kubernetes installeren en aan de slag krijgen is eenvoudig: meid! — geïnstalleerd, er zijn veel installatiemethoden. Maar wat gebeurt er als er zich problemen voordoen?
Er rijzen altijd vragen: waar hebben we nog geen rekening mee gehouden? Wat hebben we nog niet gedaan? Welke Linux-kernelparameters zijn onjuist opgegeven? Heer, hebben we ze überhaupt genoemd?! Welke Kubernetes-componenten hebben we geleverd en welke niet? Er rijzen duizenden vragen, en om ze te beantwoorden moet je 15-20 jaar in deze branche doorbrengen.
Ik heb een recent voorbeeld over dit onderwerp dat de betekenis van het probleem ‘Is Kubernetes moeilijk te onderhouden?’ kan onthullen. Enige tijd geleden hebben we serieus overwogen of we moesten proberen Cilium als netwerk in Kubernetes te implementeren.
Laat me uitleggen wat Cilium is. Kubernetes heeft veel verschillende implementaties van het netwerksubsysteem, en een daarvan is erg cool: Cilium. Wat is de betekenis ervan? In de kernel werd het enige tijd geleden mogelijk om hooks voor de kernel te schrijven, die op de een of andere manier het netwerksubsysteem en diverse andere subsystemen binnendringen, en je in staat stellen grote stukken in de kernel te omzeilen.
De Linux-kernel heeft historisch gezien een ip-rout, een overfilter, bruggen en veel verschillende oude componenten die 15, 20, 30 jaar oud zijn. Over het algemeen werken ze, alles is geweldig, maar nu hebben ze containers opgestapeld, en het lijkt op een toren van 15 stenen op elkaar, en je staat er op één been op - een vreemd gevoel. Dit systeem heeft zich historisch gezien met veel nuances ontwikkeld, zoals de appendix in het lichaam. In sommige situaties zijn er bijvoorbeeld prestatieproblemen.
Er is een prachtige BPF en de mogelijkheid om hooks voor de kernel te schrijven - de jongens schreven hun eigen hooks voor de kernel. Het pakket komt in de Linux-kernel, ze halen het er direct bij de invoer uit, verwerken het zelf zoals het hoort zonder bridges, zonder TCP, zonder IP-stack - kortom alles omzeilen wat in de Linux-kernel is geschreven, en dan spugen het in de container.
Wat is er gebeurd? Zeer coole prestaties, coole functies - gewoon cool! Maar we kijken hiernaar en zien dat er op elke machine een programma is dat verbinding maakt met de Kubernetes API en, op basis van de gegevens die het van deze API ontvangt, C-code genereert en binaire bestanden compileert die het in de kernel laadt, zodat deze hooks werken. in de kernelruimte.
Wat gebeurt er als er iets misgaat? We weten het niet. Om dit te begrijpen, moet je al deze code lezen, alle logica begrijpen, en het is verbazingwekkend hoe moeilijk het is. Maar aan de andere kant zijn er deze bruggen, netfilters, ip-routes - ik heb hun broncode niet gelezen, en de 40 ingenieurs die in ons bedrijf werken ook niet. Misschien begrijpen slechts enkelen sommige delen.
En wat is het verschil? Het blijkt dat er een ip-rout is, een Linux-kernel, en dat er een nieuwe tool is - wat voor verschil maakt het, we begrijpen het een of het ander niet. Maar we zijn bang om iets nieuws te gebruiken - waarom? Want als de tool 30 jaar oud is, dan zijn over 30 jaar alle bugs gevonden, zijn alle fouten eruit getrapt en hoef je niet alles te weten - het werkt als een zwarte doos en werkt altijd. Iedereen weet welke diagnoseschroevendraaier op welke plek moet worden gestoken, welke tcpdump op welk moment moet worden uitgevoerd. Iedereen kent diagnostische hulpprogramma's goed en begrijpt hoe deze set componenten in de Linux-kernel werkt - niet hoe het werkt, maar hoe je het moet gebruiken.
En de ontzettend coole Cilium is nog geen 30 jaar oud, hij is nog niet verouderd. Kubernetes heeft hetzelfde probleem, kopiëren. Dat Cilium perfect is geïnstalleerd, dat Kubernetes perfect is geïnstalleerd, maar als er iets misgaat in de productie, kun je dan in een kritieke situatie snel begrijpen wat er mis is gegaan?
Als we zeggen of het moeilijk is om Kubernetes te onderhouden: nee, het is heel gemakkelijk, en ja, het is ongelooflijk moeilijk. Kubernetes werkt prima op zichzelf, maar met een miljard nuances.
Over de ‘Ik heb geluk’-aanpak
— Zijn er bedrijven waar deze nuances bijna gegarandeerd voorkomen? Stel dat Yandex ineens alle diensten overdraagt aan Kubernetes, dan komt daar een enorme belasting.
Dmitry: Nee, dit is geen gesprek over de lading, maar over de simpelste dingen. We hebben bijvoorbeeld Kubernetes, daar hebben we de applicatie uitgerold. Hoe weet je dat het werkt? Er is eenvoudigweg geen kant-en-klaar hulpmiddel om te begrijpen dat de applicatie niet crasht. Er bestaat geen kant-en-klaar systeem dat waarschuwingen verstuurt; u moet deze waarschuwingen en elk schema configureren. En we zijn Kubernetes aan het updaten.
Ik heb Ubuntu 16.04. Je kunt zeggen dat dit een oude versie is, maar we zijn er nog steeds mee bezig omdat het LTS is. Er is een systematiek, waarvan de nuance is dat het C-groepen niet opruimt. Kubernetes lanceert pods, creëert C-groepen en verwijdert vervolgens pods, en op de een of andere manier blijkt (ik herinner me de details niet, sorry) dat er systemd-plakken blijven bestaan. Dit leidt ertoe dat elke auto na verloop van tijd sterk begint te vertragen. Dit is niet eens een vraag over highload. Als er permanente pods worden gelanceerd, bijvoorbeeld als er een Cron Job is die voortdurend pods genereert, zal de machine met Ubuntu 16.04 na een week beginnen te vertragen. Er zal een constant hoog belastinggemiddelde zijn vanwege het feit dat er een aantal C-groepen zijn gemaakt. Dit is het probleem waarmee iedereen die eenvoudig Ubuntu 16 en Kubernetes bovenop installeert, te maken krijgt.
Laten we zeggen dat hij op de een of andere manier systemd of iets anders bijwerkt, maar in de Linux-kernel tot 4.16 is het zelfs nog grappiger: als je C-groepen verwijdert, lekken ze in de kernel en worden ze niet daadwerkelijk verwijderd. Daarom zal het na een maand werken aan deze machine onmogelijk zijn om naar de geheugenstatistieken voor de haarden te kijken. We halen een bestand eruit, rollen het in het programma en één bestand rolt 15 seconden lang, omdat de kernel er erg lang over doet om een miljoen C-groepen in zichzelf te tellen, die lijken te zijn verwijderd, maar nee - ze lekken .
Er zijn hier en daar nog steeds veel van zulke kleine dingen. Dit is geen probleem waar gigantische bedrijven soms mee te maken kunnen krijgen onder zeer zware lasten - nee, het is een kwestie van alledaagse dingen. Mensen kunnen maandenlang zo leven - ze hebben Kubernetes geïnstalleerd, de applicatie geïmplementeerd - het lijkt te werken. Voor veel mensen is dit normaal. Ze zullen niet eens weten dat deze applicatie om de een of andere reden zal crashen, ze zullen geen waarschuwing ontvangen, maar voor hen is dit de norm. Vroeger leefden we op virtuele machines zonder monitoring, nu zijn we overgestapt op Kubernetes, ook zonder monitoring - wat is het verschil?
De vraag is dat als we op ijs lopen, we nooit de dikte ervan weten, tenzij we deze van tevoren meten. Veel mensen lopen en maken zich geen zorgen, omdat ze al eerder hebben gelopen.
Vanuit mijn standpunt is het de nuance en complexiteit van elk systeem om ervoor te zorgen dat de dikte van het ijs precies genoeg is om onze problemen op te lossen. Dit is waar we het over hebben.
Het lijkt mij dat er in de IT-sector te veel ‘ik heb geluk’-benaderingen bestaan. Veel mensen installeren software en gebruiken softwarebibliotheken in de hoop dat ze geluk zullen hebben. Over het algemeen hebben veel mensen geluk. Dat is waarschijnlijk waarom het werkt.
— Vanuit mijn pessimistische inschatting ziet het er zo uit: als de risico’s groot zijn en de applicatie moet werken, dan is er ondersteuning nodig van Flaunt, misschien van Red Hat, of heb je je eigen interne team nodig dat zich specifiek met Kubernetes bezighoudt, en dat klaar staat om het eraf te trekken.
Dmitry: Objectief gezien is dit zo. Als u in uw eentje in het Kubernetes-verhaal duikt, brengt een klein team een aantal risico's met zich mee.
Hebben we containers nodig?
– Kunt u ons vertellen hoe wijdverbreid Kubernetes in Rusland is?
Dmitry: Ik heb deze gegevens niet, en ik weet niet zeker of iemand anders deze heeft. Wij zeggen: “Kubernetes, Kubernetes”, maar er is ook een andere manier om naar deze kwestie te kijken. Ik weet ook niet hoe wijdverspreid containers zijn, maar ik ken een cijfer uit rapporten op internet dat 70% van de containers door Kubernetes wordt georkestreerd. Het was een betrouwbare bron voor een vrij grote steekproef over de hele wereld.
Dan nog een vraag: hebben we containers nodig? Mijn persoonlijke gevoel en het algemene standpunt van het bedrijf Flant zijn dat Kubernetes een de facto standaard is.
Er zal niets anders zijn dan Kubernetes.
Dit is een absolute gamechanger op het gebied van infrastructuurbeheer. Gewoon absoluut - dat is alles, geen Ansible, Chef, virtuele machines, Terraform meer. Ik heb het niet over de oude collectieve boerderijmethoden. Kubernetes is een absolute veranderaar, en nu zal het alleen zo zijn.
Het is duidelijk dat het voor sommigen een paar jaar duurt, en voor anderen een paar decennia, om dit te beseffen. Ik twijfel er niet aan dat er niets anders zal zijn dan Kubernetes en deze nieuwe look: we beschadigen niet langer het besturingssysteem, maar gebruiken infrastructuur als code, alleen niet met code, maar met yml - een declaratief beschreven infrastructuur. Ik heb het gevoel dat dit altijd zo zal blijven.
— Dat wil zeggen: de bedrijven die nog niet op Kubernetes zijn overgestapt, zullen er zeker naar overstappen of in de vergetelheid blijven. Ik heb je goed begrepen?
Dmitry: Dit is ook niet helemaal waar. Als we bijvoorbeeld de taak hebben om een DNS-server te draaien, dan kan deze draaien op FreeBSD 4.10 en kan hij 20 jaar perfect werken. Gewoon werken en dat is alles. Misschien moet er over twintig jaar wel een keer iets vernieuwd worden. Als we het hebben over software in het formaat dat we hebben gelanceerd en die daadwerkelijk jarenlang werkt zonder enige updates, zonder wijzigingen aan te brengen, dan zal er uiteraard geen Kubernetes zijn. Hij is daar niet nodig.
Alles met betrekking tot CI/CD - waar Continuous Delivery nodig is, waar u versies moet updaten, actieve wijzigingen moet aanbrengen, waar u fouttolerantie moet opbouwen - alleen Kubernetes.
Over microservices
- Hier heb ik een lichte dissonantie. Om met Kubernetes te werken heb je externe of interne ondersteuning nodig - dit is het eerste punt. Ten tweede: als we net beginnen met ontwikkelen, zijn we een kleine startup, hebben we nog niets. Ontwikkeling voor Kubernetes of microservice-architectuur in het algemeen kan complex zijn en niet altijd economisch verantwoord. Ik ben geïnteresseerd in jouw mening: moeten startups meteen helemaal opnieuw beginnen met schrijven voor Kubernetes, of kunnen ze nog steeds een monoliet schrijven en dan alleen naar Kubernetes komen?
Dmitry: Coole vraag. Ik heb een gesprek over microservices Vaak ben ik mensen tegengekomen die spijkers probeerden te slaan met een microscoop. De aanpak op zich klopt; wij ontwerpen zelf onze interne software op deze manier. Maar wanneer u dit doet, moet u duidelijk begrijpen wat u doet. Het woord dat ik het meest haat aan microservices is ‘micro’. Historisch gezien is dit woord daar ontstaan, en om de een of andere reden denken mensen dat micro heel klein is, minder dan een millimeter, zoals een micrometer. Dit is fout.
Er is bijvoorbeeld een monoliet die door 300 mensen is geschreven, en iedereen die aan de ontwikkeling heeft deelgenomen, begrijpt dat daar problemen zijn, en deze moet in microstukjes worden opgesplitst - ongeveer 10 stukjes, die elk door 30 mensen zijn geschreven in een minimale versie. Dit is belangrijk, noodzakelijk en cool. Maar als er een startup naar ons toekomt, waar 3 hele coole en getalenteerde jongens 60 microservices op hun knieën schreven, elke keer als ik naar Corvalol zoek.
Het lijkt mij dat hier al duizenden keren over gesproken is: we hebben een gedistribueerde monoliet in een of andere vorm. Dit is economisch niet verantwoord, het is over het algemeen in alles erg moeilijk. Ik heb dit zo vaak gezien dat het me echt pijn doet, dus ik blijf erover praten.
Op de initiële vraag is er een conflict tussen het feit dat Kubernetes enerzijds eng is om te gebruiken, omdat het niet duidelijk is wat daar kapot kan gaan of niet werkt, en anderzijds is het duidelijk dat alles daar naartoe gaat en er zal niets anders bestaan dan Kubernetes. Antwoord - weeg de hoeveelheid voordeel die u krijgt, de hoeveelheid taken die u kunt oplossen. Dit bevindt zich aan één kant van de schaal. Aan de andere kant zijn er risico's verbonden aan downtime of aan een afname van de responstijd, het beschikbaarheidsniveau - met een afname van prestatie-indicatoren.
Hier is het: óf we handelen snel, en Kubernetes stelt ons in staat veel dingen veel sneller en beter te doen, óf we gebruiken betrouwbare, beproefde oplossingen, maar bewegen veel langzamer. Dit is een keuze die ieder bedrijf moet maken. Je kunt het zien als een pad in de jungle: als je voor de eerste keer loopt, kun je een slang, een tijger of een gekke das tegenkomen, en als je tien keer hebt gelopen, heb je het pad betreden, verwijderd de takken en loop gemakkelijker. Elke keer wordt het pad breder. Dan is het een asfaltweg, en later een prachtige boulevard.
Kubernetes staat niet stil. Nogmaals vraag: Kubernetes is enerzijds 4-5 binaire bestanden, anderzijds is het het hele ecosysteem. Dit is het besturingssysteem dat we op onze machines hebben. Wat is dit? Ubuntu of curiosa? Dit is de Linux-kernel, een heleboel extra componenten. Al deze dingen hier, één giftige slang werd van de weg gegooid, daar werd een hek geplaatst. Kubernetes ontwikkelt zich zeer snel en dynamisch, en het volume van de risico's, het volume van het onbekende neemt elke maand af en dienovereenkomstig worden deze schalen opnieuw in evenwicht gebracht.
Als antwoord op de vraag wat een startup zou moeten doen, zou ik zeggen: kom naar Flaunt, betaal 150 duizend roebel en ontvang een kant-en-klare DevOps-eenvoudige service. Als je een kleine startup bent met een paar ontwikkelaars, werkt dit. In plaats van uw eigen DevOps in te huren, die op dit moment moeten leren hoe u uw problemen kunt oplossen en een salaris kunt betalen, krijgt u een kant-en-klare oplossing voor alle problemen. Ja, er zijn enkele nadelen. Wij als uitbesteder kunnen niet zo betrokken zijn en reageren snel op veranderingen. Maar we hebben veel expertise en kant-en-klare praktijken. We garanderen dat we er in elke situatie zeker snel achter zullen komen en alle Kubernetes uit de dood zullen opwekken.
Ik raad ten zeerste aan om uit te besteden aan startups en gevestigde bedrijven tot een omvang waarbij je een team van 10 mensen aan de operatie kunt wijden, omdat het anders geen zin heeft. Het is zeker zinvol om dit uit te besteden.
Over Amazon en Google
— Kan een host uit een oplossing van Amazon of Google als outsource worden beschouwd?
Dmitry: Ja, natuurlijk lost dit een aantal problemen op. Maar opnieuw zijn er nuances. Je moet nog steeds begrijpen hoe je het moet gebruiken. Er zitten bijvoorbeeld duizend kleine dingen in het werk van Amazon AWS: de Load Balancer moet worden opgewarmd of er moet vooraf een verzoek worden geschreven dat “jongens, we zullen verkeer ontvangen, warm de Load Balancer voor ons op!” Je moet deze nuances kennen.
Wanneer je je wendt tot mensen die hierin gespecialiseerd zijn, krijg je bijna alle typische zaken dicht. We hebben nu 40 ingenieurs, tegen het einde van het jaar zullen dat er waarschijnlijk 60 zijn; we zijn al deze dingen zeker tegengekomen. Zelfs als we dit probleem bij een project opnieuw tegenkomen, vragen we elkaar snel en weten we hoe we het kunnen oplossen.
Waarschijnlijk is het antwoord: natuurlijk maakt een gehost verhaal een deel eenvoudiger. De vraag is of u bereid bent deze hosters te vertrouwen en of zij uw problemen zullen oplossen. Amazon en Google hebben het goed gedaan. Voor al onze gevallen - precies. Wij hebben geen positieve ervaringen meer. Alle andere clouds waarmee we probeerden te werken, veroorzaken veel problemen - Ager en alles wat zich in Rusland bevindt, en allerlei soorten OpenStack in verschillende implementaties: Headster, Overage - wat je maar wilt. Ze creëren allemaal problemen die je niet wilt oplossen.
Het antwoord is dus ja, maar in feite zijn er niet veel volwassen gehoste oplossingen.
Wie heeft Kubernetes nodig?
– En toch, wie heeft Kubernetes nodig? Wie moet er al overstappen naar Kubernetes, wie is de typische Flaunt-client die specifiek voor Kubernetes komt?
Dmitry: Dit is een interessante vraag, want op dit moment, in de nasleep van Kubernetes, komen veel mensen naar ons toe: “Jongens, we weten dat jullie Kubernetes doen, doe het voor ons!” Wij antwoorden hen: “Heren, wij doen niet aan Kubernetes, wij doen aan prod en alles wat daarmee samenhangt.” Omdat het momenteel simpelweg onmogelijk is om een product te maken zonder alle CI/CD en dit hele verhaal te doen. Iedereen heeft afstand genomen van de tweedeling dat we ontwikkeling na ontwikkeling hebben, en vervolgens uitbuiting na uitbuiting.
Onze klanten verwachten verschillende dingen, maar iedereen wacht op een goed wonder dat ze bepaalde problemen hebben, en nu - hop! — Kubernetes zal ze oplossen. Mensen geloven in wonderen. In hun hoofd begrijpen ze dat er geen wonder zal plaatsvinden, maar in hun ziel hopen ze - wat als deze Kubernetes nu alles voor ons zal oplossen, ze praten er zoveel over! Plotseling hij nu - nies! - en een zilveren kogel, nies! – en we hebben 100% uptime, alle ontwikkelaars kunnen alles wat in productie komt 50 keer vrijgeven, zonder dat het crasht. Over het algemeen een wonder!
Als zulke mensen bij ons komen, zeggen we: “Sorry, maar er bestaat niet zoiets als een wonder.” Om gezond te zijn, moet je goed eten en bewegen. Om een betrouwbaar product te hebben, moet het betrouwbaar worden gemaakt. Om een handige CI/CD te hebben, moet je hem zo maken. Dat is een hoop werk dat gedaan moet worden.
Beantwoording van de vraag wie Kubernetes nodig heeft: niemand heeft Kubernetes nodig.
Sommige mensen hebben de misvatting dat ze Kubernetes nodig hebben. Mensen hebben een diepe behoefte om te stoppen met denken, studeren en geïnteresseerd zijn in alle problemen van de infrastructuur en de problemen van het draaien van hun applicaties. Ze willen dat applicaties gewoon werken en gewoon worden ingezet. Voor hen is Kubernetes de hoop dat ze niet langer het verhaal zullen horen dat “we daar lagen”, of “we niet kunnen uitrollen”, of iets anders.
Meestal komt de technisch directeur naar ons toe. Ze vragen hem twee dingen: aan de ene kant geven ze ons kenmerken, aan de andere kant stabiliteit. Wij raden u aan om het op uzelf te nemen en het te doen. Het wondermiddel, of beter gezegd verzilverd, is dat u niet meer aan deze problemen denkt en geen tijd verspilt. Er zullen speciale mensen zijn die dit onderwerp zullen sluiten.
De bewoording dat wij of iemand anders Kubernetes nodig heeft, is onjuist.
Beheerders hebben Kubernetes echt nodig, omdat het een heel interessant speeltje is waar je mee kunt spelen en sleutelen. Laten we eerlijk zijn: iedereen houdt van speelgoed. We zijn allemaal ergens kinderen, en als we een nieuwe zien, willen we ermee spelen. Voor sommigen is dit bijvoorbeeld ontmoedigd door de administratie, omdat ze al genoeg hebben gespeeld en al zo moe zijn dat ze gewoon niet meer willen. Maar dit is voor niemand helemaal verloren. Als ik bijvoorbeeld al heel lang genoeg heb van speelgoed op het gebied van systeembeheer en DevOps, dan ben ik nog steeds dol op het speelgoed, ik koop nog steeds wat nieuwe. Alle mensen willen op de een of andere manier nog steeds een soort speelgoed.
Je hoeft niet met de productie te spelen. Wat ik ook categorisch afraad en wat ik nu massaal zie: “Oh, een nieuw speeltje!” – ze renden om het te kopen, kochten het en: “Laten we het nu naar school brengen en aan al onze vrienden laten zien.” Doe dit niet. Mijn excuses, mijn kinderen groeien net op, ik zie constant iets bij kinderen, merk het bij mezelf op en generaliseer het vervolgens naar anderen.
Het uiteindelijke antwoord is: je hebt Kubernetes niet nodig. Je moet je problemen oplossen.
Wat je kunt bereiken is:
- prik valt niet;
- zelfs als hij probeert te vallen, weten we dat van tevoren en kunnen we er iets in stoppen;
- we kunnen het veranderen met de snelheid waarmee ons bedrijf het nodig heeft, en we kunnen het gemakkelijk doen; het levert ons geen problemen op.
Er zijn twee echte behoeften: betrouwbaarheid en dynamiek/flexibiliteit bij de uitrol. Iedereen die momenteel een of ander soort IT-project uitvoert, ongeacht in welk soort bedrijf - zacht voor het verlichten van de wereld, en die dit begrijpt, moet deze behoeften oplossen. Met Kubernetes kun je ze met de juiste aanpak, met het juiste inzicht en met voldoende ervaring oplossen.
Over serverloos
— Als je wat verder in de toekomst kijkt en probeert het probleem van de afwezigheid van hoofdpijn met infrastructuur op te lossen, met de snelheid van de uitrol en de snelheid van applicatieveranderingen, verschijnen er bijvoorbeeld nieuwe oplossingen zonder server. Voelt u enig potentieel in deze richting en, laten we zeggen, een gevaar voor Kubernetes en soortgelijke oplossingen?
Dmitry: Hier moeten we nogmaals opmerken dat ik geen ziener ben die vooruitkijkt en zegt: zo zal het zijn! Hoewel ik net hetzelfde deed. Ik kijk naar mijn voeten en zie daar een heleboel problemen, bijvoorbeeld hoe transistors in een computer werken. Het is grappig, toch? We komen enkele bugs tegen in de CPU.
Maak serverless behoorlijk betrouwbaar, goedkoop, efficiënt en handig, en los alle ecosysteemproblemen op. Op dit punt ben ik het met Elon Musk eens dat er een tweede planeet nodig is om fouttolerantie voor de mensheid te creëren. Hoewel ik niet weet wat hij zegt, begrijp ik dat ik er nog niet klaar voor ben om zelf naar Mars te vliegen en dat het morgen ook niet zal gebeuren.
Met serverless is het duidelijk duidelijk dat dit ideologisch correct is, net als fouttolerantie voor de mensheid: het hebben van twee planeten is beter dan één. Maar hoe moet je dat nu doen? Eén expeditie sturen is geen probleem als je je inspanningen daarop concentreert. Het is volgens mij ook realistisch om meerdere expedities te sturen en daar enkele duizenden mensen te vestigen. Maar om het volledig fouttolerant te maken, zodat de helft van de mensheid daar woont, lijkt het mij nu onmogelijk, als er niet over wordt nagedacht.
Met serverless één op één: het ding is cool, maar het is verre van de problemen van 2019. Dichter bij 2030 – laten we het meemaken. Ik twijfel er niet aan dat we zullen leven, we zullen zeker leven (herhaal dit voordat we naar bed gaan), maar nu moeten we andere problemen oplossen. Het is alsof je in de sprookjespony Rainbow gelooft. Ja, een paar procent van de gevallen is opgelost, en ze zijn perfect opgelost, maar subjectief gezien is serverloos een regenboog... Voor mij is dit onderwerp te ver weg en te onbegrijpelijk. Ik ben niet klaar om te praten. Anno 2019 kun je geen enkele applicatie schrijven met serverless.
Hoe Kubernetes zal evolueren
– Hoe denk je dat Kubernetes en het ecosysteem eromheen zich zullen ontwikkelen terwijl we deze potentieel prachtige verre toekomst tegemoet gaan?
Dmitry: Ik heb hier veel over nagedacht en ik heb een duidelijk antwoord. De eerste is statefull; staatloos is immers gemakkelijker te doen. Kubernetes investeerde hier aanvankelijk meer in, het begon er allemaal mee. Stateless werkt vrijwel perfect in Kubernetes, er valt gewoon niets te klagen. Er zijn nog steeds veel problemen, of beter gezegd, nuances. Alles daar werkt al prima voor ons, maar dat zijn wij. Het zal nog minstens een paar jaar duren voordat dit voor iedereen werkt. Dit is geen berekende indicator, maar mijn gevoel vanuit mijn hoofd.
Kortom, statefull moet – en zal – zich zeer sterk ontwikkelen, omdat al onze applicaties status opslaan; er zijn geen stateless applicaties. Dit is een illusie; je hebt altijd een soort database en iets anders nodig. Statefull gaat over het rechtzetten van alles wat mogelijk is, het oplossen van alle bugs, het verbeteren van alle problemen waarmee we momenteel worden geconfronteerd - laten we het adoptie noemen.
Het niveau van het onbekende, het niveau van onopgeloste problemen, het niveau van de waarschijnlijkheid dat je iets tegenkomt, zullen aanzienlijk dalen. Dit is een belangrijk verhaal. En operators - alles wat te maken heeft met de codificatie van beheerlogica, besturingslogica om een gemakkelijke service te krijgen: MySQL eenvoudige service, RabbitMQ eenvoudige service, Memcache eenvoudige service - in het algemeen, al deze componenten waarvan we zeker moeten weten dat ze eruit zullen werken de doos. Dit lost gewoon de pijn op dat we een database willen, maar deze niet willen beheren, of dat we Kubernetes willen, maar deze niet willen beheren.
Dit verhaal over de ontwikkeling van operators in een of andere vorm zal de komende jaren belangrijk zijn.
Ik denk dat het gebruiksgemak enorm moet toenemen: de doos wordt steeds zwarter, steeds betrouwbaarder, met steeds simpelere knoppen.
Ik luisterde ooit naar een oud interview met Isaac Asimov uit de jaren 80 op YouTube op Saturday Night Live - een programma als Urgant, alleen maar interessant. Ze vroegen hem naar de toekomst van computers. Hij zei dat de toekomst in eenvoud ligt, net als bij de radio. De radio-ontvanger was oorspronkelijk een complex ding. Om een golf te vangen, moest je 15 minuten aan de knoppen draaien, aan de spiesjes draaien en over het algemeen weten hoe alles werkt, de fysica van de transmissie van radiogolven begrijpen. Hierdoor bleef er nog maar één knop over in de radio.
Nu in 2019 welke radio? In de auto vindt de radio-ontvanger alle golven en de namen van de zenders. De fysica van het proces is in 100 jaar niet veranderd, maar het gebruiksgemak wel. Nu, en niet alleen nu, al in 1980, toen er een interview was met Azimov, gebruikte iedereen de radio en niemand dacht na over hoe het werkte. Het heeft altijd gewerkt, dat is een gegeven.
Azimov zei toen dat het hetzelfde zou zijn met computers - gebruiksgemak zal toenemen. Terwijl je in 1980 moest worden getraind in het indrukken van knoppen op een computer, zal dat in de toekomst niet meer het geval zijn.
Ik heb het gevoel dat er met Kubernetes en met de infrastructuur ook een enorme toename in gebruiksgemak gaat plaatsvinden. Dit is naar mijn mening duidelijk: het ligt aan de oppervlakte.
Wat te doen met ingenieurs?
— Wat zal er dan gebeuren met de ingenieurs en systeembeheerders die Kubernetes ondersteunen?
Dmitry: Wat gebeurde er met de accountant na de komst van 1C? Ongeveer hetzelfde. Voordien telden ze op papier - nu in het programma. De arbeidsproductiviteit is met ordes van grootte toegenomen, maar de arbeid zelf is niet verdwenen. Waren er voorheen tien ingenieurs nodig om een gloeilamp in te draaien, nu is één voldoende.
De hoeveelheid software en het aantal taken groeit, zo lijkt mij, nu sneller dan er nieuwe DevOps verschijnen en de efficiëntie neemt toe. Er is momenteel een specifiek tekort op de markt en dat zal nog lang aanhouden. Later zal alles terugkeren naar een soort normaliteit, waarin de efficiëntie van het werk zal toenemen, er steeds meer serverless zal zijn, een neuron zal worden gekoppeld aan Kubernetes, dat alle bronnen precies zal selecteren zoals nodig, en in het algemeen zal doe alles zelf, zoals het hoort - de persoon stapt gewoon weg en bemoeit zich niet.
Maar iemand zal nog steeds beslissingen moeten nemen. Het is duidelijk dat het kwalificatieniveau en de specialisatie van deze persoon hoger is. Tegenwoordig heb je op de boekhoudafdeling geen tien medewerkers nodig die de boeken bijhouden, zodat hun handen niet moe worden. Het is gewoon niet nodig. Veel documenten worden automatisch gescand en herkend door het elektronische documentbeheersysteem. Eén slimme hoofdaccountant is voldoende, al met veel grotere vaardigheden en met goed inzicht.
Over het algemeen is dit de juiste keuze in alle sectoren. Hetzelfde geldt voor auto’s: voorheen kwam er een auto met een monteur en drie chauffeurs. Tegenwoordig is autorijden een eenvoudig proces waar we allemaal dagelijks aan deelnemen. Niemand denkt dat een auto iets ingewikkelds is.
DevOps of systeemtechniek zullen niet verdwijnen – werk op hoog niveau en de efficiëntie zullen toenemen.
— Ik hoorde ook een interessant idee dat het werk daadwerkelijk zal toenemen.
Dmitry: Natuurlijk, honderd procent! Omdat de hoeveelheid software die we schrijven voortdurend groeit. Het aantal problemen dat wij met software oplossen groeit voortdurend. De hoeveelheid werk groeit. Nu is de DevOps-markt vreselijk oververhit. Dit is terug te zien in de salarisverwachtingen. Op een goede manier, zonder in details te treden, zouden er junioren moeten zijn die X willen, middenklassen die 1,5X willen, en senioren die 2X willen. En als je nu naar de Moskouse DevOps-salarismarkt kijkt, wil een junior van X naar 3X en een senior van X naar 3X.
Niemand weet hoeveel het kost. Het salarisniveau wordt gemeten aan de hand van je zelfvertrouwen - een compleet gekkenhuis, om eerlijk te zijn, een vreselijk oververhitte markt.
Natuurlijk zal deze situatie zeer snel veranderen - er zou enige verzadiging moeten optreden. Dit is niet het geval bij softwareontwikkeling - ondanks het feit dat iedereen ontwikkelaars nodig heeft, en iedereen goede ontwikkelaars nodig heeft, begrijpt de markt wie wat waard is - de industrie is tot rust gekomen. Dat is tegenwoordig niet het geval met DevOps.
— Uit wat ik hoorde heb ik geconcludeerd dat de huidige systeembeheerder zich niet al te veel zorgen hoeft te maken, maar dat het tijd is om zijn vaardigheden te verbeteren en zich voor te bereiden op het feit dat er morgen meer werk zal zijn, maar dat het hoger gekwalificeerd zal zijn.
Dmitry: Honderd procent. Over het algemeen leven we in 2019 en de levensregel is deze: levenslang leren - we leren ons hele leven lang. Het lijkt mij dat iedereen dit nu al weet en voelt, maar het is niet genoeg om het te weten: je moet het doen. Elke dag moeten we veranderen. Als we dit niet doen, worden we vroeg of laat aan de zijlijn van de beroepsgroep geplaatst.
Wees voorbereid op scherpe bochten van 180 graden. Ik sluit een situatie niet uit waarin iets radicaal verandert, er iets nieuws wordt uitgevonden – het gebeurt. Hop! - en we handelen nu anders. Het is belangrijk om hierop voorbereid te zijn en je geen zorgen te maken. Het kan gebeuren dat morgen alles wat ik doe onnodig blijkt te zijn - niets, ik heb mijn hele leven gestudeerd en ben klaar om iets anders te leren. Het is geen probleem. U hoeft niet bang te zijn voor werkzekerheid, maar u moet wel bereid zijn voortdurend iets nieuws te leren.
Wensen en een minuutje reclame
- Heeft u een wens?
Dmitry: Ja, ik heb meerdere wensen.
Eerste en commerciële - abonneer u op . Beste lezers, ga naar YouTube en abonneer je op ons kanaal. Over ongeveer een maand beginnen we met de actieve uitbreiding van de videodienst. We zullen veel educatieve inhoud over Kubernetes hebben, open en gevarieerd: van praktische dingen, tot aan laboratoria, tot diepgaande fundamentele theoretische dingen en hoe Kubernetes te gebruiken op de werkvloer. niveau van principes en patronen.
De tweede handelswens - ga naar en plaats sterren omdat wij ons ermee voeden. Als je ons geen sterren geeft, hebben we niets te eten. Het is als mana in een computerspel. We doen iets, we doen het, we proberen het, iemand zegt dat dit vreselijke fietsen zijn, iemand zegt dat alles helemaal verkeerd is, maar we gaan door en handelen absoluut eerlijk. Wij zien een probleem, lossen het op en delen onze ervaringen. Geef ons daarom een ster, hij zal niet van jou weggaan, maar hij zal naar ons toe komen, omdat we ons ermee voeden.
Ten derde, een belangrijke en niet langer commerciële wens: stop met geloven in sprookjes. Jullie zijn professionals. DevOps is een zeer serieus en verantwoordelijk beroep. Stop met spelen op de werkvloer. Laat het voor je klikken en je zult het begrijpen. Stel je voor dat je naar het ziekenhuis komt en daar experimenteert de dokter met je. Ik begrijp dat dit voor iemand beledigend kan zijn, maar hoogstwaarschijnlijk gaat dit niet over jou, maar over iemand anders. Zeg tegen anderen dat ze ook moeten stoppen. Dit verpest echt het leven van ons allemaal; velen beginnen operations, admins en DevOps te behandelen als kerels die weer iets kapot hebben gemaakt. Dit werd meestal 'gebroken' vanwege het feit dat we gingen spelen en niet met een koud bewustzijn keken dat dit is hoe het is, en zo is het.
Dit betekent niet dat je niet mag experimenteren. We moeten experimenteren, we doen het zelf. Eerlijk gezegd spelen we zelf soms spelletjes - dit is natuurlijk heel erg, maar niets menselijks is ons vreemd. Laten we 2019 uitroepen tot een jaar van serieuze, goed doordachte experimenten, en niet van games op productie. Waarschijnlijk.
- Hartelijk dank!
Dmitry: Bedankt, Vitaly, zowel voor de tijd als voor het interview. Beste lezers, hartelijk dank als u plotseling dit punt heeft bereikt. Ik hoop dat we je op zijn minst een paar gedachten hebben gebracht.
In het interview ging Dmitry in op de kwestie van de werf. Nu is dit een universeel Zwitsers mes dat bijna alle problemen oplost. Maar dat was niet altijd zo. Op op het festival Dmitry Stolyarov zal u in detail over deze tool vertellen. in het rapport er zal van alles zijn: problemen en verborgen nuances van Kubernetes, opties om deze moeilijkheden op te lossen en de huidige implementatie van werf in detail. Kom met ons mee op 27 en 28 mei, wij creëren de perfecte tools.
Bron: www.habr.com