I have been wanting to write a series of posts around the softer aspects of DevOps for a while now. This is the first one in this new series of posts.

Here in the UK, we often use the CALMS acronym to describe the pillars of DevOps.

In many companies today, the reality of these pillars is somewhat different though:

As you can see “Automation” is the only pillar that somewhat gets achieved in most places.

I think there are a number of reasons for this:

  • Automation is normally the quickest win out of all the pillars
  • The organisational structure does not need to be adjusted to bring automation in
  • You can send people on courses to learn about tools, scripting, and programming languages that help with automation
  • Generally the “Automation” pillar in the CALMS model is the one that can most easily be converted into a check list that can be ticked off
  • Many vendors make it look like deploying their tool (which normally primarily addresses the Automation pillar) is equivalent to implementing DevOps

That being said, let’s set up this series that aims to explain the not-so-easy-to-pin-down pillars of DevOps.