De auteurs van Puppets nieuwste branchebrede DevOps-enquête hebben een advies voor voorstanders van DevOps: stop ermee het “DevOps” te noemen. Het schept alleen maar verwarring. En begin niet eens aan DevSecOps. Ze brengen ook nog een interessant nieuwtje: een goed ontworpen IT-architectuur kan helpen bij het oplossen van culturele bedrijfsproblemen.
Foto: Joe McKendrick
Dat is het woord uit het State of DevOps Report 2021 van Puppet, dat de ervaringen van 2.650 IT-, ontwikkelings- en informatiebeveiligingsprofessionals bevat. Het is niet zo dat DevOps steeds populairder wordt — 83% implementeert DevOps en velen zien voordelen, waaronder een snellere levering van kwaliteitssoftware.
“We zijn er sterk van overtuigd dat de aanwezigheid van 'DevOps-teams' verwarrend is voor de industrie en veel organisaties, en in de meeste gevallen organisaties niet helpt evolueren”, aldus de auteurs van het onderzoeksrapport, onder leiding van Nigel Kersten, CTO van Puppet, en Kate McCarthy. , directeur bij ClearPath Strategies, staat. “Onze ervaring is dat organisaties met minder dubbelzinnige teamnamen, met duidelijker omschreven verantwoordelijkheden, veel meer kans hebben op een beter presterende IT-functie.”
DevOps-functies zijn doorgaans belast met een reeks verantwoordelijkheden, waaronder de volgende die worden geïdentificeerd door middel van zelfbeschrijvingen van hun teams door respondenten:
Traditionele infrastructuur & operationsSysteembeheerEnd-to-end productverantwoordelijkhedenOndersteuning van ontwikkelteams met een combinatie van release-automatisering, implementatiepijplijnen en toolingHet bouwen van de lastige dingen waar applicatieontwikkelaars niet om willen of moeten geven: infrastructuur, containerfabrics, monitoring en metrics.Bemoedigend en DevOps-praktijken in een organisatie mogelijk maken
“Gebrek aan duidelijkheid over teamidentiteiten leidt tot aanzienlijke wrijvingen in de organisatie, waardoor de levering van software op verschillende manieren wordt belemmerd”, adviseren Kersten en McCarthy. “We stellen voor dat organisaties afstappen van het gebruik van 'DevOps'-teams naar duidelijkere teamnamen, en in het bijzonder dat het gebruik van gestroomlijnde
en platformteams een duidelijk omschreven pad is om DevOps-succes op grote schaal te bereiken.”
Met andere woorden, DevOps kan het mechanisme zijn waarmee teamdoelen worden bereikt, maar is geen doel op zich. En beveiliging moet vanaf het begin in deze inspanningen worden ingebouwd – niet een afzonderlijke “DevSecOps” -inspanning.
Het Puppet-team keek ook naar een kleiner segment, wat ze 'hoogontwikkelde bedrijven' noemen die meer succes hebben geboekt met DevOps-benaderingen, om te volgen wat ze anders doen dan hun achterblijvende collega's. Om te beginnen nemen ze een platformaanpak, “waardoor ontwikkelaars toegang krijgen tot authenticatie (62 procent), containerorkestratie (60%) en service-to-service-authenticatie (53%), tracering en observatie (49%) en logboekverzoeken (47%) diensten via zelfbediening.” Dit werd bereikt “door hun interne klanten te begrijpen en een samengestelde reeks technologieën voor infrastructuur en ontwikkelingsmogelijkheden op hun platform aan te bieden.”
Teams zien er ook anders uit in hoogontwikkelde bedrijven, constateert het Puppet-team. Ze gebruiken “een combinatie van gestroomlijnde teams en platformteams als de meest effectieve manier om de cognitieve belasting van het team op grote schaal te beheren, en ze hebben een klein aantal teamtypen waarvan de rol en verantwoordelijkheden duidelijk worden begrepen door hun aangrenzende teams.” Het is veelzeggend dat 91% van de sterk ontwikkelde teams een duidelijk begrip van hun verantwoordelijkheden aan andere teams rapporteert, vergeleken met slechts 46% van de teams met een lage evolutie. Bovendien geeft 89% van de hoogontwikkelde teams aan dat leden van hun eigen team duidelijke rollen, plannen en doelen hebben voor hun werk, vergeleken met slechts 46% van de teams met een lage evolutie.
Hoogontwikkelde teams maken zich minder zorgen over bedrijfscultuurkwesties die DevOps-inspanningen in de weg staan. Het is niet zo dat ze zich minder zorgen maken over cultuur, maar ze hebben eerder een technologiestack gecreëerd waarmee workflows en informatie kunnen worden opgeschaald en snel kunnen worden verplaatst naar waar het nodig is, een die “aanzienlijke automatisering benut en investeert in interne platforms, Kersten en McCarthy stellen. Kortom, voor hoogontwikkelde bedrijven is cultuur niet langer een barrière.”
Uit het onderzoek blijkt bijvoorbeeld dat 84% van de hoogontwikkelde bedrijven capaciteiten elastisch kan leveren en vrijgeven – in sommige gevallen automatisch – om snel naar buiten en naar binnen te schalen in overeenstemming met de vraag. Slechts 17% van de bedrijven met een lage evolutie kan elastisch schalen, meldt de enquête. Evenzo kunnen ontwikkelaars bij 79% van de hoogontwikkelde bedrijven computermogelijkheden, zoals servertijd en netwerkopslag, indien nodig automatisch leveren, tegenover slechts 16% van de bedrijven op het laagste niveau van DevOps-evolutie.
Verwante onderwerpen:
Samenwerking CXO Thought Leadership Innovatie Technologie en werk 