In May I was able to attend DevOps Days Austin and last week I attended O’Reilly’s Velocity in Santa Clara. Anyone that is involved with hosting technology has run into the phrase/word “DevOps.” Usually it results in a little head scratching and then questions around “what is DevOps?” Good question. The honest truth is that we (as in the larger technology industry “WE”) are still trying to figure that out. Both DevOps Days and Velocity dive into the tactical aspects of DevOps but I wanted to focus on the overall thought process of DevOps.
I started my career at Rackspace as an Account Manager on the support floor tied to a Linux team. When cloud hosting started becoming a larger percentage of the market, tech geeks would figure out really cool things to do with it. Not only could you have more flexibility in terms of spin up/spin down times but you could also scale very easily. This led to the market of configuration management. Our teams often use configuration management such as Ansible, Puppet and Chef. The next challenge was how do you identify an area of the business or a specific system administrator that is proficient in these configuration management tools? Voila! Call them DevOps! You see this existing within Rackspace as well as across our industry as a whole.
This is on the support side but what about in product organizations? I mentioned that I started my career at Rackspace on the support floor but these days I hang in the wings of our Product Department as Manager of Engineering Operations. Moving from support to product has provided a fantastic learning experience in ways of thinking as well as organizational structure. The next obvious question of what does DevOps mean in a product organization? Well, there’s “Dev.” We have developers. There’s “Ops.” We have operations. I would ask that you, the reader, try on the concept of DevOps as a way of thinking. Within operations it is expected/required that the engineers and administrations have experience with configuration management due to the security and efficiency that configuration management provides.
The DevOps State of Mind is a more collaborative way to make a product a reality. The old school methods used to be developers wrote code in their silo and threw that code over to the wall to operations, who then had to try and figure out a way to maintain and stabilize the product. They would make their “this can’t work” comments and throw it back over the wall to the developers. Rinse. Repeat. Now you see a more collaborative process happening. Collaboration goes along with popular project management such as Kanban, including methods like sprint planning which provides a good structure for collaboration. Now you have the developers talking about a feature they think would be awesome, and operations comes in to say “if you’re going to do that, remember that we need to keep with these x, y, z standards.” This process not only provides a closer-knit process = higher engagement, but also hits the bottom-line in a hard way. If you delete the endless throwing codes/ops standards over the wall, you are able to take back a ton of time, which equates to money and for a bonus you beat the competitors to market. Yay for first to market!
So next time you are looking at both your support and your product organizations, ask yourself “Am I in a DevOps State of Mind?” Check out conferences like DevOps Days and Velocity to better understand how to get to that state of mind and then to get there in a tactical way. If it helps, throw on that Billy Joel song for inspiration.