Cloud.  DevOps.  Both are in the fad category, but both are very popular and everyone is grasping at what they really are.  There is a subtle difference however.  “Cloud” is ambiguous, this leads to the never ending line of questions “What is Cloud?”  and yet more as the concept evolves such as “If cloud means in the cloud, then isn’t private cloud an oximoron?”  DevOps on the other hand seems deceptively intuitive.  This has caused confusion in the ongoing conversation because different people mean different things.

I see it as 3 distinct definitions and I’m going to lay them out to help people start to refine their thinking.  To facilitate this I’m going to take dev and ops as keywords and add an operator.  The operator determines which methodology is adopted by the other camp.

Now let me go a step further and suggest that these are not simply aspects of devops, they are in fact the 3 phases of what is collectively the “devops transformation”.

Phase I: Dev > Ops

In this phase developement methodology and mentality are adopted by operations.  My estimate is that this represents about 90% of the devops movement.  This where the DevOps movement started and where most of its focus is today.  Several things happen in this phase:

• IT groups and systems/network administrators re-realize themselves as “operations”.  Let us not forget that this is a new concept to many people, they don’t think of themselves as “operations” they think of themselves as IT.  If you’re running a website this is a fairly natural fit, but for traditional IT groups this is an area of contention in and of itself.  In the enterprise space you’re not “operating” a website, your “operating” a business.
• Agile is slowly adopted and adapted into operations.  In many cases this means striping agile down to its first principles and its Lean roots.  Its a matter of taking existing practices such as ITIL and marrying them with agile principles.  This is slow and individually tailored to each company as many folks have found that things like SCRUM don’t work for ops, but visual workflow and control of work in progress (meaning, the inappropriately named “Kanban”) do.  Finding balance between Peter Drucker’s “doing things right and doing the right thing” takes time.
• Re-tooling for the virtualized world.  I could say “cloud world” but thats inaccurate, since the problems are the same if you have a large internal VMware deployment or an external AWS deployment.  This is where most of the action has been in DevOps so far and what the DevOps Toolchain Project has been about.  This is the draw, in particular, to configuration management (in the automation sense, not the ITIL one) and is helped along by the 3 companies really driving the publicity of DevOps, those being Puppet Labs, OpsCode and DTO Solutions.
• Monitoring gets kicked up a gear.  Just as virtualization causes you to re-evaluate your tools for configuration management and command-and-control (now being called “distributed orchestration”) your monitoring needs to step up to the new challenges as well.  This is where you will challenge your existing monitoring system, expand its functionality and re-consider your logging and trending strategies.  Maybe everything is up to snuff already, but with all the recent additions to the alerting/logging/trending category you’ll inevitably try some new things and get over your fear of using tools written in Ruby. 🙂
• etc.

Phase II: Dev < Ops

In this phase operations methodology and mentality are adopted by developers.   My estimate is that this represents less than 10% of the devops movement.  This phase generally represents the bonding of the two groups and is easily confused with Phase I.  Things that happen in this phase are:

• Metrics everywhere.  This is something championed by John Allspaw, the collection of metrics from everywhere.  In Phase I you may have started collecting metrics but they were by Ops for Ops, however in this phase Dev is actually interested in the metrics and they are more business focused, so metrics aren’t just coming from the OS but are also coming from application code.  This is where dashboards start to be created to facilitate the wide absorption of metrics.
• Continuous Integration is implemented or evaluated.  Ops alone can’t implemented CI, so so inevitably cooperation forms around it.
• Cross-training of tools and practices.  This is when developers take a genuine interest in day-to-day operations activities, challenges and start aligning the toolsets between both groups.
• etc.

Phase III: Dev <> Ops

In this phase developers and operations unify, sharing responsibilities and practices.  I think this is an underlying principle of the movement, and frankly is what DevOps really is about.  This is the magical destination of your journey, a far country where Adam Jacobs rides unicorns and children spend time with their OpsDad’s and everyone sings drinking songs together at the pub.  The DevOps movement is so concentrated on Phases I and II that this is still an uncrystalized space, but it is what you are driving towards, therefore the things that emerge in this phase are:

• Fully shared responsibility in a “no finger-pointing” environment.  Dev may built it, Ops may deploy and maintain it, but both parties are fully committed to success and personal responsibility doesn’t end after the code is committed or deployed or whatever.  This is where post-mortems involve both teams, this is where performance problems are solved in dev/op pairs working together.  When things come up, you don’t just re-assign the ticket, you get together and work it as a single unified team.
• Developers are on-call.  This is popularized by WebOps shops and is not directly applicable to enterprises, but the principle still applies.  There should be an on-call rotation in development for problems which may be attributed to code they’ve written and full accept themselves as capable first-responders.
• Integrated Continuous Improvement.  At this stage there aren’t 2 teams anymore, there is large interdisciplinary team of professionals.  New tools, new practices, new projects, etc are presented to the whole team whether coder or sysadmin, so that both groups can bring their capabilities to the table as we continually improve.  Just as in TOC, we do not want Inertia (ie: “the new status quo”) to slow us down by making us complacent.
• etc.

Framing the Conversation

Are you in the midst of a “DevOps Transformation”?  More likely the vast majority of you are just modernizing your existing operations practices and tools.  Perhaps your usual weekly dev and ops meetings have simply been renamed “DevOps Weekly Meeting”.  You might think that Phase III is impossible in your environment but there is some interesting things in I and II.  Everyone is in a different place, but there is a natural and inevitable progression here.  The first step on that road is changing the culture, and the DevOps movement has caused that to happen.

From this model you can see why using “DevOps” as a title or job description is problematic.  Which of the 3 do you mean?  Do you mean a sysadmin in Phase I who is up on the new wave of operations tools and practices?  Do you mean a developer in Phase II who is using feature-flags and continuous integration?  Do you mean any IT worker who is culturally savvy to working together and serving the common business needs?  Who are you talking about?

The parts that make up what “DevOps” is are not new.  Whats new is the culture shift that is being accepted in places it wasn’t previously.  In years past employees that tried to “cross the lines” would often be beat down as being overly nosy or over-achievers or whatever.  DevOps may be a fad, just as cloud was, but its opened up a world of possibilities that were previously closed to us.  Once using AWS was unthinkable, now its almost expected.  Once trashing Tivoli for an Open Source solution was crazy, now its welcomed.  Once asking dev for metrics in code was laughed at, now its applauded.  So embrace this time in the history of our industry and seize the new opportunities by keeping that conversation alive.