Devs and automated Ops

Over at CIO, Stephanie Overby presents a GE Capital case study in which

The team was given some quick training in automation and given three tasks: develop the application quickly, figure out how to automate the infrastructure, and figure out how to automate more of the application deployment and testing in order to marry DevOps with continuous application delivery.

DevOps is often thought of as the breaking down of walls between operations and development. As such, it’s the IT equivalent of other types of integrated teams—an organizational style that goes in and out of fashion but is more in that out at the moment.

Looking at DevOps this way is… well, not wrong exactly but it misses important points. It’s worth stipulating here that there’s not yet a broad industry consensus around what DevOps. Nonetheless, it’s broadly recognized that historical boundaries between developers and operators and—as important—between the tooling that they use are rapidly breaking down.

Let me lead into my point with another quote from the article.

The project not only proceeded quickly -- the application was delivered within several months -- it established some new IT processes. They increased the amount of automation possible not only at the infrastructure level, but within the application layer at well. 

Note the repeated use of the word automation.

A naive view of DevOps (which corresponds to how it was often discussed a few years back) was that DevOps was about the merging of developer and operator roles into one. The developer grabbed the production SQL database root password and the operator started churning out PHP. But that’s not really the DevOps story.

Much remains to be written and discovered on this topic. (By myself and others.) But one way that I increasingly think about DevOps is that the architects and operators build the infrastructure, setup developer self-service, automate scaling and deployments and then get out of the way.

For example, here’s how Paypal’s Ryan Granard described their approach with Red Hat’s OpenShift PaaS at GigaOm Structure last June:

Our concept is you walk up to a portal, you pick the product that you want to work on. You're not asking VMs and RAM. You just say, I want to work on Wallet. In minutes, we have you up and running in a fully connected container and you're developing. That's the key. That's a real benefit to just the speed of innovation and ultimately not having developers or testers or any of these folks do anything that's not part of what their role fundamentally is.

Viewed through this lens, DevOps can be seen as not necessarily about developers becoming amateur DBAs or operations folks slinging a lot of code. It’s true that some of the newer management and operational tooling—think Puppet, Chef, Foreman, and so forth—is lighter weight and perhaps more suited to a degree of joint dev and ops use. However, it’s also clear that DevOps is about automating the relevant subset of operations for developers and providing easy-to-use instrumentation and controls that let them make effective us of that underlying infrastructure.

photo: CC/flickr by M Ray http://www.flickr.com/photos/mray/7249435726/