A Useful Definition of DevOps

1,339 views
Skip to first unread message

adrianco

unread,
Apr 6, 2012, 12:11:22 PM4/6/12
to dev...@googlegroups.com
I've circulated this to a few people for feedback as a google doc, have included some useful comments from Shlomo Swidler, think it makes more sense to discuss it here than as a blog post.

By useful I mean that the definition is a framework that encompasses all the other definitions (within reason), while also providing guidance for people trying to decide whether a company is "doing" DevOps, and whether a candidate's resume includes DevOps skills. To do this, the definition has to be broken into several aspects, and some aspects have to scale progressively. When I asked around I found that there is a maturity model definition for Agile development, but couldn't find a definition for DevOps (http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration), so that seems like a good thing to attempt.

I'm not claiming that this is definitive or complete, and I would like input from others to validate, guide and extend this definition, if they think it is useful.

The aspects of DevOps are 1. The DevOps movement. 2. A maturity model for companies doing operations. 3. Personal experiences and 4. skills for people doing DevOps.

1. The DevOps Movement

The DevOps movement has leaders, followers, meetings, conferences and publications that are dedicated to improving the way that development and operations work is done by promoting the concept of DevOps. There are some significant inspirational moments in DevOps history, such as the http://blip.tv/oreilly-velocity-conference/velocity-09-john-allspaw-10-deploys-per-day-dev-and-ops-cooperation-at-flickr-2297883 Flickr presentation by John Allspaw and Paul Hammond at the 2009 Velocity Conference (I was there...).

2. CMMI for Operations

Here's the CMMI model, each of the "level" headings is reproduced in bold below with a proposed mapping to operations and DevOps.
http://upload.wikimedia.org/wikipedia/commons/thumb/e/ec/Characteristics_of_Capability_Maturity_Model.svg/600px-Characteristics_of_Capability_Maturity_Model.svg.png

Level 1. Initial - Processes unpredictable, poorly controlled and reactive

This corresponds to many companies that haven't started doing DevOps, they are fire-fighting and finger-pointing with no operations automation or change control.

[Shlomo sez:] It’s instructive to think of this in terms of the OODA loop. In Level 1 there is: little or no tooling to help “Observe”; “Orient” takes place in isolation, often lacking input from or consideration of other functions; “Decide” is performed by staff lacking sufficient experience and rigor; and “Act” is done without considering how to perform the action controllably and repeatably. In Level 1 organizations the OODA loop is also seldom closed, so the experience remains a one-off, unable to be learned from (it doesn’t affect what is later Observed) and applied to future analysis (it doesn’t affect future Orienting).

Level 2. Managed - Processes characterized for projects and is often reactive

Individual project teams are using automation but not in a coordinated way. Other teams don't share the automation so there are issues during hand-off between developers and operations and they have to react and fire fight when problems occur. For example developers use change control, but operations don't use change control or use a completely different system with no integration.

[Shlomo sez:] The unit of function in this description should be the “delivery of the service”, not the “project”. So it includes everything from requirements specification (use cases, etc.) down to service level assurance.

Level 3. Defined - Processes characterized for the organization, and is proactive

Processes and automation span multiple project groups so that Dev and Ops are sharing the same processes and tools and hand-off issues are minimized. This could be considered the most basic level of DevOps integration.

Level 4. Quantitatively Managed - Processes Measured and Controlled

Developers and Operations are using the same metrics for success, so that they are both responsible for quickly delivering business value and are both responsible for site availability and performance. Other characteristics may include: Developers run what they wrote and take turns to be on call if their code breaks; Tools exist to identify what broke and which developer to call. All systems have APIs that can configure, deploy and maintain every aspect of the production system. The actual ops organization may be separated out via an API at either the PaaS or IaaS level using internal or public cloud.

Level 5. Optimizing - Focus on process improvement

Operations functions and processes are being continuously automated away by DevOps engineers so that any repetitive processes in their daily work are eliminated by increasingly sophisticated tooling. Rather than write run-books, write code.  Ops functions may be embedded as DevOps engineers within the development organization. Developers work to a self service PaaS model, and DevOps is focused on evolving the PaaS to improve scalability, availability and productivity. New tools are built and may be open sourced, and contributions are made to improve existing open source tools.

3. Personal experiences and skills for people doing DevOps

There are two components to a personal experience, the skill set of the person, and the maturity of the organization where they acquired that experience. One possible model for this is the http://en.wikipedia.org/wiki/Six_Sigma#Implementation_roles Six Sigma "belt" levels, although the names matter less than the categories. From the most experience down that would give us the following roles:

