Denne habrapost er et interview med Anton Weiss, medejer af teknologirådgivning Otomato Software, med mere end 15 års erfaring inden for højteknologi. Han er ekspert i teknisk undervisning, initiativtager og medforfatter til det første DevOps-certificeringskursus i Israel. Anton deltager i internationale konferencer og er kendt som en sej foredragsholder.
Vi vil tale om følgende emner:
Forskellen mellem Rusland og Israel
Oleg: Fortæl os, hvem du er, og hvad du laver.
Anton: Jeg er Anton, født i Sankt Petersborg, men som 15-årig flyttede jeg til Israel og har boet der siden. I de sidste tyve år i Israel har jeg været involveret i IT i dens forskellige afskygninger. Af disse tyve år har jeg de sidste ti specialiseret mig i alt relateret til levering af software: integration, det, der engang blev kaldt konfigurationsstyring, og det, der nu hedder DevOps. Jeg arbejdede i store virksomheder - i internationale virksomheder som AT&T, BMC. Arbejdede i startups. De sidste fire år har jeg mit eget konsulentfirma, kaldet Otomato Software, hvor vi beskæftiger os med at hjælpe organisationer med at optimere leveringsprocesser og mestre nye værktøjer: Det vil sige, vi laver både den tekniske del og alt omkring det.
Oleg: Er der forskel på Rusland og Israel med hensyn til arbejde?
Anton: Jeg har næsten aldrig arbejdet med russiske kunder. Det, der har forbundet mig med Rusland i de sidste 3 år, er konferencer. Og i flere russiske virksomheder udførte vi noget som en revision: vi kom, kiggede, fandt ud af det, udstedte nogle anbefalinger og gik. Det vil sige, at der ikke var sådan noget dagligt arbejde, så det er svært for mig at sige præcis, hvordan det adskiller sig. Jeg tror, der er forskellige ting overalt. Det vil sige, at vi for eksempel i Israel har så tunge virksomhedsorganisationer, hvor folk har arbejdet i 15 år, og alt går meget hårdt. Og uanset hvordan de forsøger at lave en form for transformation, forbedre processer: de vil tale og tale, men... Vi har en klient, som vi for to år siden gjorde alt med og tog alle beslutninger, udviklede alle programmerne og I det øjeblik gik det hele i stå, og vi kom derfra. For bare et par dage siden mødte jeg cheferne derfra, som vi arbejdede med, og jeg sagde:
- Nå, hvordan?
- Nå, sådan her. Det er svært, siger de, vi gør det, nu begynder der at ske noget.
To år senere. Der er politik, der er indflydelseszoner. Der er mennesker, der ikke ønsker at give slip på disse indflydelseszoner, derfor, når en sådan situation opstår, er det meget svært at ændre noget. Nå, selve værktøjerne bevæger sig på en eller anden måde fremad. På den anden side er der i Israel startups, hvor alt ændrer sig meget hurtigt, det er nemt at rejse et nyt værktøj, og de er allerede alle cloud-native og er helt i skyen. Dette kan i øvrigt være en af de håndgribelige forskelle mellem Rusland og Israel. I Israel er den offentlige sky meget lettere. Ud fra hvad jeg så. I Rusland ser det for eksempel ud til, at det er meget svært for alle undtagen startups at gå til den offentlige sky, men i Israel er det stadig nemmere. I dag har selv banker og forsikringsselskaber allerede en vis forståelse for, at i det mindste nogle af deres ejendele kan rulles ud til den offentlige sky. Og ingen her er bange for kontrakter med Google og Amazon. Ud fra det, jeg hørte på konferencer i Rusland, er det stadig mere kompliceret der, ja, selv fra synspunktet om sanktioner eller ikke-sanktioner og nogle juridiske spørgsmål.
Forskellen mellem startups og giganter
Oleg: Jeg forstår. Hvor er det i øvrigt mere interessant og sjovt for dig at arbejde: i startups eller i store organisationer?
Anton: Det er selvfølgelig mere behageligt i startups, fordi store organisationer... ja, egentlig er det bare, at materialet bevæger sig meget hårdt. Det har selvfølgelig sine fordele. Ser man på store organisationer, har de for eksempel meget mere af det, man kalder diversitet. Store virksomheder er, simpelthen fordi de har brug for mange mennesker, eller fordi det er en form for organisationskultur, der har udviklet sig gennem årene, klar til at ansætte forskellige mennesker. Helt konkret vil man her i Israel for eksempel i startups næppe finde for eksempel arabere, der er næsten ingen af dem. I store organisationer er dette meget nemmere. Men startups vokser ud af en eller anden form for kulturel baggrund, hvor størstedelen af deltagerne dybest set er de samme hvide mænd. Der er en kultur der, at man skal arbejde hårdt, og det er tilrådeligt at arbejde 10-12 timer om dagen, og det er heller ikke nok. Det virker, som om vi har Moskva (altså Tel Aviv) bag os, der er ingen steder at trække sig tilbage, og derfor må vi bløde her og nu.
Oleg: Hvad med forskellen i tilgangen til DevOps i små og store virksomheder? Det vil sige, at hvis du for eksempel arbejder for to personer, skal du ikke opsætte CI/CD for dig selv, men kopiere artefakter ved hjælp af SCP.
Anton: På den ene side, ja. På den anden side betyder opsætning af CI/CD i dag ikke, at du virkelig laver kontinuerlig levering. Men at oprette en form for pipeline for dig selv, hvis du er et firma på to personer, er meget, meget enkelt. Hvis du før havde brug for at blive forvirret på en eller anden måde, har du i dag en masse cloud-tjenester. Jeg skrev YAML og så gik vi. Det er nemmere med dette. Faktisk består udfordringen i forvoksede startups. Dem, der er gået ud over 20 personer, og det er her, de begynder at få smerter ved afskalning, for der er ingen processer. Tidligere fungerede alt på en eller anden måde, men nu begynder alt dette kaos, og det er ikke klart, hvordan vi kan bevare denne tidligere dynamik og samtidig gennemføre processerne og beslutte, hvem der ellers skal gøre alt dette.
Og det er, når alt "vi har et DevOps-team, der vil være ansvarlig for DevOps"-tingene starter, vi ved, hvor det fører hen i de fleste tilfælde. En flaskehals viser sig, og efterhånden vokser de til, hvor de store virksomheder er nu. I store virksomheder er problemet et helt andet, de har ikke længere en flaskehals, men blot en gateway så kraftig, at den åbner en gang om dagen, og resten af tiden samler der sig en enorm mængde affald der. Og så tænker de: "Hvordan kan vi nu lave mange små gateways ud af denne gateway, som kan åbnes meget nemmere?" Altså helt andre problemer. Startups har et problem med, at "vi bliver suget ind i en tragt, hvordan kommer vi ud?", og store virksomheder har et problem - de er allerede i tragten, de er allerede i undergrundsriget, nu er de tænker på, hvordan de kan svømme op igen.
Tendensen mod stigende kompleksitet, og hvad skal man gøre ved det
Oleg: Nå, og plusset ved den tekniske del: når du har få mennesker, simple teknologier, skal du kende nogle grundlæggende ting Linux, og det er det. Og ved den mindste skalering skal du lære noget Kubernetes, og det virker som et problem.
Anton: Og dette er uden tvivl et problem. Vi havde en konference for bare to dage siden, og det var meget bemærkelsesværdigt, at næsten alle, der sagde noget der, nævnte ét ord: "kompleksitet". Dette er blevet en slags definerende ord i hele DevOps-diskursen i dag.
Oleg: Var det sådan for et år siden?
Anton: I forsøget på at gøre alt hurtigt, dynamisk, for at opnå den berygtede fleksibilitet, har vi skabt en sådan kompleksitet for os selv. Der er faktisk en masse små rørledninger, der hver for sig fungerer fantastisk, og så forsøger vi at sammensætte et eller andet billede af verden ud fra alt det her, og det er der, kompleksiteten pludselig opstår. For ud af alle disse små pipelines bygger vi nu én proces, så hele virksomheden fungerer som et menneske.
Oleg: Og hvad er svaret? Hvordan håndterer man denne kompleksitet?
Anton: Nå, der er ingen svar, de er født i processen. Min rapport handlede om en af disse beslutninger. I det store og hele, hvad fører det hele til? På et tidspunkt var jeg inficeret med systemtænkning, det bliver nævnt meget i DevOps. Jeg blev interesseret, jeg læste bøgerne af Peter Senge, Russell Ackoff, Donella Meadows - mennesker, der på et tidspunkt på en eller anden måde startede systemtænkning og i det store og hele skitserede dets hovedpostulater. En af de vigtigste linser, hvorigennem systemtænkning ser på verden, er feedback-loops. Med denne kompleksitet opstår nu disse feedback-loops, det vil sige kompleksiteten bliver meget, meget høj, vi begynder at lede efter værktøjer for på en eller anden måde at kontrollere denne kompleksitet, ja, i det mindste. Jeg siger ikke, at man skal reducere det - at sætte det i skak, så det ikke løser sig.
Centraliserede løsninger dukker stort set op, selv Kubernetes er sådan noget. Du har et centraliseret kontrolplan, som i det øjeblik, du kontrollerer det, vil kontrollere hele kompleksiteten af de tjenester, der kører rundt. Servicesien, det samme servicenet, er den samme type løsning. Vi siger: ”Vi har mange tjenester, vi har brug for, at de på en eller anden måde kan tale med hinanden, for det er uklart, hvor de sidder, og det er uklart, om de vil svare dem eller ej, og de kan ikke selv klare det. . Så lad os gøre dette nu, i midten vil vi indsætte et bestemt universelt sind, der vil fortælle dem, hvem de kan tale med, og hvem de ikke kan tale med, og beskytte dem, hvis de pludselig siger noget uhøfligt som svar." Og der er mange spørgsmål med dette. På den ene side er det en vis nødvendighed, fordi organisationer ikke kan klare det. Vi har hjulpet adskillige organisationer med at flytte til den modige nye verden af Cloud Native i løbet af de sidste par år, især når det kommer efterhånden som virksomheden vokser, den skalerer, og folk bare farer vild. Midt i alt dette er et lille hold af såkaldte DevOps, der skal skrive tusindvis af linjer med YAML for på en eller anden måde at kunne klare det hele, og alt falder bare fra hinanden efter i sømmene.
Cloud Native
Oleg: Kan du forklare lidt, hvad Cloud Native er? Fordi det er blevet en slags buzzword, nu skriver alle det på hver væg. Hvordan ser du det?
Anton: I det store og hele startede det hele med fremkomsten af “platform as a service”-tilgangen, det vil sige, da vi skulle køre meget mere software og meget flere webtjenester, end der var behov for før. Vi indså, at det ikke længere var muligt at udrulle hver service separat, som et elsket kæledyr, som vi kender ved navn og plejer hele vores liv, vi er nødt til at håndtere dem som en slags flok. For at gøre dette har vi brug for en form for homogen platform, som vi kan smide denne kode på, og platformen vil være smart nok til at betjene den. En auto-drinker er kort sagt en auto-drinker-auto-feeder til service.
Pionererne bag denne tilgang var Heroku. De sagde, at for at disse tjenester skal kunne bruge vores infrastrukturer, skal de også være køer. Det vil sige, at de skal have bestemte kvaliteter. Sådan fremstod 12-faktor applikationen, som skulle have så lidt stabil tilstand som muligt. En sådan applikation er nødvendigvis samlet af en slags rørledning, som kontrollerer dens kompatibilitet med platformen. Den skal kunne være spændstig – at vide, at hvis noget går galt, så er der ingen grund til at falde med det samme. På den anden side, i en vis forstand, stol på platformen. Generelt er det en slags hybrid. Forstå, at du ikke er alene, at der er en platform, og du skal respektere dens begrænsninger. I det store og hele startede det hele derfra.
Men af en eller anden grund retfærdiggjorde denne "platform som en service" tilgang ikke sig selv, og det lovede boom skete ikke. Det vil sige, ja, der var Heroku, så umiddelbart efter dem rejste alle de store fyre også analoger: Google App Engine, Amazon - Elastic Beanstalk. Jeg skulle arbejde meget med virksomheder, der startede med det her. Men i det øjeblik du gør noget, der går lidt ud over, hvad platformen tillader, bliver det til en frygtelig hovedpine. Fordi du begynder at støde ind i vægge, der er overalt. Og som folk plejer at gøre, når de støder på vægge, begynder de at lede efter en måde at skære igennem væggen.
Modern Cloud Native voksede derfra: hvordan man får det til at køre stadig i skyen, bruger nogle platformstjenester, men giver samtidig fantastisk fleksibilitet i alt, hvad der sker. Vi balancerer konstant mellem fleksibilitet og enkelhed. Fleksibilitet forårsager kompleksitet, og at forenkle og skabe en overskuelig platform medfører altid begrænsninger. Cloud Native handler tilsyneladende om at finde en form for balance mellem cloud-platformens begrænsninger og den fleksibilitet, som skyen tillader dig med sin automatiske skalering, og alt dette kommer med en pris.
Oleg: Sandsynligvis skal organisationen selv på en eller anden måde lære at leve processuelt med det hele.
Anton: Naturligvis, naturligt! Alt dette efterlader et aftryk. Microservices gælder også for dette. I det store og hele er det ideen om, at vi har små tjenester, små applikationer, der er spredt ud over skyen og kan placeres hvor som helst når som helst, og der kan være 10 replikaer nu, og i morgen - 1500, det er også en del af Cloud Native. Tanken om, at vi ikke er begrænset af datacentrets fysiske grænser. I det store hele er hele verden min sky, det er en helt vidunderlig vision, en vidunderlig aspiration, men den har en pris, og denne pris er kompleksitet, prisen er, at ingen i det store og hele kan passe ind i deres hoved hvad vil der ske, når vores applikation pludselig vokser fra 10 tilfælde til 1500. Ingen kan forestille sig dette, og alle skaleringsartefakter begynder at dukke op. Vi som mennesker, som operatører, kan ikke gøre andet ved det end at reagere på det kaos, der sker. Og så begynder vi at tænke: "Hvordan kan vi bygge vores applikation og vores infrastruktur på en sådan måde, at når disse artefakter opstår, for det første kan de forudses, og for det andet kan vi på en eller anden måde klare disse artefakter og fortsætte med at fungere?"
Blanding af tekniske og ikke-tekniske færdigheder
Oleg: Du har rapporter om tekniske ting, f.eks. og der er rapporter om ledelse, ledelse og alt det der. Er du generelt mere en teknisk person, eller er du leder, eller er din struktur på en eller anden måde anderledes?
Anton: På et tidspunkt begyndte jeg endda at skrive et indlæg om dette, men jeg er ikke færdig med det endnu. Jeg er lidt personligt splittet mellem disse to ting, for på den ene side kan jeg godt lide at forstå, hvordan tingene fungerer, jeg kan godt lide at finde ud af dem. Når det lykkes dig at løse et teknisk problem, giver det i sig selv blot en fantastisk følelse af dine evner, det der kaldes øjeblikkelig tilfredsstillelse, øjeblikkelig belønning, et dopaminrush: ”Åh, fedt, jeg kan gøre det, jeg har besluttet mig. ” Og det er svært at give op, det er svært at slippe af med det. Og da dette er der, fortsætter jeg med at lave tekniske ting. Nye teknologier begejstrer mig: det er fedt at grave i noget, at forstå noget. På grund af dette viser det sig, at da der er denne viden, vil folk gerne købe den, og jeg fortsætter med at sælge den.
På den anden side forstår jeg, at dette kun er en lille del af det store billede, jeg har arbejdet i branchen længe nok, og jeg kan ikke undgå at se, at teknologien kun er et hjørne af et større system, kun en af komponenterne . Jeg har ledet teams, og jeg forstår, hvor vigtigt det er at overveje, hvordan teknologier og værktøjer interagerer med de mennesker, der bruger dem. I sidste ende eksisterer informationsteknologi, faktisk enhver teknologi, som folk kan bruge. Og at skabe teknologier uden at tænke over, hvem der bruger dem, er fuldstændig meningsløst. Teknologien i sig selv er slet ikke interessant, medmindre du tænker på dens anvendelse, og applikationen er altid forbundet med mennesker, der på en eller anden måde har gavn af den. Og derfor interesserer alt omkring teknologi mig også rigtig meget. Jeg føler, at det er nødvendigt at tale om dette, jeg forstår, at uden det mister alt virkelig sin mening. Til det punkt, hvor jeg nogle gange nyder at sidde og hacke væk i to-tre dage, nogle gange uger. Jeg kan lade mig rive med af et eller andet problem, som jeg ikke kan løse, jeg kan løse det og få fantastiske fordele af det. Men så løfter jeg hovedet fra tastaturet, ser mig omkring, og jeg indser, at der sker noget omkring mig, som jeg på ingen måde kan ignorere. Og så bliver kode og fifleri med Linux fuldstændig uinteressant og ligegyldigt for mig, og jeg vil begynde at løse problemer på et andet niveau, på et menneskeligt plan.
Sådan forstår du hurtigt DevOps
Oleg: Hør her, har du nogle råd til folk, der i øjeblikket er engageret i at udvikle og lære DevOps-praksis på samme tid? Hvordan propper du det hele ind i dig selv og i hvilken rækkefølge? Hvordan kan du relativt set planlægge din karriere for at blive mere succesfuld på kort tid?
Anton: Eh... Nå, der er ingen universelle råd, igen, fra min egen erfaring. I ret lang tid, formentlig de første 10 år af min karriere, var jeg utilfreds med min plads. Jeg ledte efter det, jeg ikke kunne lide, fokuserede på det, ledte efter, hvad der ville være mere interessant for mig at gøre. Men i det store og hele gjorde han intet ved det. Det vigtigste råd er... På hvilket tidspunkt tror jeg, min karriere har taget fart? Det øjeblik, jeg begyndte at tale om ting, der interesserede mig. Området for teknisk viden, endda ikke kun teknisk viden, generelt er selve informationsteknologiområdet meget bredt, det vil sige, du kan være en tekniker: en udvikler, en tester, en integrator og en systemadministrator - det er alle forskellige ting, alle kan finde deres niche der. Vil du ikke være en komplet tekniker, er du interesseret i både tekniske og forretningsmæssige ting på samme tid? Bliv involveret i produkt- og projektarbejde. Der er mange nicher, find din niche, der vil være interessant for dig.
Der er meget snak i disse dage om T-formede fagfolk. Du skal forstå, hvor benet på din T er, vælge én ting og begynde at grave på dette sted. I det øjeblik du graver, vil fantastiske dybder blive afsløret. Men du kan grave hvor som helst. Og jeg er godt klar over, at der er mange områder, som jeg ikke har gravet dybt, fordi jeg prøvede at kigge og indså, at det ikke er noget for mig. Men hvor du er interesseret i at grave, så fortsæt med at grave, og her er det meget vigtigt at tale om det. Jeg mener igen, jeg forstår, at dette ikke er for alle. Men selv her har alle forskellige udtryksformer: For nogle kan det være velegnet at skrive blogs, men hvis du ikke kan skrive litterære og sjove blogs, skal du bare skrive tekniske blogs, udgive Gists på GitHub. Hvis du har løst et problem, så publicer det.
I det store og hele sker karriereudvikling i dag gennem deling. Der er en grund til, at videndeling er så vigtig en værdi i DevOps. Det har alle andre gavn af, og du selv har altid gavn af, hvis du deler ud af din viden. Enhver person, der har open source deres kode, ved udmærket, hvor meget du skal bruge for at finkæmme koden, hvordan du skal tænke anderledes i det øjeblik, du giver den til en anden, og du forstår, at en anden vil bruge den. De samme sociotekniske ting, som jeg talte om, spiller straks ind. Du begynder at tro, at dette ikke bare er kode, men kode, som en anden person vil læse, måske vil de ændre det, de bliver nødt til at forstå, hvad denne kode gør. Og når disse interaktioner opstår, begynder du allerede at interagere med andre mennesker i din hjerne. Og en persons karriere udvikler sig kun gennem interaktion med andre mennesker. I det store og hele, hvad er en karriere? En karriere betyder, at jeg bliver nyttig for flere mennesker, brugbar og tiltrængt. Jeg får viden, der er nødvendig og nyttig for flere. For at gøre dette skal du forstå, hvad disse mennesker ønsker, og hvad de har brug for. Sådan noget. Alt kommer altid ned til mennesker.
Oleg: Lad os sige, at vi er så seje, vi laver DevOps, alle mulige nye praksisser og så videre. Men der er dem, der ved og respekterer dette, og så er der alle andre. Og forestil dig, at du arbejder i et team i nogle, især i en stor virksomhed, og der er det stadig... lad os passe på, de er ikke særlig kendte og ikke særlig respekterede. Er der nogen måder at begynde at implementere alle disse ideer på? Hvis du ikke er leder. Det er klart, at hvis du er leder, kan du blot sige: "Vi implementerer det i morgen." Hvad sker der, hvis du er et almindeligt menneske, og du vil forbedre dig?
Anton: For det første er det ikke nødvendigt, at det virker, hvis du som chef siger: "Vi implementerer det i morgen." Folk vil udføre nogle opgaver, men det betyder ikke, at en dyb forståelse af, hvorfor det bliver implementeret, dukker op ud af ingenting. Og så er der ingen, der kan lide ændringer, især når de fortæller ham: "Du skal ændre dig."
Oleg: Og hvad skal man gøre?
Anton: Nå, se, jeg var på dette sted og var involveret i implementeringen af sådanne processer, faktisk nedefra, idet jeg bare var en teamarbejder, og så allerede en teamleder. Den eneste tilgang, der virker, er narkohandlerens tilgang. Det er det, jeg kalder "servicebaseret samarbejde", altså serviceorienteret samarbejde. I det store og hele ved du, at du har nogle mennesker omkring dig, som du kan opfatte som dine kunder. Vi gør noget, en anden bruger det. I det enkleste scenarie, som Agile engang talte om: her er jeg en udvikler, jeg har en klient, og derfor skal jeg forstå, hvad min klient vil have for effektivt at udvikle software.
I en stor virksomhed har jeg ofte ikke direkte interaktion med kunden, med brugeren. Men der er mennesker omkring mig. For eksempel skriver jeg et bibliotek - andre mennesker integrerer med det, jeg skriver en form for backend - jeg har frontend-udviklere, der skal tale med det, jeg skriver kode - jeg har testere, der enten skriver tests for mig, eller, igen giver jeg dem versioner, så de har noget at teste. Og i det store og hele skal du bare tænke: ”Her er jeg en serviceudbyder, jeg har kunder. Alt fungerer bedst, hvis jeg gør mine kunder glade. Det vil sige, at hvis mine kunder er glade, så bliver jeg glad. Tilsyneladende vil jeg for det første tjene et vist ry for mig selv, jeg vil tjene en god holdning, jeg vil modtage positiv feedback." Og vender jeg tilbage til narkohandlertilgangen, vil jeg have, at disse klienter vender tilbage til mig for mere af det samme.
Altså hvis jeg synes, at en eller anden tilgang er korrekt, for eksempel kontinuerlig integration med tests... Der er programmører, som i dag f.eks. har svært ved at teste deres arbejde. Vi skal sørge for, at de egentlig ikke skal tænke for meget over det, så de får de kontroller så nemt som muligt. I dag ser det ret trivielt ud, for 10 år siden var det slet ikke trivielt: i det øjeblik, hvor jeg skubbede min kode, så alt automatisk ville blive bygget et sted, installeret, og kun hvis der var en fejl, ville jeg modtage en besked, i mellemtiden kunne jeg roligt gå og drikke kaffe og ikke tænke på, at jeg nu skal køre kompileringen på min computer, så jeg har alle de nødvendige værktøjer, for det er også en hovedpine. Det vil sige, at hvis man mindsker mængden af hovedpine, bliver folk hooked på det. Vi ser det alle sammen: I det øjeblik du har en velfungerende pipeline, kan alle, der bruger den, meget hurtigt ikke længere forestille sig livet uden den. Hvis jeg vil ændre noget, er jeg nødt til at skabe en proces, hvorfra folk vil have en vis følelsesmæssig afhængighed.
Oleg: Bøde. Mange mennesker håber, at en konge, en stor leder eller noget andet vil komme og fortælle dem, hvordan de skal leve, og bagefter vil alle selvfølgelig flytte ind i en modig ny verden med DevOps eller noget andet. Er sådan en konge nødvendig?
Anton: Nej, en konge, der vil fortælle dig, hvordan du skal leve, er bestemt ikke nødvendig. En chef, der er villig til at lytte til sine medarbejdere, villig til at stole på dem og villig til at støtte dem i at udføre arbejdet på den måde, der føles mest behageligt og rigtigt for dem? Ja, sådan en person er nødvendig, for uden den bliver det bare en kamp. Og de underordnedes kamp mod deres overordnede ender ikke med noget godt. Som et resultat vil det helt sikkert ende galt for én person, enten for chefen eller for de underordnede.
Men problemet er, at det er meget svært at fortælle folk, hvad de skal gøre, og hvad de ikke skal gøre. De ender med at gøre, hvad deres kulturelle baggrund, ego eller øjeblikkelige følelsesmæssige tilstand får dem til at gøre.
De mest nyttige praksisser og teknologier fra DevOps-verdenen
Oleg: Forresten, nu prædikes et stort antal af alle slags praksisser: Der er tilgange fra Google, der er tilgange fra Netflix, fra alle mulige talere fra konferencer. Fortæl mig, hvilke fremgangsmåder finder du mest nyttige?
Anton: Problemet med de fleste organisationer, uanset hvor store eller små (startups lider mere af dette), er, at de ikke har processynlighed – en forståelse af, hvordan vi generelt arbejder, hvordan vi leverer software, hvor tingene hænger fast. Jeg plejer at foreslå en øvelse, der kommer fra lean management-tilgangen – kaldet value stream mapping. Kortlægning af flowet af leveret værdi. Dette kræver en vis vilje til at samle hovedaktørerne i organisationen i ét rum, alle de mennesker, der på en eller anden måde er involveret i leveringsprocessen: dem, der bestemmer de nødvendige ændringer, produkter, projekter, udviklere, testere, systemadministratorer, endda sælgere. der arbejder med kunder. Tag dem alle sammen og forstå, hvordan en ændring sker i software, hvilken vej den normalt tager.
Dette virker ret trivielt: hvad er der? Nogen fandt på det, nogen kodede det, vi har en pipeline, det løb og rullede ud. Nå, ja, vi ved, at vores byggeri her tager meget tid, ja, det bestemmer vi. Nå, ja, vi ved, at programmører nu ikke kan kompilere på deres computere, fordi de har Java, det kræver meget hukommelse, det ved vi også om, det bestemmer vi. Og jeg kommer ofte til organisationer, siger de:
— Det er her, vi skal automatisere det her, løse det her.
— Er du sikker på, at det er det, du skal starte med? Hvordan ved du det?
- Altså, vi ved det ikke med sikkerhed, men vi føler, at det gør ondt der.
Der er , som siger, at det stort set ikke løser noget, at løse problemet et hvilket som helst sted, der ikke er en begrænsning, det vil kun komplicere problemet. Hvad mange mangler, er konceptet om, hvor tingene sætter sig fast, og hvordan de flyder.
Nogle gange samler man lige pludselig forskellige mennesker, siger en:
— Her i øjeblikket går udgivelsen dertil for godkendelse.
Og den anden siger:
- Nej, sådan er det ikke hos os, det virker ikke for os. Her venter vi på miljøet til belastningstest.
Eller for eksempel siger testere:
- Her på det her sted plejer vi at gøre det hele med hænderne.
Og programmørerne fortæller dem:
- Jamen, vi har en automatiseret proces til det her. Hvorfor bruger du det ikke?
Og testere siger:
- Vi vidste ikke, hvad det var.
Hvert team ser kun sin egen brik, og ingen ser hele billedet - det er det, der ofte påvirker vores evne til effektivt at udrulle software meget mere end tilstedeværelsen eller fraværet af et værktøj. Det er disse ting. Det er værd at starte med proceskortlægning. Det er klart, at hvis en virksomhed i øjeblikket ikke har nogen CI/CD, er det allerede en saga blot. Det er klart, at dette også skal bygges. Men det er værd først at besvare spørgsmålet om, hvor meget man skal investere i det, hvilke problemer det vil løse. Dette kræver også folk, der forstår, hvordan man gør det korrekt.
Oleg: Fra et teknisk synspunkt, hvilke teknologier er værd at være opmærksomme på? Det er klart, at vi ikke længere kan tale om simpel CI/CD. Hvilke seje nye teknologier er værd at tjekke ud?
Anton: For det første er det helt åbenlyst for enhver, at containere har vundet. Og derfor, hvis nogen endnu ikke laver containere, skal du helt sikkert se på dem og se på dem så hurtigt som muligt, for bevægelsen går i denne retning, og store virksomheder forstår allerede, at de skal pakke deres software ind i containere . Nå, på platformsniveau vandt Kubernetes: det er lige meget, om det er i skyen eller ej - vi vil udrulle en boks med Kubernetes til kunderne. Nu har VMware annonceret, at de vil have Kubernetes direkte på hypervisoren. Alt er klart, Google vandt. Hvilket generelt ikke kom som en overraskelse for nogen.
Oleg: Google vandt?
Anton: Nå, hvis vi ser tilbage for blot et par år siden, var det stadig ikke særlig klart, om Swarm eller Kubernetes ville blive dræbt, og om Docker ville blive dræbt. Docker er blevet dræbt, helt åbenlyst. Det vil sige, alle kom ind sammen, og Microsoft og Amazon hjalp også - "lad os alle dræbe Docker sammen." Dræbte Docker! Men i det store og hele var Docker selv skylden. Forventede de, at de ville komme, bryde mønsteret for alle, ikke ville sælge ud til nogen og besejre alle på én gang og straks overvælde Google, Microsoft og Amazon? Der var meget lille chance for, at dette ville ske. De kunne tilsyneladende ikke finde nogen at blive venner med. Når du ikke bliver venner med nogen, ender du med at blive dumpet. Og så skete det.
Så her er det. Derfor skal du kigge på beholderne. Containere og orkestrering er langsomt ved at blive almindelig i dag. Det vil sige, at nu er rapporterne på konferencer "Det er aldrig for sent at starte med Kubernetes, selvom du er pensionist." Så det er nødvendigt. Og der begynder nu at ske en masse interessante ting omkring Kubernetes. Fordi en af de fede funktioner ved Kubernetes i det store og hele er skabelsen af en form for universel API, der giver os mulighed for at beskrive alt, hvad der sker i vores infrastruktur. I løbet af det seneste år har vi set forsøg på at omslutte en masse andre ting omkring denne API. Her er servicesien - et af disse forsøg, næsten alle implementeringer af servicesien der findes nu, siger de på en måde: "Her vil vi udvide API'en, vi vil tilføje intelligens, vi vil beskrive objekter uden for Kubernetes, men vi vil læse objekter fra Kubernetes og så videre."
Et andet sådant eksempel er, hvad der sker nu med Continuous Delivery Foundation, som blev organiseret for omkring halvandet år siden, igen, dette er Google, det er CloudBees, GitLab. Der er et Google-projekt Tekton, dets hovedidé er oprettelsen af en slags universel API til at beskrive den kontinuerlige leveringsproces. I det store og hele forsøger de at bryde det hele ned i bestemte objekter, der skal være til stede i det kontinuerlige integration/kontinuerlige leveringssystem og på en eller anden måde gøre det muligt at skrive disse ting ind i Kubernetes, så der senere kan komme alle mulige forskellige komponenter, der kan læse disse definitioner og løse, hvad de skal gøre med dem. De samme ting sker med servicesien, jeg talte om dette i min . Microsoft forsøger nu at lave en spec af, hvad servicesien skal gøre, den såkaldte SMI Spec. Med tanken om, at enhver implementering af servicesien vil være i stand til at udføre alt, hvad der er skrevet i denne spec plus noget andet.
Derfor vandt Kubernetes. I det øjeblik, hvor du bliver en platform for yderligere innovation, er det meget svært at smide dig ud et sted senere, fordi det allerede er vokset på det, nu at smide Kubernetes er at smide barnet ud med badevandet.
Hvilke rapporter er værd at deltage i?
Oleg: Hvilke rapporter går du selv til, hvad finder du interessant?
Anton: For det første, hvis der er en eller anden ny teknologisk feature, en gadget, som jeg simpelthen ikke selv har haft tid til at se, og der er en taler, der kan tale tydeligt om det, så synes jeg, at det generelt er en vild fordel, for i stedet for læs nu, og grav, og måske, med svært ved at forstå, kan du komme og lytte om en halv time, som en person viser dig, fortæller dig. Igen kræver dette en vis dygtighed og lyst til at kunne tale om teknologi. Og jeg forstår, at dette heller ikke kommer fra ingenting, du skal arbejde på det. Det tog mig også lang tid. Det, at jeg beskæftiger mig med teknisk undervisning, hjalp mig i øvrigt meget med dette. Når du har en klasse foran dig, skal du forklare noget til folk, og du indser, at uanset hvordan du forklarer, så er de dumme - så indser du, at problemet tilsyneladende ligger i, hvordan du forklarer, og ikke i det faktum, at folk er dumme.
Oleg: Hvilken slags teknisk undervisning? Hvad laver du?
Anton: Jeg har undervist i rent tekniske discipliner i omkring 7-8 år nu. Det startede med, at jeg lærte ting som Maven og shell-scripting i et år. Da jeg arbejdede meget tæt sammen med Jenkins og vidste det dybt, lærte jeg folk at arbejde med Jenkins og administration. I de seneste år - alt relateret til cloud native: Kubernetes, containere og alt omkring det. Jeg tager snart til London for at lave en masterclass på Istio. Dette er ikke hoveddelen af min aktivitet, men cirka en gang hver måned eller to afholder jeg mesterklasser.
Oleg: Går du primært efter rapporten, emnet eller personen?
Anton: Hvis jeg ved, at taleren er god, så går jeg til personen, simpelthen fordi det stadig er meget vigtigt for mig at lære af andre mennesker, hvordan man taler godt. Læring er altid vigtigt. Hvis der er et emne, men jeg ikke kender taleren, så går jeg og ser det, men det er det samme som normalt, som at gå til stand-up: Jeg så de første 10-15 minutter, gjorde' t lide det, og gik. Eller der er talere, som jeg virkelig vil gå til alligevel, fordi de altid fortæller interessante ting, de ved endda hvordan man viser ting, som du kender fra deres egen vinkel, det er enkelt og for dig vender det hele sagen fra en ny vinkel . Af dem, som jeg kan lide på det seneste... For det første er der Simon Wardley - en konsulent, han har sit eget trick med at tegne kort, han bruger kort til at forklare, hvordan virksomheder kan bygge deres strategi korrekt, han var engang en slags... så er der en CTO, CEO for startups, han taler meget om det her, om teknologi. I øvrigt kæmper han konstant for serverløs og siger, at dem, der ikke gør serverløse i dag, har store problemer.
Oleg: Dette er kammeraten, der ? Han lavede det i form af indlæg. Usædvanligt format.
Anton: Han taler virkelig på en meget sjov måde. Jeg husker mest af alt hans foredrag gennem de sidste 2-3 år. Nå, her er John Willis, der kom til DevOops sidste år – simpelthen fordi han . Der er et eller andet problem med ham, for han taler meget om den amerikanske virkelighed, ting som nogle gange simpelthen ikke gælder for hverken russisk eller israelsk virkelighed. Nu har de en slags krig med nogle ændringsgodkendelsestavler, som de konstant snakker om. Dette er tilsyneladende noget, der findes i amerikanske virksomheder.
Oleg: Men det har vi ikke - jeg forstår ikke engang, hvad du taler om nu.
Anton: Jeg forstår heller ikke rigtigt; dette sker heller ikke i Israel. Og der snakker de om det. Hvis du lytter til alle disse kammerater, som DORA, hvem , det skriver de også meget om. Generelt mener jeg, at folk taler om et eller andet problem, som kun de har, og det er overhovedet ikke interessant for dig.
Oleg: Du var til de tidligere DevOops, hvilke foredrag er værd at gå til og gennemgå optagelserne?
Anton: se . Jeg er lidt interesseret i emnet - gå.
Oleg: Der er noget Anton Weiss der, tror jeg. Det er nok et kig værd.
Anton: Nej, gå ikke efter det her, det er lidt kedeligt :)
Oleg: Okay, mange tak. Det var fedt! Jeg kan se, at du allerede har indsendt et papir til næste konference, så vi ses til næste DevOops!
Конференция afholdes den 29.-30. april, denne gang i Moskva. Vi beskrev essensen af konferencen om Habré i meddelelsen . Programmet er aktivt ved at blive dannet (der er stadig mange måneder til konferencen), men de første talere har allerede . Der kan du .
Kilde: www.habr.com
