Time for a DevOps Manifesto?

[kurtmilne]

Can we build a working draft of a DevOps manifesto right here? Or set
of guiding principles?

1 - Machines build machines - only use automated deployments.
2 - Prevent and remove fragile artifacts from production. ( hat tip
Visible Ops)
3 - No GUI based configuration - if you tweak it - consider it a "dark
failure" ( already in production - just not visible YET).
4 - Test driven design.
5 - Build and rebuild from recipe.
6 - Everyone owns uptime/security/quality
7 - Fail fast and early

etc.

What makes DevOps DevOps?

We can tweak tense/structure of each to have parallel form later.

<Group edit on>

[Mark J. Reed]

This came up last year, and I think calling it a "manifesto" might send the wrong message, but I do think it makes sense to document the assumptions that underlie DevOps. If nothing else, making them explicit will give us a chance to spot and excise the erroneous ones.

Maybe start by describing the category of problem we're trying to solve?

Selective thoughts on your list:

On Thu, Jun 30, 2011 at 2:42 PM, kurtmilne <kurt....@itpi.org> wrote:

3 - No GUI based configuration - if you tweak it - consider it a "dark
failure" ( already in production - just not visible YET).

GUI vs non-GUI is not the problem.  The point is there should be no local configuration tweaks on individual hosts.  A GUI is fine if the result of using the GUI is that data is updated inside your CMDB or your cookbook/manifest code repository.  Conversely, running a shell command is not necessarily OK if it's done locally on a managed host.

   

4 - Test driven design.

Of course, we like test-driven development and iterative design, though I'm not sure "test-driven design" is the right description.  But I don't see it as a requirement for DevOps.  The requirement is that devs produce testable code; we shouldn't try to dictate how to get there.

 

5 - Build and rebuild from recipe.

Not sure what this means.  Code builds have to be driven by configuration management?

  

6 - Everyone owns uptime/security/quality

That's a big one.

 

7 - Fail fast and early

How do "fast" and "early" differ here?

--
Mark J. Reed <mark...@gmail.com>

[John Allspaw]

Just replied to the earlier thread...I don't think DevOps should have a manifesto, referring to my earlier reply to the other thread.

What you list below are normally known as "best practices".  Which is a very good and fine thing to list. But it's nothing to do with DevOps. :)
-j

Another resource here....Chad's talk is really "optimizing for Dev/Ops happiness" -
http://codeascraft.etsy.com/2011/06/06/optimizing-for-developer-happiness/

--
John Allspaw

[kurtmilne]

John,

Welcome back. I appreciate your comments on this. I may be thinking
in broader end-to-end SDLC terms, of which DevOps is a piece of the
puzzle.

I still think some form of patterns/anti-patterns or key lessons/
competnecies would be useful to summarize for those trying to achieve
similar results.

Thanks for the link.

On Jun 30, 1:04 pm, John Allspaw <alls...@gmail.com> wrote:
> Just replied to the earlier thread...I don't think DevOps should have a
> manifesto, referring to my earlier reply to the other thread.
>
> What you list below are normally known as "best practices".  Which is a very
> good and fine thing to list. But it's nothing to do with DevOps. :)
> -j
>
> Another resource here....Chad's talk is really "optimizing for Dev/Ops

> happiness" -http://codeascraft.etsy.com/2011/06/06/optimizing-for-developer-happi...

[kurtmilne]

Mark- thanks for the color. The clarification on GUI/API based
configuration tweaks was really helpful.

Kurt

On Jun 30, 1:01 pm, "Mark J. Reed" <markjr...@gmail.com> wrote:
> This came up last year, and I think calling it a "manifesto" might send the
> wrong message, but I do think it makes sense to document the assumptions
> that underlie DevOps. If nothing else, making them explicit will give us a
> chance to spot and excise the erroneous ones.
>
> Maybe start by describing the category of problem we're trying to solve?
>
> Selective thoughts on your list:
>

> On Thu, Jun 30, 2011 at 2:42 PM, kurtmilne <kurt.mi...@itpi.org> wrote:
>
> > 3 - No GUI based configuration - if you tweak it - consider it a "dark
> > failure" ( already in production - just not visible YET).
>
> GUI vs non-GUI is not the problem.  The point is there should be no local
> configuration tweaks on individual hosts.  A GUI is fine if the result of
> using the GUI is that data is updated inside your CMDB or your
> cookbook/manifest code repository.  Conversely, running a shell command is
> not necessarily OK if it's done locally on a managed host.
>
> > 4 - Test driven design.
>
> Of course, we like test-driven development and iterative design, though I'm
> not sure "test-driven design" is the right description.  But I don't see it
> as a requirement for DevOps.  The requirement is that devs produce testable
> code; we shouldn't try to dictate how to get there.
>
> > 5 - Build and rebuild from recipe.
>
> Not sure what this means.  Code builds have to be driven by configuration
> management?
>
> > 6 - Everyone owns uptime/security/quality
>
> That's a big one.
>
> > 7 - Fail fast and early
>
> How do "fast" and "early" differ here?
>
> --

> Mark J. Reed <markjr...@gmail.com>

[Scott Smith]

