It is by now a truism that most IT organisations are planning an IT infrastructure strategy that includes cloud computing and that an internal cloud (aka private cloud) is a fundamental part of that strategy.
While trying to avoid getting sucked into the vortex that is defining cloud computing, I think it's safe to say that a cloud computing environment includes the ability for IT resource consumers like application developers to self service resource requests, along with automated provisioning (aka orchestration) of computing resources like virtual servers, network connectivity and storage. The mere deployment of virtualisation enabling support of multiple virtual servers on a single physical server, while admirable and useful in itself, is not cloud computing.
In talking to a number of informed people, it's clear that private cloud implementations are moving forward in many organisations, with RFPs to vendors out with an aim of contract award in 2011 and implementation in 2012.
The question is, how will that private cloud be used, and what are the downstream effects of moving to a private cloud? In our work, we run across a number of scenarios, some of which make sense, some of which don't make sense, and some of which are incomprehensible. I thought it might be useful to share what we see and what we predict are some of the ways private clouds will be used by those organisations implementing them.
A planning assumption that we bring to the table is that no organisation is going to insert a full blown cloud infrastructure into their existing production application environment. The reasons for this assumption are the following:
- A key principle of CIOs everywhere is don't mess with something that's in and working. Change introduces the potential for disruption and failure. So why insert an entire new infrastructure into one in which applications are quite happily humming along? Note: This does not imply that existing environments will not have virtualisation brought in. One of the most felicitous aspects of virtualisation is that it provides great benefit, cost reduction via server consolidation, without introducing much change at the application level.
- Most existing applications won't benefit from being placed into a cloud computing environment. Most production applications are written with static topology and manual administration assumed, so they can't take advantage of self service and automated elasticity. Therefore, inserting a cloud computing infrastructure into the production environment is going to provide little improvement for these applications. In any case, the leisurely march of virtualisation into production environments should call into question the belief that IT organisations are going to, overnight, disperse cloud computing capabilities throughout their production infrastructure.
- Cloud computing is expensive and disruptive to IT organisations. We constantly see organisations that underestimate the cost and change of moving to cloud computing. Just the fact that a new term, devops, needed to be created to describe how IT has to operate in a cloud environment should provide a clue about this.
So, to summarise: putting cloud computing into an existing production environment is disruptive and expensive, and doesn't provide many benefits. This should explain our assumption that most IT organisations will not retrofit cloud computing into their production computing environments.
Given this, many IT organisations are directing their initial private cloud initiatives at serving developers, which makes a lot of sense. Developers are typically underserved by existing processes, and offering them a self service option helps productivity and, crucially, avoids many issues associated with production private clouds, like how to integrate existing heavyweight processes like ITIL with agile self service resource assignment. Moreover, developers are pretty expensive employees, and avoiding long waits for resources reduces costs.
The question is, if an organisation's initial foray into a private cloud is aimed at developers, what are the subsequent use scenarios? In other words, once developers begin using the private cloud for development (and, of course, testing) purposes, what happens? Here are common use scenarios and their implications:
Scenario one: Agile development, static operations
In this scenario, software and QA engineers are provided a private cloud for development purposes, but when it comes time for production deployment, the application is operated according to the existing processes (which were, remember, created to manage static topology, inelastic applications in an often-process heavy ITIL-like environment).
We believe the satisfaction level to this strategy depends upon what proportion of newly developed applications assume and use the elastic automation associated with cloud computing. Selecting this approach might depend upon organisation specific projections of future application elasticity requirements. If the proportion of applications requiring elasticity is rather low, this scenario might be perfectly acceptable. For the majority of newly developed applications, static operation techniques would be appropriate. For the minority of applications that require elasticity, an exception to provide a more agile operations environment could be made and pertinent measures taken.
The challenge with this scenario is that it is in conflict with what we see as the increasingly common nature of future applications. That is, the nature of applications is changing, with more highly variable workloads, much larger scale and more complex deployment topologies that are more difficult to manage in a manual fashion. In a phrase, there is an impedence mismatch between the future of applications and the operational assumptions of this scenario.
Find your next job with computerworld UK jobs