The world needs a reference for collecting common DevOps principles and practices that are currently being used. To that end we’ve created this blog post as a work in process effort where we can gather DevOps wisdom collectively as an industry—there are going to be some missing pieces in this initial iteration so feedback is welcome. Please leave me a comment below or hit me up on twitter with suggestions.
DevOps is categorized as transformational in these four key areas:
- Favoring faster delivery cadence and a reduction in change volume.
- Treating our systems and infrastructure as code, including how we version it to how we build it.
- Changing our engineering culture to orient around the total delivery and usage experience.
- Creating feedback loops in your runtime environment that informs all parts of your engineering team.
Infrastructure as Code
Infrastructure as Code is sometimes reduced to mean Dockerfiles, Terraform Plans, or Chef cookbooks. Those are the practical artifacts of adopting this philosophy, but the broader goals of Infrastructure as Code instead describes our systems and applications in code.
When thinking of Infrastructure as Code, there are specific areas that must be considered:
- Version controlled artifacts that describe the system and all its components.
- Configuration management of the system in running state.
- Testing is a first order priority with Test-Driven Development (TDD) and integration testing as common practices.
- Facilitating distributed computing and scaling.
- Understanding your Software Supply Chain.
Adoption of Infrastructure as Code concepts happened rapidly with the underlying infrastructure shifting from bare iron, to virtual machines, to public cloud services, and now to containers and serverless patterns. Codifying the entire system continues to progress.
Culture is the foundation of DevOps, in fact many of the early adopters of DevOps said that DevOps was purely a cultural movement during the early years. The cultural divide between the dev and ops groups was apparent early on with staffing ratios of 10 devs to 1 ops. There were also competing priorities of stability and feature development. This tension created natural divides and silos based on roles in many organizations.
“You can’t directly change culture, but you can change behavior, and behavior becomes culture” — Lloyd Taylor VP Infrastructure, Ngmoco
source: John Willis and his excellent article on DevOps Culture
The DevOps movement arose as originally being called Agile Infrastructure. Agile had success transforming development practices and behavior and it was thought if we could just apply those same principles to operations then we would make progress. Behaviors did change, now as a part of operations, there were new practices like: Scrums, Kanban boards, standups and planning poker sessions. This were evidence of the start of a cultural change.
Naturally, tooling that influenced the culture was created that helped the devs and ops teams to collaborate. There was transparency and a new interest in facilitating tasks or federating operational tasks through ChatOps.
Runtime Feedback Loops
So far we have covered a lot of what the Dev in DevOps brought to the table: Agile, Version Controlled Infrastructure, and Software Supply Chain. Lets now explore what the Ops part of the equation brought to the equation. With the growth of DevOps and adoption across the organization, there was a renewed interest in:
- Monitoring everything and collaborating around monitoring systems.
- Performance as a priority across the entire development lifecycle and performance metrics being exposed to the writers of the application.
- Alerting and putting developers on call created a new feedback loop that adopted the “if you write it, you support it” mantra.
These feedback loops are mostly operational feedback loops that inform the team with how well the product or service is actually doing.
Continuous Integration and Continuous Delivery (often called CI/CD) is not a wholly new concept, however, the growth and adoption rate of CI/CD is on the rise. The focus on delivering software rapidly is influenced by the previous points in this article, and in many ways your delivery cadence metric is an indicator of how successful your organization has been at adopting DevOps. Don’t misconstrue what I mean. You do not need to be delivering 10 times a day to be successful, success is more a measure of the reduction of MTBD (Mean Time Between Delivery) for your organization. Moving from monthly to weekly to daily delivery is a journey and it is a journey worth making:
High-performing IT organizations experience 60X fewer failures and recover from failure 168X faster than their lower-performing peers. They also deploy 30X more frequently with 200X shorter lead times.
There are two key areas that influence your delivery cadence:
- Using a CI system or service that runs tests and creates artifacts that can move on to the next stage in the delivery pipeline
- A deployment system with minimal (but important!) gates and that handles orchestration
Request for Help
This research is a work in progress document to gather what we are doing in the DevOps world collectively as an industry—there are going to be some missing pieces in this initial iteration. As you can imagine, it is a bit daunting trying to distill years of practices into a single article and we would love your feedback. Please leave us a comment below or hit us up on twitter with suggestions.