Understanding cloud and 'devops'--part 3

The first two parts of this series laid out a case for why cloud computing is driving an applications focus in operations instead of a server focus, and why that applications focus forces a change in the core responsibilities of IT operations personnel, respectively. Those posts triggered a very lively discussion on Twitter and in what I call the "cloud-o-sphere" about the consequences--and limits--of "devops."

I know I promised some examples of devops in action, but that will have to wait until a later post. For now, let me lay out some of the more interesting observations--and debates--that my review of devops triggered.

1. Devops does not mean that developers have all the power. One of the first responses to my posts was from Andi Mann, once an analyst, now a marketing manager at CA. Andi has tremendous knowledge of both IT operations and cloud computing, and he had some reservations to the devops concept:

   [M]ost of the writings I see about devops are really about dev, not ops. As a result, they don't really capture the whole story of the application lifecycle. They justify devops as an antidote to the problems that ops are causing--slowing down release cycles, imposing arbitrary rules, screwing up deployments, killing developer productivity, hacking manual scripts and configs, stopping the business from being agile--but fail to recognize both the failings of developers that contribute to the problems, and the role of operations in delivering critical business outcomes during the application delivery lifecycle.

   Mann goes on to point out some of the things that ops does today that are critical regardless of infrastructure ownership, and he's right--but he misses the mark a little bit on what devops is about. As Andrew Clay Shafer notes in his response:

   To start with, Andi asserts that DevOps is mostly about developers. I'm not entirely certain what makes him think that, but it is patently false and the majority of people involved are heavily from an operations background. That said, I do believe semantics matter, and it might just be the name itself that leads people to that conclusion.

   Maybe NeoOps, or KickassOps would have been better... but it is probably too late for that now.

   Shafer then describes the ways in which operations and development interact on the lifecycle issues that Andi outlined. I recommend you read both posts (though at times Shafer's get's a little too personal for me), as they will give you a sense of both the confusion about devops, and how devops really does bring operations closer to development without handing over the controls.

2. Infrastructure operations still matters--a lot. An extension of the previous point is an observation that devops not only doesn't replace applications operations, but it doesn't replace infrastructure operations, either. In fact, infrastructure operations retains tremendous control over what can be done in a data center, regardless of whether it is a private corporate data center or a public cloud provider data center.

   Recall in part 2 when I discussed the importance of policy in communicating application operations needs to the underlying infrastructure:

   [T]he concept of application policies becomes paramount: descriptive or prescriptive "rules," input parameters and/or functional code that basically tell the cloud service/infrastructure what to do on behalf of the application. Policies are delivered to the cloud service through well defined APIs, then mapped to specific infrastructure service profiles as necessary by the cloud provider.

   Lost in my explanation is a simple fact: if the cloud provider (essentially an infrastructure operations service provider) is the one that receives and interprets policies, then the cloud provider is the one who gets to determine which policies it can support, and how those policies are in fact supported.

   Did you get that? If you are an application developer or operator, you can choose any operations policy you want for your application, as long as it is supported by one or more of your cloud providers.

   This ability to control what operations policies are available in the cloud is why infrastructure operations remains a critical opportunity for innovation in cloud computing. While it would be possible to boil life down to just a handful of universally supported operations capabilities, I believe--as I noted before-- that providers will differentiate themselves in part by the configurability and flexibility of their services.

3. Beware of the cloud boomerang. Bernard Golden, CEO of Hyperstratus, wrote a great post about one of the reasons why ignoring devops might lead to a huge problem for your IT operations organization in the very near future; namely, what Golden calls the cloud boomerang:

   As engineers finalize their application development work in the cloud, there will be pressure to "put it into production." Many of these applications will subtly, even surreptitiously, migrate from development through "trial" to production. I've certainly witnessed this plenty of times. I was once assigned to lead development of a new release of a product on a crash basis because the previous version--a development prototype never intended for anything but internal testing--had been released and was in customer production use and, as one might expect, wasn't robust enough.

   Inevitably, many of these cloud-developed applications will end up in production in the cloud. Use of the application will grow. Customer enthusiasm will increase. Business dependence will grow.

   Then problems will arise. The original developers will be assigned to a new project, and no longer be available to manage the application. Enough feature requests will arise that the developers need to focus on the next application version and can no longer perform system administration duties for the production version. The application will run into performance issues and the developers won't know what to do. Or, developers, being developers, will lose interest in the now-running application and direct their attention elsewhere, leaving the application without anyone responsible for its care and feeding.

   And a call will go out to the operations group to ask it to take over the application and make sure it's running correctly.

   Yes, the application will move back "home" in a boomerang trajectory. That's the cloud boomerang generation.

   In other words, as developers leverage public clouds for application development and testing today, the risk grows quickly that those applications will stay in the public cloud, and operations will be stuck with the responsibility to keep it running.

   Ideally, the solution would be to simply invite operations to join development in designing the application and its deployment and management automation. However, I don't think that's going to happen in many, if not most, cases. If developers are surreptitiously using the cloud for development, they aren't going to be excited to pick up the phone and call IT operations and expose what they are doing. They'll push as far as they can "in the dark," and only bring IT in when it is too late to kill the project without great cost--and angst.

   Perhaps the best most IT management teams can do is prepare to retrofit devops on applications running in public clouds. Identify how an application running in, say, Amazon Web Services would be monitored and controlled, and what the operations procedures would be to support such an application--as well as the cost to the application owner.

   I'm not sure that's a strategy with a high likelihood of success, though.

As I noted earlier, I'll have to do another post with some examples of devops at work, but as you can see the concept is very nascent, and there is much thinking--and innovation--left to do. However, in my opinion the operational realities of cloud computing make facing these challenges inevitable. I hope you'll give devops some thought, at least, and apply the concepts where they make the most sense in your changing IT portfolio.