skeptic's blog

Great DevOps articles

Nobody reads books any more. They come thick and fast, and few of us have the time or the attention span.

So forget my post on great DevOps books to read and enjoy this one on seminal DevOps articles and posts. Never mind the meat and vegetables, have some snacks.

Describe DevOps with CALMS, or I prefer CAFFS

A common acronym used to describe DevOps is CALMS: Culture, Automation, Lean thinking, Measurement, Sharing. Or I prefer CAFFS...

Two kinds of DevOps: horses don't grow horns

© Copyright canstockphoto.comThe DevOps principles apply to horses and unicorns, but we act on them in different ways, even for different goals.

The cult of DevOps

Several times recently I got the message (overtly or subliminally) that if you don't work with software and tools you can't understand DevOps, that if you haven't immersed yourself in the sacred waters of cutting code then you are somehow unenlightened.

Victims of the system

Most people who seem to be blocking progress are in fact well intentioned and trying to do the right thing but they are victims of the system in which they work.

Great DevOps books to read

As if anyone reads books any more. I'm drowning in great books to read while the Internet gives me endless distractions. My attention span is shot to hell, and my memory has been replaced by Google.

But sometimes I find a few minutes and here are some of my favourites for understanding this beast called DevOps. [Updated 13/8/2016]

Reflections on the DevOps Enterprise Summit UK 2016

I just got back to the last rock on the planet, all the way from London and the DevOps Enterprise Summit UK. It was worth all the travel. IT Revolution run a great event.

Who owns DevOps?

There is currently a tension in the DevOps world, between influential purists saying you cannot define, codify, or certify DevOps, and most of the world saying it is bloody well going to anyway if DevOps is to be useful in the mainstream.

Don't reorg for DevOps

The point of DevOps is to span silos not create new ones.

I'm seeing too much of enterprises assuming one of the first steps of DevOps is a reorganisation.

If DevOps is about collaboration across silos, how does rearranging the silos help? DevOps isn't about org structures.

Challenging the operational rites

Over time a strange set of rites and rituals grow up around the Require-to-Deploy value stream*. Some of them are there to protect the quality of the output but others have ceased to add value.
Image

Syndicate content