Tag Archives: manifesto

My Take On The DevOps State of the Union

DevOps has been a great success in that all the core people that are engaged with the problem really ‘get’  it and are mainly on the same page (it’s culture shift towards agile collaboration between Ops and Dev), and have gotten the word out pretty well.

But there’s one main problem that I’ve come to understand recently – it’s still too high level for the average person to really get into.

At the last Austin Cloud User Group meeting, Chris Hilton from Thoughtworks delivered a good presentation on DevOps. Afterwards I polled the room – “Who has heard about DevOps before today?” 80% of the 30-40 people there raised their hands.  “Nice!” I thought.  “OK, how many of you are practicing DevOps?”  No hands went up – in fact, even the people I brought with me from our clearly DevOps team at NI were hesitant.

Why is that?  Well, in discussing with the group, they all see the value of DevOps, and kinda get it.  They’re not against DevOps, and they want to get there. But they’re not sure *how* to do it because of how vague it is.  When am I doing it?  If I go have lunch with my sysadmin, am I suddenly DevOps?  The problem is, IMO, that we need to push past the top level definition and get to some specific methodologies people can hang their hats on.

Agile development had this same problem.  And you can tell by the early complaints about agile when it was just in the manifesto stage.  “Well that’s just doing what we’ve always done, if you’re doing it right!”

But agile dev pressed past that quickly.  They put out their twelve principles, which served as some marching orders for people to actually implement. Then, they developed more specific methodologies like Scrum that gave people a more comprehensive plan as to what to do to be agile.  Yes, the success of those depends on buyin at that larger, conceptual, culture level – but just making culture statements is simply projecting wishful thinking.

To get DevOps to spread past the people that have enough experience that they instinctively “get it,” to move it from the architects to the line workers, we need more prescription.  Starting with a twelve principles kind of thing and moving into specific methodologies.  Yes yes, “people over process over tools” – but managers have been telling people “you should collaborate more!” for twenty years.  What is needed is guidance on how to get there.

Agile itself has gotten sufficient definition that if you ask a crowd of developers if they are doing agile, they know if they are or not (or if they’re doing it kinda half-assed and so do the slow half-raise of the hand).  We need to get DevOps to that same place.  I find very few people (and even fewer who are at all informed) that disagree with the goals or results of DevOps – it’s more about confusion about what it is and how someone gets there that causes Joe Dev or Joe Operator to fret.  Aimlessness begets inertia.

You can’t say “we need culture change” and then just kick back and keep saying it and expect people to change their culture.  That’s not the way the world works.  You need specific prescriptive steps. 90% of people are followers, and they’ll do DevOps as happily as they’ve done agile, but they need a map to follow to get there.

3 Comments

Filed under DevOps

A DevOps Manifesto

They were talking about a DevOps manifesto at DevOpsDays Hamburg and it got me to thinking, what’s wrong with the existing agile development manifesto?  Can’t we largely uptake that as a unifying guiding principle?

Go read the top level of the Agile Software Development Manifesto.  What does this look like, if you look at it from a systems point of view instead of a pure code developer point of view?  An attempt:

DevOps Manifesto

We are uncovering better ways of running
systems by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes over tools
Working systems over comprehensive documentation
Customer and developer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

That’s not very different. It seems to me that some of the clauses we can accept without reservation.  As a systems guy I do get nervous about individuals and interactions over processes and tools (does that promote the cowboy mentality?) – but it’s not to say that automation and tooling is bad, in fact it’s necessary (look at agile software development practices, there’s clearly processes and tools) but that the people involved should always be the primary concern.  IMO this top level agile call to arms has nothing to do with dev or ops or biz, it’s a general template for collaboration.  And how “DevOps” is it to have a different rallying point for ops vs dev?  Hint: not very.

Then you have the Twelve Principles of Agile Software. Still very high level, but here’s where I think we start having a lot of more unique concerns outside the existing list.  Let me take a shot:

Principles Behind the DevOps Manifesto

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable functionality. (more general than “software”.)

Software functionality can only be realized by the
customer when it is delivered to them by sound systems.
Nonfunctional requirements are as important as
desired functionality to the user’s outcome. (New: why systems are important.)

Infrastructure is code, and should be developed
and managed as such. (New.)

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage. (Identical.)

Deliver working functionality frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale. (software->functionality)

Business people, operations, and developers must work
together daily throughout the project. (Add operations.)

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done. (Identical.)

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation. (Identical.)

Working software successfully delivered by sound systems
is the primary measure of progress. (Add systems.)

Agile processes promote sustainable development.
The sponsors, developers, operations, and users should be able
to maintain a constant pace indefinitely.  (Add operations.)

Continuous attention to technical excellence
and good design enhances agility. (Identical.)

Simplicity–the art of maximizing the amount
of work not done–is essential. (Identical – KISS principle.)

The best architectures, requirements, and designs
emerge from self-organizing teams. (Identical.)

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly. (Identical.)

That’s a minimalist set.

Does this sound like it’s putting software first still?  Yes.  That’s desirable.  Systems are there to convey software functionality to a user, they have no value in and of themselves.  I say this as a systems guy.  However, I did change “software” to “functionality” in several places – using systems and stock software (open source, COTS, etc.) you can deliver valuable functionality to a user without your team writing lines of code.

Anyway, I like the notional approach of inserting ourselves into the existing agile process as opposed to some random external “devops manifesto” that ends up begging a lot of the questions the original agile manifesto answers already (like “What about the business?”).  I think one of the main points of DevOps is simply that “Hey, the concepts behind agile are sound, but y’all forgot to include us Ops folks in the collaboration – understandable because 10 years ago most apps were desktop software, but now that many (most?) are services, we’re an integral part of creating and delivering the app.”

Thoughts?

20 Comments

Filed under DevOps