Codifying DevOps

[Guillaume FORTAINE]

Hello,

For your information :

http://java.dzone.com/articles/codifying-devops

Best Regards,

Guillaume FORTAINE

[bongo]

For starters, it's "DevOps" not "Devops" or "devops".

Secondly, link bait spam.

Finally, I am yet to find someone who is a consultant - especially one of 15 years - who is well endowed enough with experience and the know how of current industry trends and best practices, to write a blog post on how companies should be practicing said best practices. Consultants are usually last to the party, clean up all the free booze left around, and are too busy taking photos of the party while everyone is off someone else.

I am really not impressed.

[Stefan Goethals]

Funny....

[Stefan Goethals]

That 'Funny' was about bongo's silly reply...

[Evan Bottcher]

wait… I'll just get some popcorn...

[David Lutz]

I've got marshmallows...

;-)

[Gildas]

David,

I just wanted to point that the article was actually written by
Patrick Debois, who invented the term devops (and as far as I know he
prefers it with no capital letters) as he organised the first
devopsdays in Gent in 2009.

You might not agree with the way he tries to formalize it (myself I'm
not a big fan of the formalism) but I think he has all the legimacy
required to try and do it.

Regards,
Gildas

On Tue, May 22, 2012 at 1:26 PM, bongo <da...@sonicb.com> wrote:

[Matt Ryanczak]

On 5/22/12 7:26 AM, bongo wrote:
> I am really not impressed.

...with this reply. Yet another example of how the ongoing tone of this
list defeats any meaningful discussion...

[Matt O'Keefe]

Maybe "bongo" is a "brogrammer" who practices "BroOps" who's sensibilities were offended? He does mention booze and parties... :)

[Matt Joyce]

Please let us not impune he rich culture of the noble bro.

[bongo]

Haha, BroOps, I love it.

Sorry guys - it was tongue in cheek and (what I thought) full of sarcasm. I have to agree with Gildas on his thoughts with formalism, as I try and to optimise and simplify my day job (and all things in life).. but it's awesome to see people see building and stretching and thinking outside of the box of devops.

:)

[mpron]

Just wanna make sure everyone knows that this was posted with the
written permission of Patrick DuBois. Great guy. See source links in
the author block at the top and under the tags at the bottom.

Now, back to the debate.

[Patrick Debois]

Hi David and list,

I can't apologize for the fact that I'm consultant, that's just the way
it is.

The fact that I accidentally came up with the term devops doesn't give
any more credibility than anyone out there. What I think about the name
should be in uppercase or lowercase is even completely irrelevant.

I can't help my passion for devops and I will not apologize for it
either: it drives me to organize devopsdays and blog and tweet about it.
Feel free to ignore my opinion in any way.

I totally understand that while reading the blogpost, your bullshit
detector kicked and as a matter of fact it totally should! You should
not believe anything on the internet without giving it good thought.

From the beginning that the term "devops" was used, there has been
endless demands ranging from a Devops Manifest to a definitive
description. It always made me cringe at the idea: whatever you write
down can interpreted dogmatically. During my 20 years (yeah I should
update my blog), I've seen this happen to Itil, Agile or whatever ideas
are out there. Before you know it , it can lead to hollow things like
"devops" training or "devops" certification But I beg to say that those
'framework' by themselves aren't good or bad. It's the dogmatic
application of the ideas that give them a bad name.

On hindsight, not having a specific definition has proven a good thing:
it allowed the community of ideas to grow and expand. Discussions that
happened on this mailinglist like "you're not using a configuration
management, so you're not devops" really make me sad. I want to keep
expanding the ideas. No matter what your definition of devops bring your
ideas to the table! I've always quoted: "Cloud has more than 40
definitions, does it make it any less useful?"

But here's the real dilemma: people new to the subject are asking me
over and over again , do you have any references or sources of
information we should read? Only being able to answer follow the twitter
hashtag or search google, didn't feel right either. After many
consideration (almost 3 years now) I finally became convinced that the
benefits to bundle all the information outweighs the danger of people
taking it prescriptive or applying it narrow minded.

Enter my blogpost: because I'm so sensitive about this matter as well
(like my other co-authors), I decided to put our current train of
thought on the web. A few tweets later I started noticing people were
kind of silent about it, not sure what to think about it. Did Patrick go
to the darkside? Rest assured I'm a jedi and will be a jedi4ver.

There is not intend to be pre-scriptive! I know it's a long article, but
if you were to read it to it's full extend you will see I explicitly
don't want that to happen! I apologize if this was how it came across
but I think if it's just the skeptic reflexes kicking in.

