I was talking to a colleague who works for a large technology vendor. His company offers products to enable IT organisations to construct cloud infrastructures inside their own data centres - to turn existing stable, static computing environments into ones that support scalability, agility, and dynamic applications. The company's progress on its products has been impressive, early implementations successful, and interest from their customer base (infrastructure groups within large IT organisations) high. However, he shared an apprehension with me regarding product adoption. "I'm concerned that while our customers are working on a very deliberate plan that will take a couple of years - doing their research, performing a pilot, evaluating the economics, making the capital investment business case - that the apps side of the house will just charge ahead using on-demand public cloud providers like Amazon." While he was worried about this trend from the point of view of how it will affect the prospects for his company's products, my mind moved toward a different outcome: the boomerang. With regard to the issue he's worried about, my sense is that his concern is quite valid. Many software engineers have moved to cloud environments for development due to immediate resource availability and low cost. It's widespread. I noted in a blog post a few months ago my amusement regarding one large software vendor's senior executive's rant. He and I were both on a cloud computing panel and in his remarks he railed against developers using Amazon, citing intellectual property concerns. After the panel was over, as the participants were chit-chatting, he said that he found it frustrating because developers in his own company were using Amazon quite widely, despite being warned against it, because it was so much easier than getting computing resources through the official channels. The phrase "hoisted on one's own petard" sprang to my mind.
Some proportion of these engineers end up passing their cloud costs on in the form of expense reports. Some don't bother, feeling the $30 or $40 per month is something they're willing to absorb in the interests of getting their job done.
But there's no question that lots and lots of development is going on in the cloud. Indeed, most analysts and consultants recommend "dev/test" as a good initial candidate for cloud use.
But what does this have to do with a boomerang?
Actually, what came to my mind was the phrase " boomerang generation”, referring to the recent phenomenon of adult children moving back into their parents' home. The parents, who never imagined that they would have to take care of their grown kids, find themselves burdened with ongoing responsibility for their offspring. While many chafe at the duty, most end up taking it on, feeling they have no way to abjure the duty.
And here's how I think IT operations will experience what I call the "cloud boomerang."
As engineers finalise 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.
Note that this doesn't necessarily mean that the application is transferred back into an internal data centre. It just means that, well, operational responsibility is transferred back to operations.
This will present some challenges, including:
Learning about the boomerang application and its architecture. Developers are notoriously poor about documenting an application, and one could expect that cloud-developed applications will be no better than average in this respect, and perhaps far worse. Taking over responsibility for an application requires understanding its architecture and patterns, so expect to devote some time to learning the ins and outs of the application.
Productising the application. Many times applications developed in a skunkworks fashion fail to adhere to organisational standards with respect to security, monitoring, etc., etc. Don't be surprised if your boomerang app needs some upleveling in terms of making it ready to operate in a production environment. This will undoubtedly require additional development work, so make sure that you require development resources as part of the handover process.
Making the application cloud-ready. Wait, the application is already in the cloud. Why does it need to be made cloud-ready? There's a significant difference between an application running in a cloud environment and an application being capable of using cloud computing characteristics like scalability and dynamism. Just last week, I was talking to a company that had its applications running in a public cloud, but was suffering from lack of scalability and inability to recover from virtual machine failure - all due to writing its applications in a non-cloud-friendly way. In the past, adding resources, relocating instances and the like were the responsibility of operations and handled manually, but in the cloud world, the application needs to be able to perform these actions autonomically via integrating operational characteristics into the application itself. The burgeoning #devops movement addresses this integration, but it is nascent, and there are by no means best practices available to be adopted today. If your boomerang app needs some heavy rearchitecting, don't be shocked.
So if the cloud boomerang is inevitable, what should IT operations do? Here are vital action steps to avoid being clonked by the cloud boomerang:
1.Recognise you don't have two years to develop your cloud strategy. Two-year plans are as obsolete as Soviet five-year plans. The pace of change in IT is quickening and time horizons that used to make sense are far too long for today's (and tomorrow's) IT. This is unquestionably the most dynamic time in IT history. Right now you have developers making cloud choices that will become de facto organisation choices. Failing to recognise this and address it is an enormous mistake. And the (perhaps) instinctive reaction to forbid use of a public cloud is wrong and foolish. If the trend can't be controlled, the next best strategy is to guide it. Thus ...
2.Get ahead of the developer curve by defining certified stacks and making them available. One of the really challenging elements of so-called shadow IT is that component choices are made on an individual application basis without and guidance or recommendation. Since a big part of the impetus is to improve personal productivity, help increase it further by offering pre-bundled software stacks that can be used immediately. Any shortcut to productivity is likely to be grabbed immediately. Assist this impulse.
3.Find a viable cloud system management product and implement it stat. One of the most dangerous things about current cloud development practices is that applications are put together without thought about downstream manageability. For operations, failing to have an efficient mechanism to manage boomerang applications is a recipe for one-off applications, extra work, and post-release re-engineering. Again, providing an easy mechanism will be an incentive to adoption and reduce downstream angst.
4.Look on the cloud boomerang as a gift. As White House Chief of Staff Rahm Emanuel said: "You never let a serious crisis go to waste." Chris Hoff, a well-known cloud computing blogger who focuses on security, says that cloud computing will be a forcing function that will motivate IT organisations to implement better security practices. Likewise, the cloud boomerang offers the opportunity to move forward on implementing consistent IT practices and processes.
The role of operations is definitely evolving rapidly as expectations of application scale, resource availability, and cost undergo transformation. Operations won't disappear - far from it - but those responsible for operations need to recognise the way its role and its own internal operations must change to meet the new expectations. And that includes taking on boomerang applications and making sure they meet those new expectations.
The author is CEO of consulting firm HyperStratus and author of Virtualization for Dummies.
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.