The Evolution of DevOps

 Not Just a Tech Problem  

Because it is a framework deployed in tech companies to address a technical problem, it’s often assumed that DevOps is technical in nature – simply about automating processes, testing, and deployment.  It’s assumed that a DevOps engineer is just someone who uses automation tools such as Jenkins, Kubernetes, or Chef.  DevOps is not just about automating processes though – it began as a way to address the split between development and operations teams that causes so many headaches and delays during software development.  In fact, it turns out that the issues that plagued technology companies before DevOps – issues that still cause software flaws, fragile code, and fewer features and innovations in many companies-- are actually more human issues than technology issues.  The causes of these problems can often be mapped back to issues with a company’s culture.   

A Dynamic Set of Practices Based on Transparency, Sharing, and Empathy 

DevOps is a dynamic set of practices and theory that mixes management principles and automation practices and tools in order to help companies improve their software development.  It’s firmly rooted in the idea that for the best software to be developed, the culture of a technology company must be one of transparency, sharing, and empathy.  Various tech companies and individual engineers have used and developed their own set of practices based on DevOps principles using distinct tools and choosing certain methodologies to focus on for their particular development needs.  Here we’ll examine the evolution of DevOps methodologies and tools since its inception in 2009.  

The Beginning:  

Roots in Agile  

With many movements that develop over time with many different contributors it can be hard to pinpoint a specific point of “inception.”  Some concepts core to DevOps began developing as early as the mid-2000s (Agile, which is related to DevOps was developed in 2001) but the first DevOps Days was held in 2009 in Belgium.  It was started by Patrick Dubois, and he is credited with coining the term.  The ideas of DevOps quickly took off, gaining a group of passionate advocates in the software development and IT world.  Many of these advocates were also proponents of Agile, frustrated with the world of waterfall software development that existed before.  But DevOps answered part of the equation in software development that Agile left out – operations.  DevOps included operations in the development process, applying the same methods of automation and cultural practices to operations just as it does to development.   

CAMS 

One early contribution to the evolution of DevOps was the CAMS model (Culture, Automation, Measurement, and Sharing) which was a set of tenets for DevOps developed by Damon Edwards and John Willis.  In the CAMS model, they emphasized the culture of a DevOps company as the most important or foundational aspect.  According to John Willis: “If you don’t have culture, all attempts at automation will be fruitless.”   

Culture 

A culture of DevOps means breaking down the silos of different teams, such as the people who write the code, deploy, test, and then operate the cod.  It also often includes the ideas of “transparent uptime” which guide how to interact with customers, aspects of the LEAN methodology, and the knowledge that failures are unavoidable.  A person is not ever to blame for issues that arise – processes are, and processes can be improved.  Running “blameless postmortems” is one tool that DevOps teams use to examine issues and improve future detection and recovery time.   

 Automation 

A key innovation of DevOps is framing “infrastructure as code.”  Everything in DevOps should be automated, both the development and operations side.  There are many different tools and variations on processes for automation, including Jenkins for the development side, and Chef for operations.  The rise of cloud computing has allowed a huge increase in automation in DevOps. 

 Measurement 

Firmly rooted in the ideas of Agile, DevOps is also about continual improvement.  And to continually improve, you must measure everything that you can.  DevOps organizations must be able to pivot if something that was tried isn’t “measuring up,” and be able to take a hard look at processes if IT performance numbers are not meeting goals.   

 Sharing  

Automation is rooted in transparency – processes must be transparent so that problems can be traced back to causes, examined, and then solved in a way that prevents future issues.  Responsibilities also need to be shared in order to break down barriers between teams and individuals and create a shared language to discuss problems and create solutions.  Continual Integration tools such as BitBucket and Git help with this.  

A Decade of Implementation, The State of DevOps, and the Cloud 

 In just over a decade, DevOps has seen huge implementation across the tech industry.  It’s famously used by successful companies such as Netflix and Amazon.  An increase in Cloud Computing has caused a huge increase of automated tooling, with tools such as Puppet, Ansible, Chef, Git, Maven, and Jenkins now closely associated with DevOps.  It’s also seen an increase in the types of people driving implementation:  what was once driven by engineers and coders is now being embraced by managers and other leaders.  

 In May of 2020 GitLab reported that DevOps is indeed still effective in 2020: 83% of the developers they surveyed reported faster code release.  But DevOps hasn’t been evenly applied.  The State of DevOps, an annual report put out by Puppet, discusses the success of companies implementing DevOps.  The report breaks companies into 3 categories: “Low DevOps Evolution,” “Mid-Level DevOps Evolution,” and “High DevOps Evolution.” Predictably, the increase of success gained by adopting DevOps practices correlates with how much of DevOps the company actually implements.  Just as predicted by John Willis, simply attempting to automate processes without making a cultural shift will not be as effective.  

DevOps Today: What Is a DevOps Engineer, Anyway?  

Today we often hear the misnomer: “DevOps Engineer.” DevOps is actually a way to structure a culture or a team, so it would appear that the term “DevOps engineer” and related job titles are inaccurate.  A “DevOps engineer” could mean a wide variety of things: an IT operator who once manually worked deploying servers, and now runs the automatic deployments and testing for the development pipeline, a developer who applies automation to operations, or even a developer who is “on call” to assist with operations.  Though it’s been thought “incorrect” to call someone a DevOps engineer, new more specialized jobs have evolved out of DevOps.  Now, a Site-Reliability Engineer (SRE) who specializes in containers or AWS could truly be considered a DevOps engineer.  Whatever the case, it’s important to remember that a professional working in a DevOps environment should not only be comfortable automating processes and familiar with tools like Jenkins.  They also need to be committed to empathizing and working with members of both development and operations teams and have the support of an organization committed to fostering a DevOps culture.  

Interested in learning more about DevOps?