So, I tuned in at nearly the right moment to hear an extra snippet of discussion at Cloud Field Day 1 (CFD1) and it was a topic that gets my brain going. The topic was whether or not DevOps was bullshit. I’ve done quite a bit of thought on this topic and I’ve come to my own conclusions that there’s a very good chance that DevOps is pure BS.
I’m going to point to a blog post by Tom Hollingsworth (@NetworkingNerd) about specifics into the Ops side (specifically the networking angle). What I’ve found very interesting in most of my discussions with people about DevOps is that rarely do you hear from the Ops side of the equation. That makes some sense, but is awfully important to making DevOps, well, DevOps. Continuous integration and continuous deployment NEED a static environment in which to function. Without this highly static environment, you aren’t really changing much when it comes to running production applications in your environment.
The more I pondered why DevOps is so hard to grasp from an operational perspective, the more I started to realize is that when it comes to a highly successful DevOps enabled organization, I see a trend (not an absolute) that many of these organizations tackled the operational problems with greenfield environments. Not all of the components may have been completely greenfield, but the point remains that new technologies were brought in (from Operations perspective) to address the issue. If you think about it, this is what the term “shadow IT” was all about. They just greenfield’ed the application to an area in which the infrastructure was statically presented. They removed existing operational problems from their equation and got on with building and deploying new applications in a more rapid fashion.
Why is that? I think we all know the answer. We (as in those of us in operational roles) are expected to be everything to everyone with our subject matters. Whether it’s network or storage or virtualization, we have to appease every person in the business and their unique needs. This makes it very hard to start working on transforming operations internally. How is one supposed to automate their environment if you are being presented 25 different business use cases to automate in a single silo (yes, I used the word silo, but let’s be honest, silos are still everywhere). We have other tenants other than developers that we need to make happy in the business.
I’ve read through “The Phoenix Project” multiple times and this is my main problem with it: it glosses over this very detail. You never really get to understand how they made the rest of their consumer base pleased with the levels of service needed to run the business. The book only came from the perspective of making the develops the defacto tenant and to hell with everyone else. I can see now why so many in Ops roles have no clearly defined methods to really making this work because they aren’t likely to be able to focus on the applications internal developers are pushing out. There is a delicate balancing act that goes on within an IT organization and only a finite amount of hours to accomplish tasks in.
I’ll end this by stating that I’m a huge fan of what the concept of DevOps can do to an organization. On it’s very simplistic nature, it’s trying to do what we’ve been saying for years (get the applications and operators closer together and make they work together to eliminate the friction between the two groups). Unfortunately, there’s been too much focus on technology and not enough on the people and process side of the equation. Many organizations could really use a business analyst to come in and get some of these people and process issues fixed before proceeding down a path in which all you’ve done is amputate a broken arm, rather than giving it the care it actually deserves.