We are grouping interesting "devops" stories and practices together. So
people can find them in one place. Many of these stories seemed to be
one-offs tricks/hacks. Hard to structure in a book. For me personally
the structure of the areas made me help to group the stories. Also it
allows to think about layers (like people and process) we are giving
less thought than merely tools. The fact of the maturity levels was a
side effect; I literally mention: "they are useless if you want to lie
to yourself or your colleagues"

But enough of my reasoning, what could we do to improve it? Please tell
me your worries (that is on it's content :).

I make no plea to agree with me, just to learn and understand.

Patrick

[Gildas]

On Tue, May 22, 2012 at 4:55 PM, Patrick Debois
<patrick...@gmail.com> wrote:
> Hi David and list,

Hi Patrick,

[SNIP]

> From the beginning that the term "devops" was used, there has been endless
> demands ranging from a Devops Manifest to a definitive description. It
> always made me cringe at the idea: whatever you write down can interpreted
> dogmatically. During my 20 years (yeah I should update my blog), I've seen
> this happen to Itil, Agile or whatever ideas are out there. Before you know
> it , it can lead to hollow things like "devops" training or "devops"
> certification  But I beg to say that those 'framework' by themselves aren't
> good or bad. It's the dogmatic application of the ideas that give them a bad
> name.

Yes and I'm sure the people who wrote stuff about Agile were adamant
saying their presentation should not be taken dogmatically, and still
it was :)

[SNIP]

> But here's the real dilemma: people new to the subject are asking me over
> and over again , do you have any references or sources of information we
> should read? Only being able to answer follow the twitter hashtag or search
> google, didn't feel right either. After many consideration (almost 3 years
> now) I finally became convinced that the benefits to bundle all the
> information outweighs the danger of people taking it prescriptive or
> applying it narrow minded.

[SNIP]

