)
Dev-ops isn’t a destination, it’s a journey. That’s the philosophical take from the “2018 State of DevOps Report,” complied from some 30,000 people who work in the industry by Puppet and Splunk.
Why put out this report now? The authors hope to put up road signs for all the travelers on the road who’ve lost their way. “We’ve seen far too many teams whose dev-ops journeys began eight or nine years ago and who have experienced many starts and stops along the way. These teams tell us they feel they’re still at the beginning of their journey and wonder why they haven’t made more progress.”
To that end, they’ve developed the five (well, six if you count “foundation”) stages of a successful dev-ops journey: Normalize the technology stack, standardize and reduce variability, expand dev-0ps practices, automate infrastructure delivery and provide self-service capabilities.
Some of the less obvious nuggets from the report:
Successful teams contribute improvements to tooling provided by other teams
“The ability to contribute improvements to tooling provided by other teams stands out as a key foundational capability,” say authors on page 34 in the “Foundation” chapter. “As organizations expanded their DevOps practices, 44 percent of the highly evolved cohort reported that teams could always contribute improvements to other teams’ tooling compared to fewer than 1 percent of the least-evolved cohort. In other words, the highly evolved cohort is 44 times more likely to employ this practice.”
The revolution starts with simplification
“Starting a dev-ops evolution by reducing complexity may surprise people who think of automation as the first step in dev-ops, especially since automation is a core pillar of the movement.” That’s taking the wrong tack, say the report authors. “We have seen organizations start with Stage 4 automation, without having been through normalization, standardization and expansion (Stages 1-3). These organizations do not achieve success, and we believe it’s because they lack a foundation of collaboration and sharing across team boundaries.”
Service changes can be made during business hours
As your team continues to expand dev-ops practices — and succeed with them— the constraints imposed by red tape and bureaucratic process should be reducing, the report says on page 60, the chapter devoted to stage four, Automation. You still need a roadmap: define what business hours mean. You may need to be always on (i.e. a web service) and customers both internal and external will expect your service to be available all the time. You also need to demonstrate success in making changes reliably so the business partners and stakeholders of your service trust your abilities. “You need to be believed when you say changes will have no impact on performance or customers,” the report adds.
The 77-page report, produced in partnership with by partners including AWS and Cyberark, is free with email registration — here. For this year’s report, the survey was offered in English, French, German, Japanese and Malay. These languages cover regions where surveyors report high interest in dev-ops.
And let us know in the comments (or via email: editorATopenstack.org) if this squares with what’s going on at your company and whether you think it will change any time soon.
- Exploring the Open Infrastructure Blueprint: Huawei Dual Engine - September 25, 2024
- Open Infrastructure Blueprint: Atmosphere Deep Dive - September 18, 2024
- Datacomm’s Success Story: Launching A New Data Center Seamlessly With FishOS - September 12, 2024
