Four Pillars of DevOps – Presentation at Agile Cambridge 2014

I was fortunate enough to make my speaking debut at Agile Cambridge 2014. Follow this link for session details.

I attended Agile Cambridge 2013 and was inspired to speak at the conference. I chose to speak about DevOps as I’ve done a fair bit of investigation into the subject and on my travels found some alarming trends and missed opportunities.

I wanted to present a clear definition of DevOps that reflected the current trends in the industry. I felt none of the definitions I found covered the essence of DevOps:
All of these definitions are fixed on the idea of separate teams for Dev (software engineering) and Ops (technology operations). None of these definitions covered a third major area: quality assurance.
Often, however, conversations around DevOps lead to tools. No doubt this is partly because vendors need to advertise and promote their products and also because companies need to obtain these skills, but how do we as practitioners know we need them in the first place?
As for the Four Pillars, I defined these as:
  • Platform – the tools, infrastructure, containers and environment configuration, including the state of that configuration (e.g. the state of data in the database)
  • Deployment – the practice of deploying a built software artefact onto the platform
  • Testing – lots of test types, triggers and frequencies
  • People – the people who make the three pillars above happen and how they might be organised

The first three pillars may have a mix of manual and automated steps. The fourth pillar, people, are either performing the manual steps or developing the automated alternatives (perhaps with the assistance of tools). It’s not enough to say “manual or automated”, we need to ask how rapid, how repeatable and how reliable.

  • Rapid – how quickly a particular step (or series of steps) is performed. Quicker usually means more investment.
  • Repeatable – can it be run over and over again? For example, some tests may be destructive or at least change the baseline data state in the database. Do we need to roll-back to a known state or can the tests be written in a more flexible way? Again, this usually means more investment.
  • Reliable – when the steps (or series of steps) is performed will it reliably run to completion. There is absolutely no point in automating something flaky. It will just get ignored and wastefully consume time and resources.
In triggering these steps or developing the automation, the people performing these tasks must have control, i.e. self-service. This may sound a “no brainer”, but it’s rarely the case. Often someone else does the deployment, or someone else develops the deployment scripts, or someone else runs the tests.
In terms of levels of investment and in organisation of people, I mentioned a few trade-off sliders and some organisational tensions:
  • Do we need to automate? What level of service are we hoping to achieve? Is there sufficient investment available? Perhaps define the level of service as NFRs (non-functional requirements) to define them as attributes of the product to be delivered. E.g. deploy new release to production weekly.
  • Do we manage people by capability as separate teams or do we organise people around products that are important to the organisation? Breaking down barriers to communication is an important goal in any organisation, but is it more important to bring the people working in a certain way together or is it more important to bring the people working on a certain product closer together?
  • Should we invest in standard practices (to promote cost savings) or invest in innovation (allow different ideas for different products to flourish)?
In conclusion it is not one size fits all: there are two main ways to organise and organisations should use both:
  • By product. Provide permanent multi-discipline teams to develop and manage a product at all levels. Essentially a sub-organisation itself. These teams may require expert/specialist support from outside the team from time-to-time, but as a whole the team should be self-sufficient. These teams would focus on the mission critical products: those products that are most important to the success of the organisation. “Bring the people to the work.”
  • By capability. Provide permanent teams offering an ongoing capacity & capability. These teams organise around the capability they have and may be dependant upon other teams for delivery. Some of this capability could be outsourced. These teams would work on a particular product for a short time, then move onto another product. Changes to a particular product would have to be scheduled into the available pipeline. “Bring the work to the people.”

By having a choice of model organisations are better equipped to organise according to priority. If the product is mission critical, organise around that. Otherwise it is more important to standardise and equip teams to deliver through a particular capability.

Finally, the new definition for DevOps I offer is…

DevOps is an approach to streamlining the deployment and operation of a product on the production platform. This is enabled through removing barriers to communication, providing self-service operations and automation of steps for a rapid, repeatable and reliable product delivery pipeline.

A DevOps Engineer is a master of this approach and an expert on the tools that enable the automation of the pipeline, preferably operating in a coaching capacity.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s