First post - I’ll get better, I promise!

I started out writing about DevSecOps, and came up with a tldr; diagrammatic description of what DevOps is. So, here it is on it’s own:

Devop isn’t about technology,it’s about ownership and responsibility. While DevOps is usually enabled and implemented via good technology, if you think it’s about technology you’re missing the point!

Devops is culture/management, not technology.

• DevOps is Vertical Integration of Technology Systems.
  • We don’t go we don’t separate responsibilities across time
  • We do not separate responsibilities by tech stack layer

In Pictures: DevOps, The Union of Development and Operations.

First, there was a stack

Most technologies are built or running on other technologies, themselves built or running on other technologies.

Next, specialization divides up the pie

Most companies like to split out the responsibilities for these layers to different specialized people or parts of the company.

For instance,

• Information technology (IT) runs the Hardware and Supplies the Operating Systems (OS),
• database administrators (DBAs) run the databases
• systems administrators (sysadmins) configure and run the OS Infrastructure.

Finally, developers do their thing with the application.

Life cycle Maturity Phases

Life cycles and Pipelines Gonna Flow

So, put the stack aside for now because we have another dimension to think about: Time.

Many systems are developed and operated in a linear pipeline or development process. First they are in a “development” state, then they move to a “test/QA state”, and finally to a “production state”.

A component can be in each of these states, and often owned by different people and operated in separate environments depending on the state it is in.

Note the colors indicating the life cycle state, they’ll be important in a moment.

There be dragons - But they’re not my responsibility!

Specialization/Separation up and down the stack, combined with Specialization/Separation across the deployment/operations states gives you this:

Who owns and is responsible for each thing at each time? Good luck figuring that out without a RACI.

Devops to the rescue?

Devops simply gives the whole thing to the same team, in both dimensions.

• Who is responsible for X? - Developers
• Who is blocking it because of Y - Developers
• Who decides to take risks around Z? - Developers

Developers, Developers, Developers. Steve Ballmer would be proud!

A Couple of Devops Readings:

• Why Everyone Needs DevOps Now: My Fourteen Year Journey Studying High Performing IT Organizations - Gene Kim
• Automation and DevOps Best Practices - Rob Hirschfeld, Dell & Matt Ray, Opscode

Prologue musings: Is specialization an antipattern?

No specific claims here, just leaving some thoughts. - feel free to https://twitter.com/secvalve

While writing this, thinking of DevSecOps, and discussing with a friend, it occurred to me that specialization might itself be an antipattern in many situations…. After all,

• It’s not common to have dedicated experts in UX, performance, or accessibility, so why is it so common to have a security person?
• The aim is to manage the emergent property, you don’t care how it gets there

Specialization has positives and negatives:

• Pluses: specialists tend to be better at the specific thing, and have a more specific responsibility that is theoretically less open to conflict of interest.
• Specialists may not be useful to the team outside of their specific expertise, and can be somewhat unconcerned with the holistic interest of the whole system over the whole life cycle.

Kate P