August 26, 2010
Alright, several people have asked me why I haven't weighed in on the current "devops" movement. Mostly because no two people can absolutely agree on what DevOps is. I'm outside of that particular community, although I read a lot of the blogs of the key members, so maybe I'm in a good position to comment on my perspective.
First, lets define DevOps. If you strip away all of the touchy-feely stuff that gets associated with the name, at its core, DevOps is an increased interaction and interdependency between developers and operations staff, whether that operations staff is specifically system administrators or whatever.
This means that the people who develop code no longer have willful ignorance of operational environments, and the people who operate the environments can't do so in a vacuum of knowledge about the software itself. This increased communication and reliance IS DevOps. That's it. Nothing more. It's a methodology. It's not a panacea and it's not for everyone. How can you tell if it's for you?
Let's answer some questions...
- Does your organization have programmers?
- Do you provide Software as a Service?
- Do you release software updates frequently?
Developers are necessary for the DevOps relationship...otherwise you've just got Ops
DevOps grew up in the web world, around places like Flickr, who provide applications over the web. Other people may just think of them like websites, but in actuality, they're applications with incredibly large code bases. Since a solid application depends on well-developed code running in a known stable environment, it's natural that this kind of biosphere would produce methods like DevOps
If you're in an environment where something is broken and gets fixed immediately, then you can say yes here, but it's not just bug fixes. Features get rolled out, pulled in, and switched around. Agility of this nature isn't possible without everyone working from the same playbook. It's also not possible with an environment that can't change rapidly to match the code.
For the 90% of companies out there without that particular environment, then you probably aren't using DevOps, and that's fine, because there's almost nothing it can do for you. Especially if you don't have programmers. Because hey, no dev, right?
You'll notice that nowhere in the preceding text did I mention the tools that DevOps uses. That's because the tools are completely separate. Using "puppet" doesn't mean you subscribe to the DevOps methods (or even the mentality), and although DevOps may not be necessary for your environment, you might find puppet extremely useful. Let me say that again, Using the same tools as DevOps shops use does not tie you to the DevOps methodology.
As alluded to in the last answer up above, the shops that run DevOps need environments that can change quickly and absolutely. They needed tools that could do it, because you can't manually change hundreds of application servers. Because of their need to change that many machines, and have it happen nearly instantaneously, tools to automate this kind of change were developed and implemented.
Other technologies that get lumped into DevOps, cloud computing and virtualization, are also natural off-shoots of the type of environment where you have hundreds of application servers. Of course that kind of environment is going to be heavily into virtualization (if they've got an existing large infrastructure) or cloud computing (if they don't).
Again, DevOps doesn't "own" these technologies. They just use them (and advance them by writing tools to improve them, in many cases).
So there, that's my take. For the people who can use it, DevOps is developing into an exciting methodology to ensure increased availability and stability of IT resources.
It's not for everyone, but you owe it to yourself to take a look at the tools that too many people have been misbranded "DevOps". There's a lot of functionality there, and it can decrease the amount of time you spend slogging through administrative tasks.
It looks like I'm not the only one who's been thinking about this, too. Benjamin Smith wrote his take as well, and it seems like we agree quite a bit.