Once, people used the word genius only when describing someone who really was a genius. Someone with extraordinary intellectual and perceptual capabilities. Today every parent uses this word to describe their, likely cognitively regular child – and this term has lost any good taste. I find the same trend holds true for DevOps. And yet, that doesn’t stop everyone from saying the word DevOps, a lot (and more often than not, in a completely wrong context).
The Problem
Many recruiters are now looking for “DevOps Engineers”. The demand for “DevOps engineers” has grown exponentially over the course of the last few years by thousands of %, just a small trend graph from indeed.com, and snippet from Google.
We constantly hear about companies building, “DevOps Teams”, and developing “DevOps Tools”. Everyone wants “DevOps” but have no idea what it means.
The short definition of DevOps is the ultimate business-requirements to customer to business-requirements cycle (often referred to as the best “development to production cycle”). How this would look in code:
(Of course, this snippet presents the problem very broadly and doesn’t take serious bugs into consideration)
All of this, aside from the development process is expected to happen automatically, not affect users at all, and have monitoring that is so exceptionally smart that it always points to the exact problem. Hmmm. What’s described above, is of course…. utopia.
Reality Check. Most companies are more likely in the camp that:
- runs tests manually or not at all
- monitors the wrong things
- reacts to the wrong problems in the wrong manner
- doesn’t improve work processes
- keep doing the above in iterations and trying to set out fires while more fires appear.
- more bad stuff…
DevOps aims to solve these problems.
It is a culture, in which people work together to improve the product delivery cycle.
At its base, it requires good collaboration/communication (with the other teams), familiarity (with the system), control (over features and failures), short dev-to-prod cycles (this isn’t mandatory, but can help to prevent major bugs), and quality testing (‘nuff said). This is practically a great analogy to a good relationship except that it also requires automation (to make all of the above possible), which is something you should probably refrain from in your relationship if you want your belongings to remain inside the house.
The Perceived Anatomy of a “DevOps Engineer”
Let’s look at the following job descriptions.
DevOps Expert
See anything… strange about them? Yes, they want a God.
The Dream Errr…”DevOps Team” is basically a group of:
- Linux Experts (preferably all distributions in the world)
- Coders (preferably Python, Ruby, Perl, Bash, Batch, Powershell, Powerpoint…)
- Adept at CM, CI, CD, NBA and NBC (So they must know Chef, Puppet, Jenkins, Hudson, Travis, Git…)
- Have vast knowledge in Cloud (like.. in the sky?)
- are familiar with Databases (Including high availability, disaster recovery, fault tolerance, fail-over… something like the average marriage)
- Know Storage (WTF?)
- Know Monitoring (Nagios? REALLY?!)
- Know Networks…
- Know Big Data (the bigger, the better)
Bottom line, they are supposed to be a group of people who know everything, can do anything, yet do not develop the application (That’s the Devs Job), nor do they install servers manually (That’s the Ops job).
Don’t even get me started on “DevOps Tools” – Puppet, Chef, Ansible, Cloudify, Saltstack, OpsWorks, Jenkins.. these are all “DevOps Tools”, right? WRONG! They are automation tools! They don’t “DevOps”. They automate, i.e. enable “DevOps”. JIRA, HipChat, PagerDuty, CloudWatch, New Relic… these are communication, collaboration and monitoring tools. You get the idea.
There are no “DevOps Tools”. Developers have development tools because a developer is a profession. Just like a blacksmith has a mallet. Can you define a set of culture tools? Are the pen, the paintbrush, and the violin considered culture tools? No, they are instruments for the writer, painter, and musician to create works of cultural significance.
In the same way, there are automation, collaboration and communication tools that enable the DevOps culture to be implemented into the organizational DNA.
What we tend to mean when we say DevOps:
- ‘We use Puppet to manage our servers’ configuration’.
- ‘We use Ansible to deploy our application versions’.
- ‘We use AWS as our infrastructure’, ‘we use Cloudify for our orchestration.
What we should mean when we say DevOps:
- ‘Our Devs and Ops work closely together’.
- ‘They’re familiar with each other’s work so that Devs know the system they’re writing code for, (and adjust to it) and Ops know the code they’re deploying (and understand how it affects the system)’.
- ‘They develop in short iterations and can deploy fast (both infrastructure and application) to overcome bugs ASAP and create smaller problems if any new bugs arise’ (again, not mandatory, but can help).
- There are many more items in this list… but you get the gist.
This is enabled by:
- Keeping code tidy and well documented so it’s easily understood by all.
- Keeping our code under version control and backed up so that we can always go back to a previous version in our environments, when needed.
- Testing and monitoring the most important aspects of the system rather than the ones that we don’t care about.
- Automating our Infrastructure, because deploying servers and configuring them manually makes them more susceptible to human errors.
- Automating our code deployment so that we can deploy a lot (that doesn’t mean that we HAVE to deploy a lot), without making mistakes.
Where did we stray off course?
Culture is a very abstract and complicated concept. It isn’t as simple and obvious as a tool.
Along the way, we took the tools and skills that are required to implement DevOps and named them DevOps instead. We appended the skills necessary to deal with these tools to a list, created a job description, and from there… the rest is history.
What people refer to as “DevOps people” is usually (not always) a term that describes operations people who know how to code and who automate stuff – “InfraCoders”.
So pretty much, you can’t (well,you can – it just doesn’t make much sense) have a “DevOps Team” or a “DevOps Engineer” because “DevOps” is not a thing.
It is a how. It doesn’t respond to the question: ‘What’s your job?’ or ‘What does your team do?’ it responds to: ‘How does your company do it?’. And most importantly: DevOps, is “DevsWITHOps”, not “DevANDOp.”
Having said that, DevOps is not ONLY for Devs and Ops. It’s for everyone. It’s not about the titles or teams, it’s about the way a company handles the process of delivering a product to production in the best way possible.
The problem with the “everything is DevOps” attitude is that it renders definitions meaningless. If everything is DevOps, then it’s everything and nothing, and de facto has no meaning. DevOps is already a complex concept. Making it mean everything, will make it practically impossible to implement.
Ultimately, it really makes no difference whatsoever what you call your special forces team. You can call them “DevOps” or you can call them Bean Soup. Just be sure not to delude yourself that by constantly using the word DevOps in the wrong context, that your company is doing DevOps, while all you’re actually doing, is using Puppet.
About the Author
Nir Cohen – is an Ops Architect at GigaSpaces working on Cloudify and a co-organizer of DevOps Days Tel Aviv. He’s the brainchild behind the awesome open source tool Packman for package management. Nir loves system architecture, likes to think of himself as an innovative, think-tank type of guy who adores challenges and has an extremely strong affinity to automation and system architecture. He’s primarily driven by researching and deploying new systems and services. To Nir, the most important thing in life is ethics. Find Nir on GitHub or follow him on Twitter.
Some interesting “What do you mean by Devops” questions from a presentation with a similar theme [1] from devopsdays last year:
* When was the last time Dev and Ops from your teams went out for a beer?
* Do Dev and Ops have shared incentive structures, go on joint teambuilding exercises etc.?
* When is the first time an Ops member gets involved in a Dev project?
* How much regular contact is planned between Dev and Ops after a release goes live?
* How many Ops stories/wishes/requests are incorporated into the Dev backlog?
[1] http://www.slideshare.net/xebialabs/devopsdays-atlanta2013
you are so right!! This is exactly how things have been for some time. I have worked with , not for, developers for years but we are different teams that think differently and thats not a bad thing. Seems folks want to blurr the lines are somehow create a “better” system .. 🙂 Ughh
So I cant seem to figure out where I belong now due to this “devops” headache. I have been an architect in Ops teams for some time as well as writing tools, automation, and all the crap you list above. So there is this odd thing that now everyone has different ideas on where these skill-sets belong. Some say engineering and others say ops should own. ( I am a bit skewed by coming from ops but I see logic for both arguments)
I agree that this is absurd where companies think they are going to get all of these different people wrapped up in 1 person . I dont think this trend is going to last because it is unrealistic and you are not going to be able to take ops/dev skills and mush them into this odd hybrid. I cant even remember how many idiots I have seen on youtube , blogs, and every where else (including large companies AS well as startups) trying to tell the world that their definition of devops is the one that is accurate! It is totally insane and I suppose I am going to have to figure out how I can take my current skills and make it work on one side or the other. It seems like I am in the minority in the way that I think since I have talked with many companies recently that are in love with the word DevOps but even after talking about it for 30 minutes cant quite pinpoint what it means. (or of course regurgitate something from the many idiots out there claiming to have figured out what it means and how to implement this new found thinking. Almost as bad as how the “Agile” methods have confused just as many !!!!)
Yep, I agree that DevOps is being abused the same way as “Agile” and “Full-stack developer”.
In my opinion, engineering is, well, when you engineer, and that usually means – produce something – a program, a script, a tool etc. Ops is somewhat closer to “end-user” side of tools. Both things are related and depend on each other, but Ops side usually has “the bigger picture” how to put everything together and make it work. Ops side might have no real skills of coding – they might ask some dev (or engineer): “Please, write some script that does this and that”. If the developer of the script does not ask “why”, then he/she remains just a developer writing a script. But if the developer starts asking questions and getting deeper into Ops, he/she might say: “Hey, I can make this script even better and do more than you ask for!” and Ops say: “Wow, that’s awesome, we didn’t know this was possible!” So, it’s communication (and the most important question in the world – “why”) between Devs (or engineers) and Ops which results in DevOps. IMHO.
This is an interesting article. I’ve worked in CM for over a year and I hear the word “DevOps” defined as a movement, a skillset, a culture, tools…so this clarifies questions that I’ve had regarding exactly what it is.
One question though: what does “NBA” and “NBC” stand for?
Excellent post! This should be a mandatory read for every IT manager and IT recruiter.
Devops = passing down the IT/Ops manager’s responsibilities to the dev and ops team members…so the person whose actual job is to organize the two teams, hold them together, create and facilitate an environment of cross-training and cooperation, take responsibility and make the hard decision will end up having even less clue of how things work in reality and the only task of pushing the devops team to absorb more and more responsibility over each other’s work. This is where DevOps originally comes from, grownup engineers cutting out the clueless middle-management….but it’s adopted mostly as means for middle-management to shed responsibility over things they don’t understand while still getting paid like they would.
So how can you tell if it’s a “real” DevOps team? Ask who they report to. If it’s a flat organziation with lot’s of DevOp teamleads reporting to high-level management, they get it…if it’s the same 4-5 layers of email-forwarders THEN an actual DevOps teamlead…then they don’t
It is the abuse and confusion around the term DevOps which brought me to this post. I have iterated on delivery pipelines and spent every waking hour driving home the importance of continuous improvement for some time. Now I am having trouble titling myself as a professional as I look for new employment.
I code, I automate infrastructure configurations and application deployments, I monitor all the things–I do a lot of these `DevOps` things, but the last thing in the world I want to be called in a `DevOps Engineer`. The “Industry” started calling it `DevOps Engineer`, well like you say, it’s not a thing, it’s a how. Though I, myself cannot come up with a better term to describe what I do. Perhaps we as the practitioners of this methodology should provide some guidance or suggestions on ways to describe someone with a DevOps mindset, with the knowledge and expertise to drive a DevOps culture. Someone who is skilled with the automation, monitoring, and communication tools which provide higher performing development and operations within a company. If we can’t title ourselves, how can we depend on the title provided by some recruiter or worse, self-claimed, ‘industry experts’?