Buzzword Abuse – The Anatomy of a DevOps Engineer

This post was originally posted by our own Nir Cohen, at DevOps.com.

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

Hear Ye! DevOps Engineers & Teams – Integrate ALL your DevOps Tools out of the box. Psych. But really…Get Cloudify.  Go

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.

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 Nir
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.