I have a confession to make. In the past several years I’ve implemented “DevOps” automation tools for a number of startup companies without having a clue what their business was about. That’s more than a little scary when you think about it.
Granted, I did this on their terms: These engagements were so time-critical that, despite my recommendations to the contrary, the clients insisted I just hunker down and “implement DevOps” before it was too late.
But DevOps is a lot more than tooling. DevOps is a puzzle with four major pieces that have to join up just right:
- A mindset shift
- Strong team buy-in
- Process changes and
Of these four, automation is by far the easiest to actualize. The only reason it’s perceived as difficult or mysterious is because the marketplace isn’t mature and there are 600 ways to do everything. Yet nearly all the tooling I’ve put in place for clients is generic, with little variation between implementations. Everybody needs configuration management, everybody needs a continuous integration pipeline, and so on. This is why (if you insist) I can implement your automation without understanding your business.
But here’s the big problem: By trying to hire “DevOps engineers” when truly there’s no such thing, and asking them to “build us DevOps” when that can’t be done, all you end up with is a bunch of custom automation tooling that can actually make things worse.
Think about it. You’re scrambling to “get DevOps” because you believe that, if you don’t, you will fall further and further behind your competitors and ultimately fail. But with tooling alone you won’t succeed in getting DevOps-you just got part of the puzzle-so you’re no further ahead.
Worse yet, the new automation frequently doesn’t fit your business needs and isn’t understood by any of the people who are supposed to be “doing DevOps.” So it just adds complexity to the stack, frustrates and confuses your team and wastes precious time and resources… especially after that DevOps white knight you hired rides off to greener pastures along with his or her expertise.
What organizations that “need DevOps” should be focusing on instead of tooling is the other three pieces of the DevOps puzzle-because these are the bits that really are company-specific. And if you bring in an automation engineer to help with your tooling, take the time to explain to him or her about your business needs, so that they can ensure the automation fits with the rest of your company’s unique DevOps puzzle.
If you’re looking to create a DevOps team in your organization, drop us a note. We’d love to help you get the tooling right, and the other puzzle pieces, too. We’ll do whatever you need us to do, but please don’t tell us to “just shut up and give us Puppet so we can do DevOps.” Because that would be wrong.