Don’t “Do” DevOps. Solve Problems.

Don’t “do” devops. Solve problems.

That was the advice I gave at DevOps World | Jenkins World last week in San Francisco.  It deserves more time and words than I could give it then.

The popularity and success of “DevOps” marketing is wonderful in many ways.  For one, explaining my resume is easier than it’s ever been.  But, like agile, the success of the buzzword has created new problems, such as unrealistic expectations among management and confusion about who should be “doing devops.”

Agile and devops concepts/culture/practices didn’t evolve in a vacuum.  They grew out of people solving old problems in new ways or needing solutions to new problems.  This context is critical.  Consider the two statements.

1. Our management created a DevOps transformation initiative, so we implemented an Infrastructure as Code approach for our simplest test environments to show progress.
2. We saw a lot of human error manually coordinating test infrastructure for all the components in one of our critical applications, this led to testers often not having a working app to test, so we automated provisioning and deployment across all components in order to eliminate the bottleneck for testing.

One of those is “doing” devops and one of them is solving problems.  One of them is easy, safe and ticks a box in a status report somewhere.  One of them is difficult, potentially disruptive and could cause even more delays until it works, but ultimately eliminates waste and brings real value to the business.

I’m not saying to ignore devops ideas–absolutely learn about them!  Then you can apply those ideas to their best effect in your specific context to solve your problems.

But declarative Infrastructure as Code is better than spaghetti automation!

Maybe.  No one wants spaghetti code, but working is better than elegant. I agree that IaC is a great approach, but if it’s not solving an immediate problem and delivering value, maybe it’s not the right time.

But we can’t afford to add risk to our critical application and the infrastructure that tests it!

Anything that’s important to the business will involve risk.  Why can you afford to be working on things that aren’t important to the business?

Surfacing the difference between #1 and #2 to management and getting agreement at the right levels can be difficult.  I think it’s a worthy cause.