DevOps Master Black Belt

The Master Black Belt is responsible for creating and defining DevOps techniques, and teaching them to others. They are the gurus of DevOps, speaking at conferences and publishing books on the subject and have experience of taking organizations to at least maturity level 4.

DevOps Black Belt

The Black Belt is an experienced DevOps practitioner capable of leading a DevOps transition at a company and training their teams in the tools and techniques of DevOps. An experienced DevOps black belt has a track record of successful DevOps transitions to at least maturity level 3. They may have manager or architect roles in the organization. They ideally have worked in both development and operations roles at some point in their career.

DevOps Green Belt

The Green Belt is a participant in a DevOps transition project or works full time in a DevOps role. They are familiar with the DevOps philosophy, toolset and techniques, but they aren't responsible for leading transitions or training sessions, they are responsible for building code that automates operations functions. An experienced Green Belt has been a participant in a successful DevOps transition or has hands-on experience working at an organization that has reached at least maturity level 3.

4. Skills and Tools

There needs to be a clear enough definition that a hiring manager can get guidance to write a DevOps oriented job spec. They will do that anyway... There are many varieties of DevOps skills, just as there are many varieties of Developer skills and Operations skills. The key is that DevOps should combine skill sets along with the concepts of how to integrate them.


Andrew Clay Shafer

unread,
Apr 6, 2012, 5:23:32 PM4/6/12
to devops


You are now entering FSOP Cycle Phase 4.

http://www.techdarkside.com/FSOP.jpg

Keep your arms and legs inside the ride at all times.

Zac Stevens

unread,
Apr 7, 2012, 5:32:31 AM4/7/12
to dev...@googlegroups.com
Hi Adrian,

Thankyou for starting this discussion.

On Fri, Apr 6, 2012 at 5:11 PM, adrianco <adrian.c...@gmail.com> wrote:
> By useful I mean that the definition is a framework that encompasses all the
> other definitions (within reason), while also providing guidance for people
> trying to decide whether a company is "doing" DevOps, and whether a
> candidate's resume includes DevOps skills. To do this, the definition has to
> be broken into several aspects, and some aspects have to scale
> progressively. When I asked around I found that there is a maturity model
> definition for Agile development, but couldn't find a definition for DevOps
> (http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration), so
> that seems like a good thing to attempt.
>
> I'm not claiming that this is definitive or complete, and I would like input
> from others to validate, guide and extend this definition, if they think it
> is useful.

<--snip-->

> 2. CMMI for Operations

Applying CMMI to DevOps is an interesting idea, and one that could be
useful. It would speak to senior managers who have heard that DevOps
aims to improve business outcomes, and want to understand the
opportunities they have for improvement. Considering the same problem
from the bottom of the organisation (or for the candidate assessing
whether a company is "doing" DevOps) might lead us towards the Joel
Test[1].

In both cases, the contentious part is the definitions. For example,
achieving your Level 5 appears to require organising around PaaS; I
don't agree that that's the pinnacle of DevOps in general, though it's
certainly going to be true for some organisations.


> 3. Personal experiences and skills for people doing DevOps
>
> There are two components to a personal experience, the skill set of the
> person, and the maturity of the organization where they acquired that
> experience. One possible model for this is the
> http://en.wikipedia.org/wiki/Six_Sigma#Implementation_roles Six Sigma "belt"
> levels, although the names matter less than the categories.

I'd take a step further back and suggest that the categories matter
less than the intent. Who is the audience for this section? How
would it be applied?

When I was starting my career as a system administrator, the SAGE "Job
Descriptions for System Administrators"[2] had a big impact on me,
providing a roadmap for my growth as a professional. It was easy to
figure out where I stood, and what I needed to work on to improve.
Where do junior sysadmins these days go for guidance? Perhaps, for
operations staff, the SAGE levels simply need to be updated to reflect
the soft skills and tools families that have come to prominence since
the originals were written.

Looking to Six Sigma for guidance here gets my hackles up. Two main points:
* I don't feel that Six Sigma implementation is analogous to DevOps
in any meaningful way
* The tone is exclusive, not inclusive, and antithetical to the
principles of the movement

I don't think we're at a point where looking to evaluation or
accreditation schemes is useful.

Conversely, I think there's a lot of value in helping individuals
identify opportunities for self-improvement and professional
development. I'd love to see something that speaks to that audience.


> 4. Skills and Tools
>
> There needs to be a clear enough definition that a hiring manager can get
> guidance to write a DevOps oriented job spec. They will do that anyway...
> There are many varieties of DevOps skills, just as there are many varieties
> of Developer skills and Operations skills. The key is that DevOps should
> combine skill sets along with the concepts of how to integrate them.

