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.
Summary
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.
This is one of the best articles I have read on defining what DevOps really is. The author nailed it with this: “DevOps is the progression of the software development lifecycle (SDLC) from waterfall to agile to lean”. YES! We started this movement in 2009 and it has been tremendously successfully. We created a team composed of Architect or Lead Developer, Developer(s), Project Manager, Business Analyst, QA tester and Operations\Platform Engineer. The results have been that we deliver value to the business faster and with far less issues than with the waterfall approach with team silos.
First, thanks for the article. I agree with your definition of what DevOps “is” as a practice, but I disagree with this:
>>DevOps is not a person, a role, or a title. You are not a DevOps engineer, even though you may call yourself one.
What do you call someone who’s role is to enable the DevOps practice at a company? This person might do everything from getting the company on git, helping build unit/acceptance tests, enable CI/CD with jenkins, setup and maintain configuration management with puppet, help developers spin up environments with Vagrant+puppet, maintain the deployment scripts, and own the release process. If someone with that job role described themselves as an, “engineer who practices DevOps,” I would be hard pressed to fault them for having a title of, “DevOps Engineer.” In fact, I just described my role at the company I’m currently at.
I think it is important to understand that DevOps started as a cultural shift and a mindset of applying certain principles to the SDLC, as you said. However, it is a bit petty to belittle someone for using it as a title, since it happens to be the most descriptive title for the role, in my opinion.
Jason,
The intention of the article was not to belittle anyone or anything. The point of the article is that in many enterprises the concept of DevOps is misunderstood. Instead of improving the overall SDLC and operations many to choose to rebrand systems administrators as DevOps engineers. In essence they create yet another silo instead of eliminating silos. At the end of the day, what we call ourselves is irrelevant. It is results that really matters. I am OK with the title of DevOps Engineer if the end result is better, faster, more reliable software. I am not ok with the title of DevOps Engineer if the end result is more of the same. Thanks for your feedback.
Thanks a lot for the author for explaining brief about DevOps term.
I’d like to expand a little to what Jason mentioned. In my view, the DevOps role is two fold. The first is what Jason mentioned…helping to set up the infrastructure to enable a lean operations process. The second role (which I’d say is more crucial) is having someone open up the lines of communication. You need a person who can “talk the language” of developers, operations, QA and release teams. Without this, you will not build up enough trust to change the culture.
There’s a perception that the developers and operations teams have opposing goals. The developers want to push out lots of changes to implement new requirements while the operations teams want to keep changes to a minimum to maintain stability. The real goal is pushing new changes out quick while maintaining a stable production environment. That is the message that needs to be communicated but won’t happen unless all the teams can have open and honest communications. I believe the DevOps role is one that helps make this happen by demonstrating how and why this should happen.
I see the DevOps movement having the same issues as the Agile movement did in its early days. When agile first came on the scene, people used to think if they just stopped documenting their work they were being “agile”. Practices like unit testing, small release cycles, etc. which built an agile culture took much longer to become reality. Similarly, just having Chef or Puppet deployments doesn’t mean you have a DevOps culture.
Thanks for your post … I have removed DevOps from my title because what I am seeing exactly what you are seeing but it goes something like this “When I ask them where is the operations team is, they often say either “we did not invite them,” or even worse, “we don’t talk to them.” I am seeing DevOps being more NoOps there is a great event called DevOps Days but the funny thing was it felt like Developers are now expected to do what operations did. Now that we have the Cloud adoption widespread there is mutiny going on in a lot of corporations because the idea of automating everything has put Operations and SysAdmin who don’t have the knowledge of scripting out of business. So I agree most corporations and startups have lost touch … DevOps has become NoOps … 🙂 So instead of the Developers focusing on Code … they now have to focus on everything as the rise of SDN and APIs has diminished the value of a Solid Network or System Admin. The whole title DevOps is elusive because for one company DevOps may mean Build Engineer in another company DevOps may mean Infrastructure Automation Engineer or simply Senior System Administrator. It is nothing new for a Senior Windows Engineer to write Powershell Script and it is nothing new for a Senior Linux Engineer or Mid-level engineer to write bash scripts. The idea of expecting someone with an infrastructure background to easily become a build engineer actually hurt the company. As the Engineer would have to be an expert in everything … She/He can no longer specialize in anything …