> There is not intend to be pre-scriptive! I know it's a long article, but if
> you were to read it to it's full extend you will see I explicitly don't want
> that to happen! I apologize if this was how it came across but I think if
> it's just the skeptic reflexes kicking in.
>
> We are grouping interesting "devops" stories and practices together. So
> people can find them in one place. Many of these stories seemed to be
> one-offs tricks/hacks. Hard to structure in a book. For me personally the
> structure of the areas made me help to group the stories. Also it allows to
> think about layers (like people and process) we are giving less thought than
> merely tools. The fact of the maturity levels was a side effect; I literally
> mention: "they are useless if you want to lie to yourself or your
> colleagues"
>
> But enough of my reasoning, what could we do to improve it? Please tell me
> your worries (that is on it's content :).

I think it might be better to present this as a "devops fieldbook"
instead of trying to structure/derive laws/rule from the different
stories you have and then articulate the book along those laws/rules
(1).

You can organise chapters based on the value or difficulty you
(writers of the book) affect to each story, if you want to provide a
sense of progression. People will understand it's not prescriptive and
you don't have to define a target/ideal like they have in CMMI and
such.

I believe devops is a journey. And I believe there's more value in the
journey itself than in an hypothetical target/goal/ideal.

Cheers,
Gildas

--
1- something along the lines of what was done in the "5th discipline
fieldbook" http://www.amazon.com/The-Fifth-Discipline-Fieldbook-Organization/dp/0385472560

[Matt Joyce]

I think any attempt to codify devops at this point is both premature and ultimately destructive.  At the very least codify some guidelines to follow before setting stuff in stone.  Ala, do not tie devops codes of conduct to existing technology or paradigms.

Scalability and adaptability are what tech is all about.  Operations is the duct tape that keeps our world's data moving.  And to be duct tape we cannot be specialized.

[Jaime Gago]

Unless the specialization is being the duct tape, that is what "Devops is a journey not a destination" means to me. Another way to put this is we change specialities all the time, that is our speciality.

J.

[Matt Joyce]

try selling that to a cto.  i'd love a video.

[Miles Fidelman]

Any CTO who prefers a packaged methodology over doing some homework and
tailoring technology/process to the specifics of their business, is a
CTO to be avoided. (And boy, if you hear your CTO talk about "total
quality management" or "six sigma" - that's the time to run for the
door. c.f. Dilbert for references to "stink like a dead weasel").

--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra

[Joe McDonagh]

Not sure I see the connection between Six Sigma and this kind of
mentality...

Joe McDonagh

AIM: YoosingYoonickz Google: Joseph.E.McDonagh
IRC: joe-mac Skype: therealjoemac

[Eric Shamow]

On Tuesday, May 22, 2012 at 1:09 PM, Miles Fidelman wrote:

Any CTO who prefers a packaged methodology over doing some homework and

tailoring technology/process to the specifics of their business, is a

CTO to be avoided. (And boy, if you hear your CTO talk about "total

quality management" or "six sigma" - that's the time to run for the

door. c.f. Dilbert for references to "stink like a dead weasel").

Any methodology can be misapplied or broken badly.  Agile is very often misapplied as has been pointed out elsewhere on the list - it doesn't mean that Agile as a methodology is worthless.  The same is true for Six Sigma.

-Eric

[Henk Langeveld]

On 22/05/2012 17:43, Gildas wrote:
> I think it might be better to present this as a "devops fieldbook"
> instead of trying to structure/derive laws/rule from the different
> stories you have and then articulate the book along those laws/rules
> (1).
>
> You can organise chapters based on the value or difficulty you
> (writers of the book) affect to each story, if you want to provide a
> sense of progression. People will understand it's not prescriptive and
> you don't have to define a target/ideal like they have in CMMI and
> such.
>
> I believe devops is a journey. And I believe there's more value in the
> journey itself than in an hypothetical target/goal/ideal.

Indeed, as with Agile and Lean, continuous improvement is an essential
part of Devops.

Just the other day Alan Shalloway mentioned the paradox of
"standard work" on the kanbandev list:

> To best understand this, let’s look at two quotes from Taiichi Ohno:
>
> * "No standards no kaizen"
> * "I told everyone that they weren't earning their pay if they left
> the standardized work unchanged for a whole month"

http://www.netobjectives.com/blogs/standard-work-why-we-need-it-0

For certain things, we do need standards, but as we improve things,
the standards may become stale. But before you get into that rythm,
it may help to just do what others have shown works.

Cheers,
Henk

[Matt Joyce]

To put it my own way...

Tell a person not to do something, they will want to do it.
Tell a person they should do something, they will avoid doing it just to spite you.
Show a person something works, and they will adopt it immediately.

Leadership by example is the only leadership there is.

-Matt

[Ernest Mueller]

At 06:16 PM 5/20/2012, Guillaume FORTAINE wrote:

>http://java.dzone.com/articles/codifying-devops

Hmm, I did ignore this as link spamming at first too. But now having
read it, I like it in general, I think a little more definition of
DevOps can help.

(Note, I started this email and left, and now there's a long "but is
it VALID to put people in BOXES using DEFINITIONS" kind of argument
when I came back. I don't think much of that. I believe a lot of
what's wrong with Ops right now is that it's protested too much that
it's an undefinable art and has therefore been 10 years late to the
game to uptake best practices well understood in even that 'cowboy
dev' world. Yes, you can define things and definition is useful,
though threatening to craftsmen, even master craftsmen.)

To respond to the actual article, which seems to not be attempted yet...

1. Devops in the right perspective

This is the one part I disagree with, sad since it's the
first! "DevOps as breaking down silos everywhere in the
organization" is hubris. That's called agile. DevOps is indeed the
focus on the relationship between dev and ops at the product
level. And there's nothing wrong with that. The movement grew out
of the agile operations movement for a reason. The core observation
that the same collaboration is needed in other areas is correct, the
generalization of DevOps to that is not. It's like security people
that say "well CIA, Availability is part of security so hey we should
be figuring out the load balancing and scaling!" You pat them on the
head, say "Sure, sure; now let the people who are actually experts in
that area work."

So yay for agile collaborative organizations; but it's not "Big
DevOps," it's that DevOps is one particular sticking point within
that larger framework that requires a lot of specific work.

2. DevOps Areas

I like these, I think Ben Rockwood's diagram helped me explain to
many people why DevOps isn't just one of those things and I agree
with this extension of it. Well done.

3. Area Layers

I like this OK. It seems very bottom up though. I think there's
some clear devops principles->methods->practices that go top down
from vision just as there are agile principles (e.g. manifesto)->
methods (e.g. Scrum)->practices (e.g. sprints, backlogs, planning poker).

4. Area Maturity Levels

Don't mind this but I agree in shying away from CMMI. No one uses
that crap even for dev any more. Even when it is used it's mostly just abused.

5. Area Indicators and Scorecard

Turning it into metrics is very needed and helpful. We are extremely
metrics driven at my current company - we contribute them and then
every week there's a 90 minute meeting where the entire management
team up to the CTO review them and ask in depth questions.

6. NOOPS

Please don't take us one step forward, two steps back with
incorporating an even more poorly defined term than DevOps. I
venture to say "working with product teams outside your company" is
similar to no NoOps definition I've ever heard before.

7. CAMS and Areas

This peters out without a whole lot of explanation, I don't know if
it really "maps" so much as "is representable with a similar diagram
for branding purposes" (which is fine)...

Ernest

[James Holmes]

The key to Agile culture (including devops, lean and anything else we choose to call Agile) is the Shu Ha Ri principle. If people can't see a "standard" set of tested, working practices, they'll have a tough time evaluating what to keep and what to throw away. This appears dogmatic at first; the point is that once the set of practices have been mastered the practitioners are then free to change them, discard them and invent new ones.

The benefit of this is that not everyone needs to fully understand up front why the whole set of techniques exists. They'll work this out themselves over time by actually doing them. This gets the team up and running with their adoption immediately and leverages the experience of those who've come before them, rather than expecting each new team to reinvent the wheel.

[damone...@gmail.com]

I see your point about being careful of DevOps being heralded as a panacea for all ills. But DevOps isolated to just the point of contact between Dev and Ops isn't the answer either.

You could say the macro perspective is "Lean" in it's purest form, but DevOps has as much claim to it in the technology realm as Agile does. The only proof I need that "big picture" isn't properly represented by Agile is that the Agile movement has been around for a long time (in "tech years") yet completely missed the big picture that you needed the align and optimize the entire development to operations delivery cycle to properly implement Lean in a software as a service world. Sure you can reference a handful of sharp folks who have been saying this all along… but the vast majority of the thought, effort, dollars, and time that has gone into Agile has resulted in a prescriptive methodology for software development that starts with requirements and ends with "code complete". I'm sure the purists will cringe at this and the manifesto will roll over in it's grave… but that is where that movement has gone. It's become a local optimization that doesn't address the "global" concern of the development to operations delivery cycle (i.e. what the business actually cares about and pays for)

Now on to DevOps… Are we not doomed to repeat the same mistake if we don't take the all inclusive holistic approach? The whole point of having a "dev" and an "ops" is to take business ideas and manifest them as running features for customers. What's the point of the "focus on the relationship between dev and ops at the product level" if it doesn't optimize the whole system to achieve it's purpose? In order to optimize that relationship for that purpose you have to include all the pieces that must come together to make that happen. That doesn't mean that everyone has to be a generalist in everything (your example of conflating security and availability), but it does mean that everyone has to understand the system they are a part of and how to work together to fulfill the purpose of the system.

When the original DevOps conversation started, it was taking a broad system-wide view. The two seminal events both talked about Dev and Ops as if they were the entire technology house split into two sides. Paul Hammond (Dev) and John Allspaw (Ops) represented the entire Flickr technology team (at least figuratively if not literally). The first DevOps Days in Ghent was framed as bringing together the two self-identifications that rarely gather at the same conference, Dev and Ops.

Post DevOps Days Ghent the conversation definitely became deployment centric. Why? Because deployment is the canary in the coal mine for a broken development to operations lifecycle. It's the flash point where the pain is felt, but the root cause of that pain comes from somewhere else.

Now that I'm 5 paragraphs into a rant… :)

I'm realizing that I probably should have asked what you meant by "focus on the relationship between dev and ops and the product level"? Can you provide examples of what is and isn't in scope by that DevOps definition?

[Erik Hollensbe]

All I took away from this entire thread, was that DevOps is to systems people what Web 2.0 was to designers.

To be completely unmistaken: folks, it's getting warm on this list from all the hot air.

I won't speak for anyone but myself, but it'd be nice to get back to talking about actual technology that serves the needs of people straddling the development and operations divisions in companies.

Don't blame me for the rage; blame Phil Hollenback, it's all his fault for egging me on. :)

