There's a term that's rising to prominence in the IT world. It's actually a fairly handy short-hand for a complex topic. It brings together what can sometimes seem like polar opposites. It compresses into a very tiny space a great deal of meaning and symbolism. And yet…I hesitate to use the term, because it sounds so much like the kind of thing some marketing wonk would come up with. The term is so broad and all-encompassing that it freaks people out. It's so simple and clear that people think they know all that it means, and can therefore immediately dismiss it as not applicable in their situation. That term is DevOps.
Look up DevOps in Wikipedia and it will tell you that it is a software development method, but most DevOps advocates seem to come from the IT side of the chasm that separates developers from operations, perhaps because DevOps places emphasis on process and culture, two topics close to the heart of operations. However, don't go thinking that IT love the DevOps idea and developers hate it; brickbats fly from both camps.
Developers, enamored of the integrated approach described by the likes of The Phoenix Project or Continuous Delivery, would like to be able to respond to business need in business time, adding functionality when the need is recognized, instead of 6-9 months later after it's gone through the sclerotic IT purchasing and configuration process.
DBAs and sysadmins, tiring of being woken up at 3AM every day for the last week (month, year, decade) because of shaky code shoved into production too quickly, want more control over developers and what they do, with a slower, more methodical, development and deployment process.
These apparently-conflicting goals between development and IT prevent the integration process from occurring. There is also a lot of resistance to some of the new techniques meant to help manage an integrated process. Why would you want to put a bunch of pieces of paper on the wall as a means of process management? And Kanban just sounds stupid anyway. Continuous Delivery? Are you nuts? Let's just try one successful delivery. Talk to the developer/DBA/SAN admin/sysadmin? No way, that person is a total jerk who only knows one word ("No"). I don't care what some silly management book you read in the 80s said about process improvement, we're building software, not running a factory. The Goal? How about not taking the server offline, how's that for a goal?
So much resistance to such a simple idea. Let's just agree that we need to work together. Let's agree that we actually have a common goal. No, it's not to develop software or protect the database or administer auditing. Our common goal is to delivery functionality to the business so that we all keep our jobs. Yeah, that's right. The one thing we have in common is that we all support the business. So, let's team up. Let's figure out how to create a stream, a flow, heck call it an assembly line if it makes you happy, but a process that gets stuff out of people's heads, into 1s and 0s in app code, that then gets it deployed to the production box. Let's build infrastructure around this process so that we can automate the heck out of everything we release and test everything we release and even automate the tests. Finally let's make that process happen as fast as we can, while still protecting the business and minimizing down time.
And that's all that DevOps and all the related processes are trying to do. They're trying to find a way that we can cross the chasms that appear to surround us, but aren't really there, or at least shouldn't be. So, object to the name all you want. We don't have to call it DevOps. We can call it Bob or Ear or Achmed or Plug. It doesn't really matter what we call it. What matters is that we need to come up with mechanisms that satisfy the business need as accurately as we can and as fast as we can while still protecting the systems.
Homework? Pick up one of the books referenced here and give it a read. You won't find much mention of DevOps in Jez Humble's book but his book shares the same goals in terms of achieving an integrated process for software delivery. Stare at your belly button a while. Can't you, shouldn't you, attempt to reach across the chasms in your organization and figure out how to make development, testing and deployment faster, safer, repeatable and automated?
