DevOps is Dead!

a (controversial) rant

@thinkops

http://www.github.com/nir0s

Nir Cohen

the problems

Many recruiters are now looking for “DevOps Engineers“.
Many companies have “DevOps Teams”.
Many people are developing “DevOps Tools”.
Everyone wants “DevOps” but have no idea what it means

The definition

of “DevOps”

(searching: “What is DevOps?”)

the short definition of Devops

The ultimate business requirements to customer to business requirements cycle

where everyone is happy like this:

most companies

(in a strong russian accent)

run test bad!
monitor wrong thing!
react wrong thing!
no improve!
more bad thing...

devops to the rescue!

DevOps aims to solve these problems. It is a culture(!), in which People(!) collaborate(!) to improve(!) the biz-to-user cycle.

and in the middle you have:

that's right.

more people!

it requires

Collaboration/Communication/
Familiarity of the teams (with the system and its architecture)
Control (over deployments, features and failures)
Short dev-to-prod cycles (to prevent major bugs) - which also leads to...
Quality testing (without which this won’t work)
Automation (to make all of the above possible)

let the rant commence

The
“DevOps Engineer”

Now look at the following job description:

See anything… strange about it?

Yes, they want “a God” -

and that’s not even the main issue here.

The problem is, that adding “DevOps” to this title,

completely contradicts the idea of “DevOps” as it

was defined in the first place.

the devops god

So practically, a “DevOps Engineer” is someone who is:

A Linux expect (preferably all distributions in the world)
Knows Code (preferably Python, Ruby, Perl, Bash, Java, Batch, Powershell, Powerpoint…)
Is adept in CM, CI, CD, NBA and NBC (So they must know Chef, Puppet, Jenkins, Hudson, Travis, Git, TeamCity, Circle CI…)
Has vast experience in Cloud (like.. in the sky?)
Is familiar with Databases (Including high availability, disaster recovery, fault tolerance, fail-over… something like the stigma of an average marriage)
Knows Monitoring (Nagios? REALLY?!)
Knows Networks, storage systems...
Knows Big Data (the bigger, the better)

so... a ''devops team''

is a group of people who:

Know everything
Can do anything
Do not develop the application (That’s the Devs Job)
Do not install servers manually (That’s the Ops job?)..

Many times, the “DevOps” team is a team that develops tools for operations… other times, they are the Ops Team… and worst of all.. sometimes, they are just a bunch of people who cite buzzwords.

the ''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.
They ENABLE DevOps.

that much is also true for...

JIRA,

Campfire,

PagerDuty,

CloudWatch,

New Relic…

these are Communication, Collaboration and Monitoring tools.

can you define a set of ''culture tools''?

When a writer uses a Mont Blanc Limited Edition pen to write a better-than-shakespeare masterpiece, you don’t say: “Oh, what a nice Culture Tool that pen is!”. It’s a Writer’s instrument!

There are Automation, Collaboration and Communication tools that enable the DevOps culture to be implemented in the organizational DNA.

end of rant…

now seriously...

what we tend to mean

when we say “DevOps” is:

“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 as our Orchestrator.”

what we should mean

when we say DevOps is:

“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 deploy fast to overcome bugs ASAP and create less significant service outages if any new bugs arise.”

we enable that by

Keeping our code tidy and well documented.

Keeping our code/documentation under version control so that we can always go back to a previous version, 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 and configuring servers manually makes them more susceptible to human errors (and takes time).

Automating our code deployment so that we can deploy a lot, without making mistakes.

what did we stray off course?

Culture is a very abstract and complicated concept. It isn’t as simple and obvious as tools and skills.

Along the way, we took the tools and skills that are required to implement DevOps and named them DevOps instead. We listed the skills necessary to deal with these tools, created a job description, and from there… the ball rolled.

summary

You can’t have a “DevOps Team” or a “DevOps Engineer” because “DevOps” is not “A Thing”. It is “A How”. It’s not an answer to: “What’s your job?” or “What does your team do?” it’s an answer to: “How does your company do it?”.
Most importantly: DevOps, is “Devs WITH Ops”, not “Dev AND Op”.
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.

some links

Puppet Lab’s take on DevOps (note what their Head of Operations says about DevOps Engineers. Just horrible.)
Wikipedia’s definition
A very elaborate and wonderfully informative article about DevOps.
http://theagileadmin.com/what-is-devops/

so this:

is actually

sad...