Ask five IT people what the term DevOps means, and you will likely get five completely different answers. Go to any online job board, search DevOps, and look at the job descriptions, and you will see great disparity in the desired skillsets and responsibilities, as well as job titles. Go to LinkedIn and search for people using DevOps, and you will see thousands and thousands of people calling themselves DevOps engineers. Some of them may even claim having up to ten years of experience. I find it quite amusing that nobody can define what it is; very few companies are actually doing it and doing it well, yet we are all experts at it.
What is DevOps?
Let’s get one thing straight. DevOps is not a person; it is not a job; it is not a role. I have written this many times, but my definition of DevOps goes like this…
DevOps is a culture shift or a movement that encourages great communication and collaboration (aka teamwork) to foster building better-quality software more quickly with more reliability.
Let’s break this definition down. The first key phrase is “a culture shift or a movement.” Notice this does not say a person or a role. The next phrase is “communication and collaboration.” Again, we are not talking about a person or a role, but a mindset for getting teams to work more closely together with common goals in mind. The final component is the end goal: “better, faster, more reliable.” DevOps is all about getting to market faster with products that meet the businesses requirements and run without constant hand-holding and fire-fighting.
DevOps is the progression of the software development lifecycle (SDLC) from waterfall to agile to lean. DevOps goes beyond agile and focuses on removing waste from the SDLC. Often, the waste or bottlenecks are found in the forms of inconsistent environments, manual build and deployment processes, poor quality and testing practices, lack of communication and understanding between IT silos, frequent outages and failing SLAs, and whole suite of issues that require precious IT resources to spend significant time and money keeping the systems running.
What I am seeing in the enterprise
Enterprises are struggling with DevOps. They all want DevOps even though many do not know what it is. In many cases, I see infrastructure teams who are calling themselves DevOps leading a grassroots initiative. When I ask them where the development team is, they often say either “we did not invite them,” or even worse, “we don’t talk to them.” This is where I want to interject and say, “no, you are not a DevOps engineer.” A better consultative approach, however, is to take them through a few slides showing them how DevOps evolved, what the business benefits of DevOps are, and how the organization needs to change to achieve those benefits.
Another reoccurring pattern I see is that a “DevOps” team’s first step is often to figure out if they are going to use Chef or Puppet (or Salt or Ansible or whatever else is hot). They have not even defined the problems that they are setting out to solve, but they have the tools in hand to solve them. Often these teams wind up building thousands of lines of the scripts, which raises the question, “are we in the business of writing Chef scripts or in the business of getting to market faster with better quality and more reliability?” Too often, these teams code themselves into a corner with mountains of proprietary scripts that actually add more waste to the system, instead of removing waste from the system, which is what the driving forces behind the DevOps movement are all about.
In essence, the old bottleneck of procuring and installing new hardware becomes replaced with a new bottleneck of creating tickets for the “DevOps engineer” to create new Chef scripts to create the necessary environments for the app dev team. Had the teams worked together in a collaborative fashion instead of in silos, they could have a created a framework for self-service provisioning that provides the operations team with the proper controls and the application team with the tools to get their job done faster.
What I often see is that the operations teams enforces what makes sense for operations and creates a very restrictive environment for the application team. This can lead to a bottleneck where the app team must stand in line to wait for changes, or even worse, the application team goes around the operations team and starts doing its own thing on AWS totally ungoverned. Too often, I have seen companies approach DevOps from only an operations perspective and build a bunch of nice tools and processes that nobody uses because they never involved application team in the process.
DevOps is not a person, a role, or a title. You are not a DevOps engineer, even though you may call yourself one. DevOps is all about getting better-quality, more reliable products to market faster by being more inclusive and improving communication and collaboration within the enterprise. Most enterprises do not need to mimic what web giants like Facebook, Netflix, and Etsy are doing. But to stay relevant in the fast-moving world of mobile and cloud, enterprises need to replace old, slow, high-touch processes with a modern approach to software development and operations.
Share this Article:
Latest posts by Mike Kavis (see all)
- The State of DevOps in 2016 - June 30, 2016
- What I Learned @ DockerCon 2016 - June 23, 2016
- Rightscale Publishes State of the Cloud Report for 2016 - May 11, 2016