-Erik

[damone...@gmail.com]

Being concerned with improving process and organizational dynamics = hot air?

That is like saying that rather than studying "hot air" like TPS, Lean, ERP, or Operations Management the business world would have been better off if everyone just focused all that effort on building better robots.

Pick any company that you would consider to be a low performing organization and drop off the exact list of tools used by Etsy or Amazon. Would they suddenly perform just like Etsy and Amazon? Of course not. Why? Because they didn't understand all of the stuff you are calling "hot air".

[Eric Shamow]

Erik,

You may do better on the devops-toolchain list, which although relatively inactive of late, is intended for specific discussion around tooling.

For better or for worse devops is as much if not more a management/cultural issue than a tools-based one.  The tools only exist to facilitate the culture change.

-Eric

-- 

Eric Shamow

Sent with Sparrow

[Chad Woolley]

"M" is the mute thread hotkey in gmail...

[Noah Campbell]

That's why there is devops-t...@googlegroups.com, so tool discussions can rage on in their full gory detail.

-Noah

Noah Campbell
415-513-3545
noahca...@gmail.com

[Gmail - benkrueger]

Honestly, tools are well and good and necessary, but engineers aren't good at things like building reliable bridges and skyscrapers solely because of their tools. It's because of all the icky, gooey, sometimes painful process maturation, codification, and scientific rigor they've spent a very long time refining. Who wants to cross a bridge built by engineers that consider this kind of stuff "hot air"? I can't speak for anyone else, but I consider pursuing that kind of professional maturation to be the greater mission here.

