My take on DevOps

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…

  1. Does your organization have programmers?
  2. Developers are necessary for the DevOps relationship…otherwise you’ve just got Ops

  3. Do you provide Software as a Service?
  4. 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

  5. Do you release software updates frequently?
  6. 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.

  • I agree, some of these tools have existed for a long time and I didn’t think about it but you’re right DevOps doesn’t own these tools. The methodology of DevOps does lend it’s self well to using configuration & control tools, virtualization and cloud, but it is not the only path to these tools.

    On the flip side, which is also how I got involved in the DevOps toolchain mailinglist, I think there are still a lot of tools missing. I have been plugging away writing some of the filler, but there is one huge one that I am still designing to fill in where puppet/chef fall short.

    I don’t know how much software writing you do, but I would like to ping a couple ideas off of you, since you work in an environment similar to mine.

    Scott (aka fatherlinux)

  • Matt, I would add also that one of the most important things is about the culture. The team needs to have a communication culture were everyone devs and ops are on the same page and work for the same goal (to have their company succeed). The tools are important as they improve agility and empower many of these technologies, but I agree with your note they are useless if taken out of the context. devops is not about tools, but about culture, communication and people interaction in general.

  • Terry Greenlaw

    I head the DevOps group for a fairly large organization (5000+ servers), and I think you did an excellent job of distilling the essence of DevOps.

    We use the sysops and network engineers as subject matter experts, and use our cmdb, message queues, monitoring, and other infrastructure components to develop tools that the entire operations team can use.

    The communal knowledge that builds the tools makes the whole team more productive at the same time it protects the company from losing functionality when someone quits and takes the scripts they’ve been hoarding with them.

    We don’t use puppet or chef, so I’m certain neither of those are prerequisites :-)

    However, I can answer “yes” to all three questions above. We focus on web interfaces and services, and rely heavily on JQuery, MongoDB, and PHP for our solutions. We aim for small solutions with quick deliveries, and leave the bloat to someone else :-)

    We did not have executive buy-in initially, but once they saw the results, they quickly became our biggest evangelists. There was a little apprehension from the sysops and network guys originally, but they knew the previous model was not sustainable nor scalable, and it only took a couple of quick wins to get them on board. Now they are more productive than ever, and we’re tasked with solving all kinds of interesting problems that make me look forward to going to work for the first time in 20+ years of IT :-)

  • Great post. I’ve always thought “devops” was more appropriate for web shops delivering app fixes/features as quickly as possible. I usually take the latest trends with a grant of salt.. agile, devops, rails, etc. They all have their place but the people pushing it usually don’t have the experience to say “hey, it doesn’t apply here. sorry”…. they usually want to push it everywhere like it’s some magic bullet.

    While delivering hardware and software (bottom of the stack, not apps) solutions, I’m been constantly asked to deliver “good enough” solutions and improve them later, much like agile and devops like to do things. But how am I going to deliver a storage server that’s broken in many ways but works for 25% of what it should.. and keep rebooting and changing things on the hope that someday it’ll be 100% of what we need ? I don’t think Devops apply to that kind of infrastructure.

    On the other hand, it sure applies to the apps that we use to manage the infrastructure. We sure benefit from quick fixes and new functionality to those apps. The problem though is agile/devops usually skip the planning/architecture phase and go straight to code… they can fix it later, right ? Well, yeah.. unless a bug in the configuration management wipes out all my disk pool configuration.. then it’s not fun, right?

    Companies that are all about devops/agile (like where I work), tend to want to apply it everywhere. The IT infrastructure team is often tasked with “release early, release often” while at the same time getting a hard time from the CIO because the number of incidents go up nearly with the number of changes… so we are often asked to stop doing changes, and then everything gets stable again.

    I hate all the hype that I get from the agile/devops/rails folks. When it comes to basic reliable systems, I prefer the well thought approach vs. the “release crap early, release crap often”. And I’m not sure it even works for the web shops… Facebook is a super agile shop, isn’t it ? How come a “hack” to fix their cache can take down the whole company? The person that architected that “hack” should get a hard time from his/her boss… but then, that’s their whole point… it’s going to break and we fix it quickly. I’m glad I don’t have to explain a 2.5hrs outage in the middle of the business hours to my shareholders.

  • As someone who has self identified as an “Operational Developer” for the past 13 years, I can say I have some differences of opinion on this, though not in the movement, since I am not a part of the movement.

    I’ve been doing system administration and development for 25 years, and have primarily take roles as a system administrator or operational lead, and while maintaining the systems, I have written automation and software to help manage things.

    This is different from this joined split idea, where you have Developers and Operations people, and they work together. That is great, and key, but really always happened to more or less extent.

    What I want to see more of is people who are BOTH. Who are competent sys admins in their own right, and could run everything by hand without a problem. And are able to write code to develop additional software needed to help run, automate and manage the systems.

    To me, this is what “DevOps” should be, but I’ll take more hand holding between the organizations as well. :)

  • Pingback: A considered reply to Mark Burgess | Standalone Sysadmin()