Forfatterne av Puppets siste bransjevide DevOps-undersøkelse har litt råd til DevOps-forkjempere: slutt å kalle det “DevOps.” Det skaper bare forvirring. Og ikke engang komme i gang med DevSecOps. De gir også en ny interessert godbit av nyheter: en godt designet IT-arkitektur kan bidra til å løse bedriftskulturelle problemer.
Foto: Joe McKendrick
Det er ordet fra Puppets State of DevOps -rapport fra 2021, som inkluderer erfaringene fra 2650 fagfolk innen IT, utvikling og informasjonssikkerhet. Det er ikke det at DevOps går ned i popularitet – 83% implementerer DevOps, og mange ser fordeler, inkludert raskere levering av kvalitetsprogramvare.
“Vi tror sterkt på at tilstedeværelsen av” DevOps -team “er forvirrende for industrien og mange organisasjoner, og i de fleste tilfeller hjelper det ikke organisasjoner å utvikle seg,” sa forfatterne av undersøkelsesrapporten, ledet av Nigel Kersten, CTO of Puppet og Kate McCarthy , rektor ved ClearPath Strategies, stat. “Vår erfaring er at det er langt mer sannsynlig at organisasjoner som har mindre tvetydige lagnavn, med et mer klart definert ansvar, har en IT -funksjon som fungerer bedre.”
DevOps-funksjoner belastes vanligvis med en rekke ansvarsområder, inkludert følgende identifisert gjennom undersøkelsessvarendes selvbeskrivelser av teamene sine:
Tradisjonell infrastruktur & amp; drift Systemadministrasjon End-to-end produktansvar Støtte for utviklingsteam med en kombinasjon av utgivelsesautomatisering, distribusjonsrørledninger og verktøy Bygging av de vanskelige tingene som applikasjonsutviklere ikke ønsker eller trenger å bry seg om: infrastruktur, containervarer, overvåking og beregninger. muliggjøre DevOps -praksis på tvers av en organisasjon
“Manglende klarhet rundt teamidentiteter skaper betydelig organisatorisk friksjon, noe som hindrer programvarelevering på en rekke forskjellige måter,” sier Kersten og McCarthy. “Vi foreslår at organisasjoner går bort fra bruk av” DevOps “-team mot tydeligere lagnavn, og spesielt at bruk av strømjusterte
og plattformteam er en veldefinert vei for å oppnå DevOps-suksess i stor skala.”
Med andre ord kan DevOps være mekanismen for hvordan lagens mål oppnås, men er ikke et mål i seg selv. Og sikkerhet bør bygges inn i denne innsatsen fra starten – ikke en egen “DevSecOps” -innsats.
Dukketeamet så også på et mindre segment, det de kaller “høyt utviklede firmaer” som har sett større suksess med DevOps -tilnærminger, for å spore hva de gjør annerledes enn sine jevnaldrende. Til å begynne med bruker de en plattformstilnærming, “slik at utviklere får tilgang til autentisering (62 prosent), containerorkestrering (60%) og service-til-tjeneste-godkjenning (53%), sporing og observerbarhet (49%) og loggforespørsel (47%) tjenester via selvbetjening. ” Dette ble oppnådd “ved å forstå deres interne kunder og tilby et kuratert sett med teknologier for infrastruktur og utviklingsmuligheter på plattformen.”
Team ser også annerledes ut i høyt utviklede selskaper, observerer Puppet -teamet. De bruker “en kombinasjon av strømjusterte lag og plattformteam som den mest effektive måten å håndtere lagets kognitive belastning i stor skala, og de har et lite antall lagtyper hvis rolle og ansvar er klart forstått av de tilstøtende teamene.” Fortellende rapporterer 91% av høyt utviklede team en klar forståelse av ansvaret sitt til andre lag, sammenlignet med bare 46% av lavutviklede lag. I tillegg rapporterer 89% av høyt utviklede team at medlemmer av sitt eget team har klare roller, planer og mål for arbeidet sitt, sammenlignet med bare 46% av lavutviklede lag.
Høyutviklede lag bekymrer seg mindre om bedriftskulturelle spørsmål som har en tendens til å hindre DevOps -innsatsen. Det er ikke at de er mindre bekymret for kultur, men de har snarere laget en teknologibunke som gjør at arbeidsflyter og informasjon kan skaleres og raskt bevege seg dit det er nødvendig, en som “utnytter betydelig automatisering og investerer i interne plattformer, Kersten og McCarthy sier. Kort sagt, for høyt utviklede firmaer er kultur ikke lenger en barriere. “
For eksempel viser undersøkelsen at 84% av høyt utviklede selskaper elastisk kan levere og frigjøre evner – i noen tilfeller automatisk – for å skalere raskt utover og innover i forhold til etterspørselen. Bare 17% av lavutviklingsbedriftene kan skalere elastisk, rapporterer undersøkelsen. På samme måte kan utviklere på 79% av de høyt utviklede firmaene tilby databehandlingsmuligheter, for eksempel servertid og nettverkslagring, etter behov automatisk – mot bare 16% av firmaene på det laveste nivået av DevOps -evolusjon.
Relaterte emner:
Samarbeid CXO Thought Leadership Innovation Tech and Work 