[ranjib dey]

i have found to keep the toolchains and principles or methodologies tied together, It helps me explaining how the principles are implemented or practiced in day to day life. I agree the a tool only communication should happen in the different group, but it does not harm to mention them in this forum as long as they add value to the communication. 

Also, our individual perceptions are derived from our own experiences, which differs vastly. I am not as  experienced as the other in this thread, but i have seen places where the major bottle neck was culture or process or mindset. But i have also seen cases where practicing devops is difficult primarily due to the tech stack or tools. Note, its not impossible may be, but it considerably difficult compared to other stacks. So, as long as we dont restrict the scope of this movement to only certain use cases or domains, both methodology as well as tool chain specific learning are important. Their proportion might differ case by case.

[ranjib dey]

Sorry for the horrible english. Rephrasing it.

i have found keeping the toolchain and principles or methodologies together works well.  It helps explaining how the principles are implemented or practiced in day to day life. I agree that a tool only communication should happen in the different group, but it does not harm to mention them in this forum as long as they add value to the topic. 

Also, our individual perceptions are derived from our own experiences, which differs vastly. I am not as  experienced as the others in this thread, but i have seen places where the major bottle neck was culture or process or mindset. But i have also seen cases where practicing devops is difficult primarily due to the tech stack or tools. Note, its not impossible may be, but it considerably difficult compared to other stacks. So, as long as we dont restrict the scope of this movement to only certain use cases or domains, both methodology as well as tool chain specific learning is important. Their relevance might differ case by case.

[James Bailey]

On 23 May 2012 11:09, Gmail - benkrueger <ben.k...@gmail.com> wrote:
> Honestly, tools are well and good and necessary, but engineers aren't good at things like building reliable bridges and skyscrapers solely because of their tools. It's because of all the icky, gooey, sometimes painful process maturation, codification, and scientific rigor they've spent a very long time refining. Who wants to cross a bridge built by engineers that consider this kind of stuff "hot air"? I can't speak for anyone else, but I consider pursuing that kind of professional maturation to be the greater mission here.
>

DevOps has always been about more than just the tools. It is
phenotypically similar to "Operations Management", Ben Rockwood has
written an excellent blog post about this and I can heartily recommend
it and some of the reference material in the article.[0]

Good Operations Management knowledge brought systemic order and
efficiency to organisations involved in the physical manufacturing
technologies of the last 3 centuries. This wisdom was written down
and distilled into the books you can buy today. So DevOps in it's
place and time has naturally grown from within the information
technology industry. Being a child of the 21st century the blogs came
first from Patrick, Ben and many others, the books and the courses on
how to do DevOps are following, all of this will codify DevOps.

Embrace it!

Jim

[0] http://cuddletech.com/blog/?p=642

[Ernest Mueller]

Well, but Agile hasn't dropped the ball - it's
just that it's just now getting around to us.
When you look at the actual big picture there's a
lot to it. The Agile Austin group, for example,
has SIGs on agile dev, agile QA, agile
architecture, agile product development, agile
UX, agile leadership... And now DevOps. Just
because now we're down with the concepts that are
new and shiny to us doesn't mean we now know how
to fix all the other parts of an organization.

Going and looking at the first diagram in
Patrick's article - no, optimizing the
relationship between HR and Sales is not
"DevOps." That's ridiculous. It's overreaching
IMO just like my security example. DevOps isn't
just chef and puppet, or just about deployment,
but I think its focus is realistically on the
part where ops is actually embedding into the
rest of the organization instead of being a
segmented sideshow and optimizing the process of
actually delivering services. Yes, dev and ops
represent the "two sides of the technology house"
- and I think Ops can properly be understood to
rep Net and Sec and all that as we move forward -
but the scope is not "everything in an
organization all the way to HR and Finance." Ops
is waking up and smelling the coffee here, not
inventing coffee. The expansion dilutes the
usefulness of the focus. DevOps isn't
lean/agile/OM but better. It's an application of
those principles to a product team creating and delivering software.

The next DevOps Areas part I think is
great. It's the initial "well DevOps is
everything!" thing that sounds like consulting gig scope creep to me.

Ernest