If you use a web front end for config management(eg Puppet Dashboard), you are using GUI-based configuration. Seems kind of arbitrary to me.

I agree with John. Furthermore, I think you're trying to tackle a cultural problem with a technical approach. Unfortunately that doesn't work. People like to break rules. It's just in our nature.

-scott

[Andrew Clay Shafer]

What are you trying to accomplish with a manifesto?

Let's start there.

A manifesto, by definition, is essentially a marketing document.

What are you selling? What do you want people to buy into?

The original list proposed here is focused only on system automation.
In that form and with that as the sole focus, we don't have a
manifesto I would support.

[Guillaume FORTAINE]

Dear Mister Milner,

Thank you for your post.

> What makes DevOps DevOps?

To quote John Willis, I would say CAMS : Culture, Automation,
Measurement and Sharing :

http://www.cutter.com/content-and-analysis/journals-and-reports/cutter-it-journal/callforpapers03.html

And being a beginner to DevOps, a manifesto would definitely make the
life easier. However, according to me, your questions only focus on
Automation :

1) Culture

http://groups.google.com/group/devops/t/7b2df14560c7ea55

2) Automation

Andrew Shafer introduced the "Infrastructure-as-Code" concept, but it
seems that only a few people focused on what we can truly call
bare-metal before being able to move up to the higher layers : xCAT,
OpenStack, Apache Tashi, projet HeV...

Especially, I would greatly appreciate to invite you to a further
reading of the Intel presentation entitled "Enabling the Autonomic
Data Center with a Smart Bare-Metal Server Platform" :

http://www.acis.ufl.edu/~icac2009/files/presentations/Kinzhalin.pdf

By the way, for those of you would you like to go further, I would
greatly appreciate to invite you to a further reading of my post
entitled "Intel Rapid Boot Toolkit - UEFI Hypervisor : Cloud Computing
Firmware/Firmware-as-a-Service" :

https://lists.linux-foundation.org/pipermail/virtualization/2010-January/014598.html

-Note : Rackspace is working on Open Compute servers that are
coreboot/avatt enabled :

https://twitter.com/#!/Jwinela/status/59424563771080704

"Need to buy more Open Compute servers. Don't want stability /
integration tests to beat out coreboot/avatt dev."

3) Measurement

http://www.shinken-monitoring.org/

4) Sharing

Facebook, Google+, ...

Best Regards,

Guillaume FORTAINE
gfor...@gfortaine.biz
+33(0)631.092.519

On Thu, Jun 30, 2011 at 8:42 PM, kurtmilne <kurt....@itpi.org> wrote:

[Michael Stahnke]

Instantly I thought of the James White manifesto that was originally
delivered at DevOps Days Ghent 2009.

http://blog.websages.com/2010/12/10/jameswhite-manifesto/

The original was in a gist I think

Mike

[James Bailey]

On 30 June 2011 19:42, kurtmilne <kurt....@itpi.org> wrote:
> Can we build a working draft of a DevOps manifesto right here?  Or set
> of guiding principles?
>
> 1 -  Machines build machines - only use automated deployments.
> 2 - Prevent and remove fragile artifacts from production.  ( hat tip
> Visible Ops)
> 3 - No GUI based configuration - if you tweak it - consider it a "dark
> failure" ( already in production - just not visible YET).
> 4 - Test driven design.
> 5 - Build and rebuild from recipe.
> 6 - Everyone owns uptime/security/quality
> 7 - Fail fast and early
>

This sort of thing has alread been done , it not Devops but it is
something I use it almost daily as a check list for the "perfect 10"

https://gist.github.com/161265

== Rules ==
On Infrastructure
-----------------
There is one system, not a collection of systems.
The desired state of the system should be a known quantity.
The "known quantity" must be machine parseable.
The actual state of the system must self-correct to the desired state.
The only authoritative source for the actual state of the system is the system.
The entire system must be deployable using source media and text files.

On Buying Software
-------------------
Keep the components in the infrastructure simple so it will be better
understood.
All products must authenticate and authorize from external,
configurable sources.
Use small tools that interoperate well, not one "do everything poorly" product.
Do not implement any product that no one in your organization has administered.
"Administered" does not mean saw it in a rigged demo, online or otherwise.
If you must deploy the product, hire someone who has implemented it
before to do so.

On Automation
-------------
Do not author any code you would not buy.
Do not implement any product that does not provide an API.
The provided API must have all functionality that the application provides.
The provided API must be tailored to more than one language and platform.
Source code counts as an API, and may be restricted to one language
or platform.
The API must include functional examples and not requre someone to be
an expert on the product to use.
Do not use any product with configurations that are not machine
parseable and machine writeable.
All data stored in the product must be machine readable and writeable
by applications other than the product itself.
Writing hacks around the deficiencies in a product should be less
work than writing the product's functionality.

In general
----------
Keep the disparity in your architecture to an absolute minimum.
Use [http://en.wikipedia.org/wiki/Set_theory Set Theory] to accomplish this.
Do not improve manual processes if you can automate them instead.
Do not buy software that requires bare-metal.
Manual data transfers and datastores maintained manually are to be avoided.

Jim :)

[James Bailey]

Lol this thing get everywhere it is like an anti-cancer. Just seen your post.

Jim :)