Når det gjelder programvareutvikling, har den moderne praksisen med devops - der utviklere og IT-operasjoner kombinerer for å levere programvare på en mer strømlinjeformet måte - feiet seg gjennom virksomheten, ettersom flere og flere organisasjoner ser fordelene med større automatisering og mer hyppige utgivelser.
Nå, med pandemien som fremhever behovet for større digital smidighet, vil adopsjon av devops akselerere enda raskere?
Når London-utgaven av Enterprise Devops Summit nærmer seg (i sitt nye virtuelle format), var det det første spørsmålet vi stilte verten og grunnleggeren, Gene Kim, den tidligere CTO i Tripwire og forfatteren av tre populære devops-bøker.
Samtalen nedenfor er redigert for klarhet og kortfattethet.
: Hvordan har pandemien i stor grad påvirket devops?
Gene Kim: Det er et meme som går rundt på Twitter akkurat nå om hvilken leder på C-nivå som har avansert den digitale forstyrrelsesagendaen mest? Er det administrerende direktør, økonomidirektør, CIO eller COVID-19? COVID-19 er vinneren. Jeg tror det er så sant.
Digital forstyrrelse var på nesten alle styrets agendaer i fjor. Nå har COVID-19 presset den videre i tre til fem år. Jeg tror det som har vært så interessant, er at det er så mange historier om heroikkene som organisasjoner må gjøre for å gjøre titusenvis, hundretusenvis av arbeidere i stand til å jobbe hjemmefra. Det var bare mulig ved å i det vesentlige bryte alle reglene.
Det viser IT og forretningsledelse hva som er mulig og hva disse teamene faktisk er i stand til. Så ofte blir de bundet, og de fleste vil si at alt som ble gjort for å gjøre det mulig for folk å jobbe hjemmefra - noen som aldri har jobbet hjemmefra før, som back office office-team - det var bare et lite mirakel.
: Den siste State of Devops-rapporten viste denne enorme mellomgrunnen for organisasjoner når det gjelder devops modenhet.
Tror du at pandemien vil skyve midtveien inn i det mer modne rommet, eller tror du det er vanskelig å gjenoppbygge måten team fungerer når alle er fjerntliggende?
Kim: Jeg tror ikke det kommer til å være en hindring, det faktum at det er fjernt. Vi vet at det er mulig. En av mine største overraskelser på reisen min var å lære at GitHub tidlig på 2010-tallet, alt infrastrukturteamet, var fjerntliggende. Så det var ingen to ops-ingeniører i samme by, noen gang i de første dagene.
I løpet av fem år med å gjøre State of Devops-rapporten har vi funnet ut at industrien ikke hadde noe å si. Det spilte ingen rolle om du er i helsetjenester, detaljhandel, uansett. Sannsynligheten for å være en høy eller middels eller lav utøver var i utgangspunktet den samme, uavhengig av bransje.
Det endret seg i fjor, det var detaljhandel som faktisk var mer sannsynlig å være en høy ytelse. Jeg tror det viser at retailpocalypse, eller en eksistensiell trussel, presser detaljhandelsnæringen til å tilpasse devops praksis raskere. Jeg tror resultatene er at COVID-19 kommer til å presse alle bransjer til å adoptere devops raskere, bare på grunn av alt forretningspresset vi nettopp snakket om.
: Hvordan føler du deg om fremveksten av DevSecOps og annen ny terminologi rundt devops?
Kim: Dette er et argument som jeg hadde da Devops Handbook kom ut i 2016, med min medforfatter, John Willis. Han hadde en veldig visceral reaksjon på at det bare er en devops. Det er ikke det at han ikke tror på det, men det han overbeviste meg om var at vi på det tidspunktet i bransjen trengte en paraply for å sette alt i. Jeg elsker ideen til DevSecOps, eller noen måte å utvide paraplyen og bringe andre stammer inn. Jeg elsker devops som denne måten å signalisere at alt som ikke er devops, bør vi assosiere med de gamle, dårlige måtene å gjøre ting på.
: Hva med AIops?
Kim: Ja, AIops, MLops, jeg elsker den setningen, men jeg ser et smalt syn på at det nesten ikke er noen verdistrøm som ikke kan gjøres bedre ved å bruke dataene som den verdien genererer. Enten det er markedsføring for spådommer fra kunder, eller feilanalyse og spådommer for infrastruktur.
Problemet der er at når du har disse maskinlæringsprosjektene på $ 50 millioner, utført av fagfolk som ikke er programvare, bruker de ikke versjonskontroll eller de beste teknikkene vi har utviklet de siste 30 årene. Hele måten å generere treningssett og disse nye produksjonsmodellene på, er teknikkene forskjellige enn det vi som programvareingeniører bruker.
Microsoft holdt et foredrag om hvordan de bruker MLops for å integrere disse dataforskerne i teknologiverdistrømmer. John Deere holdt en presentasjon om hvordan de gjør det for en rekke initiativer.
Problemet er at du ofte har disse modellene som er prototypet i Python eller SPSS, noe som er bra, men de er ikke produksjonsklare. Så det trengs noe annet for å sikre at oppdraget faktisk blir servert. AI skaper dette helt andre problemet for å skape produksjonstjenester. Det er et virkelig rikt felt som definitivt må adresseres.
: Hva er de største gjenværende flaskehalsene for organisasjoner som anvender devops-praksis? Og er det en alternativ rute?
Kim: Jeg tror devops er ubønnhørlig, uunngåelig. Jeg vil si at den største hindringen er ledelse og kjøp av virksomheter. Når jeg ser på de siste syv årene av konferansen, er en av de tingene som virkelig skiller seg ut, at folk som holder presentasjonene er mer eldre hvert år.
I år har vi Patrick Eldridge, Chief Operating Officer for Nationwide Building Society. Vi har en rekke administrerende direktører og CTOer, og ofte presenterer de sammen med sin forretningsmotpart, personen med resultat- og tapansvaret for disse virksomhetene. Jeg tror det viser at devops faktisk ikke er et teknologiproblem, det er et forretningsproblem. Dette er samtalene som viser i hvilken grad devops er integrert i alle aspekter av strategi og operasjoner.
Ta Nationwide, de ansetter noe som 1200 mennesker, når mye av bransjen krymper. Jeg tror dette bare viser hvilket sterkt signal som devops ikke bare lar organisasjoner overleve på markedet, men trives i et miljø der de vokser mens andre krymper.
: Hvordan påvirker fremveksten av containere devops praksis?
Kim: Alle disse teknologiene - containere som sannsynligvis er de sterkeste - tvang virkelig folk til å tenke på uforanderlig infrastruktur eller infrastruktur som kode. Jeg vet ikke hvilken vei kausaliteten går, enten folk som tenker på en devops måte, hvor de allerede tenker på infrastruktur som kode, sannsynligvis henter ting som containere mye raskere, eller kanskje verdiproposisjonen til containere er så høy at det suger folk inn.
Hvem kan gå tilbake til den gamle måten å prøve å finne ut hvordan du får laptop-miljøet ditt til å se ut som produksjonsmiljøet? Så alle disse tingene gjør det så klart at det er en bedre måte å jobbe på. Jeg synes det er veldig vanskelig å slå tilbake når du har gjort ting som kontinuerlig integrering, som kontinuerlig levering. Når du har opplevd det, er det veldig vanskelig å gå tilbake til den gamle måten å gjøre ting på.
Jeg tror Edgar Schein sa "verktøy er en kulturell gjenstand," i antropologi og sosiologi. Så verktøy endrer måten du tenker på og endrer måten du jobber på. Så jeg er enig i påstanden din om at disse verktøyene definitivt fremskynder en devops måte å jobbe på.
: Hvorfor har det vært så vanskelig å integrere sikkerhet i devops fram til nå?
Kim: Hvis vi hadde denne samtalen for åtte år siden, tror jeg vi vil spørre ‘hvorfor er det vanskelig å få operasjoner om bord?’ Er det fordi de er redd for at jobbene deres skal forsvinne?
Noen mennesker snakker om NoOps, der vi ikke trenger operasjoner lenger, når jeg synes det er ganske klart for alle som har brukt Kubernetes, vet at ingen utviklere ønsker å lære Kubernetes, vi vil at infrastrukturfolk skal gjøre det for oss. Jeg tror det samme gjelder sikkerhet. Det vi ønsker er at produktteamene og utviklingsteamene skal være fullstendig ansvarlige for tilgjengeligheten, driften og sikkerheten. Vi vil ikke at utviklere må bli eksperter på nivå med alle kroker og kroker som sikkerhetsproblemer kan gjemme seg i.
Vi ønsker virkelig å utnytte spesialistkunnskapene til sikkerhet, enten bringe dem inn i teamene eller utnytte plattformer de bygger, slik at alt vi skriver på plattformen er fundamentalt sikrere. Jeg tror den dagen kommer. I likhet med operasjoner er skillet så høyt med utviklere, den naturlige reaksjonen er 'over min døde kropp', og jeg er sikker på at det kan ordnes.
: Hvordan har ferdigheten til en devops engineer utviklet seg?
Kim: En av de viktigste ferdighetene, evnene og egenskapene som trengs i disse banebrytende opprørene - ved hjelp av devops for å styrte den eldgamle mektige ordenen, som er veldig glade for å gjøre ting slik de har gjort i 30 til 40 år - er tverrfunksjonelle ferdigheter til være i stand til å nå over bordet til sine kolleger og hjelpe til med å løse problemer. Det er slik disse lagene vokser og ansetter når så mange andre lag krymper.
En av fellesnevnerne blant samtalene jeg har hørt så langt i år, er at de alle ansetter. Jeg tror devops mennesker har så mye å gjøre for dem, og jo mer de kan finne disse initiativene, og forretningsfolk som trenger dem, fremtiden er veldig lys.
En venn av meg, Tom Limoncelli, som skrev boka om skysystemadministrasjon - han sa det for drift, men jeg tror det kan brukes overalt - er at vi er i en gaffel i veien: Nedover en vei blir lønnen vår halvert og den eneste jobben vi kan finne er på Genius Bar i Apple Store. Nedover den andre veien dobles lønnen vår, fordi vi har de hotteste ferdighetene på markedet. Jeg syntes det var strålende.