I don't agree that "doing DevOps" involves "hiring DevOps", or that
being able to write a "DevOps job spec" is a generally useful thing.

Conversely, I do want to be able to hire developers and system
administrators who have developed the skills (soft and hard) that I
associate with DevOps - whether or not the candidate is familiar with
the term. Then again, that was true before *I* was familiar with the
term.


Zac

1: http://www.joelonsoftware.com/articles/fog0000000043.html
2: http://static.sage.org/field/jobs-descriptions.html

Adrian Cockcroft

unread,
Apr 7, 2012, 2:08:07 PM4/7/12
to dev...@googlegroups.com
Level 5 is about continuously improving and developing new processes and tools. So while level 4 could include using a state of the art tool set (which might come with a PaaS label or not), level 5 implies that you are developing new tools and processes or adding to the state of the art. Tooling tends to turn processes into services, so Operations as a Service or PaaS is a label that could be applied to the outcome.
 

> 3. Personal experiences and skills for people doing DevOps
>
> There are two components to a personal experience, the skill set of the
> person, and the maturity of the organization where they acquired that
> experience. One possible model for this is the
> http://en.wikipedia.org/wiki/Six_Sigma#Implementation_roles Six Sigma "belt"
> levels, although the names matter less than the categories.

I'd take a step further back and suggest that the categories matter
less than the intent.  Who is the audience for this section?  How
would it be applied?

When I was starting my career as a system administrator, the SAGE "Job
Descriptions for System Administrators"[2] had a big impact on me,
providing a roadmap for my growth as a professional.  It was easy to
figure out where I stood, and what I needed to work on to improve.
Where do junior sysadmins these days go for guidance?  Perhaps, for
operations staff, the SAGE levels simply need to be updated to reflect
the soft skills and tools families that have come to prominence since
the originals were written.

Looking to Six Sigma for guidance here gets my hackles up.  Two main points:
 * I don't feel that Six Sigma implementation is analogous to DevOps
in any meaningful way

I used Kanban ten years ago doing Six Sigma projects, just sayin... (applying six sigma to operations should be a different thread if people want to go there :-)

Perhaps Scrum Master and Agile Coach are better analogies to think about? The labels exist as a shorthand for management to use.

 * The tone is exclusive, not inclusive, and antithetical to the
principles of the movement

I think there could be some measure of engagement with the movement as an expected attribute of a DevOps person. Definitions are there to make things clear, so "Does this person have DevOps skills, experience and mindset?" has a useful answer. That usefully excludes unskilled people who don't understand the principles of the movement, and gives some clarity to people for their personal development goals. 


I don't think we're at a point where looking to evaluation or
accreditation schemes is useful.

I agree, but if the DevOps movement is broadly successful companies that make a living out of training and accreditation will eventually latch onto it with their own definitions, so some thought and guidance now may help steer towards a better outcome, or at least names for roles that don't get peoples hackles up....
 

Conversely, I think there's a lot of value in helping individuals
identify opportunities for self-improvement and professional
development.  I'd love to see something that speaks to that audience.


> 4. Skills and Tools
>
> There needs to be a clear enough definition that a hiring manager can get
> guidance to write a DevOps oriented job spec. They will do that anyway...
> There are many varieties of DevOps skills, just as there are many varieties
> of Developer skills and Operations skills. The key is that DevOps should
> combine skill sets along with the concepts of how to integrate them.

I don't agree that "doing DevOps" involves "hiring DevOps", or that
being able to write a "DevOps job spec" is a generally useful thing.

Conversely, I do want to be able to hire developers and system
administrators who have developed the skills (soft and hard) that I
associate with DevOps - whether or not the candidate is familiar with
the term.  Then again, that was true before *I* was familiar with the
term.


Zac

1: http://www.joelonsoftware.com/articles/fog0000000043.html
2: http://static.sage.org/field/jobs-descriptions.html

At some point the DevOps movement runs into the realities of large enterprise silo-ed developer and operations practices. To get management attention span in that environment is challenging. e.g. if "Competitor X is out executing us, what can we do to speed things up?" gets the answer "DevOps", but then DevOps is a fuzzy movement that everyone defines differently it's not going to get much traction. If the answer is "Competitor X is using more mature DevOps processes and tools to out execute us, here's a definition (on wikipedia or devops.org etc.) of where we are, what we should do next (The DevOps Cookbook), and what kind of people we need to hire/train to do it" then I think you get a different response.

Adrian
Reply all
Reply to author
Forward
0 new messages