In cloud computing environments the clock literally starts ticking the moment an application instance is launched. How long should that take?

The term “on-demand” implies right now. In the past, we used the term “real-time” even though what we really meant in most cases was “near time”, or “almost real-time”.  The term “elastic” associated with scalability in cloud computing definitions implies on-demand. One would think, then, that this means that spinning up a new instance of an application with the intent to scale a cloud-deployed application to increase capacity would be a fairly quick-executing task.

That doesn’t seem to be the case, however.

Dealing with unexpected load is now nothing more than a 10 minute exercise in easy, seamlessly integrating both cloud and data center services. 

            -- Cloud computing, load balancing, and extending the data center into a cloud, The Server Room 
                                                    

A Twitter straw poll on this subject (completely unscientific) indicated an expectation that this process should (and for many does) take approximately two minutes in many cloud environments. Minutes, not seconds. Granted, even that is still a huge improvement over the time it’s taken in the past. Even if the underlying hardware resources are available there’s still all of the organizational IT processes that need to be walked through – requests, approvals, allocation, deployment, testing, and finally the actual act of integrating the application with its supporting network and application delivery network infrastructure. It’s a time-consuming process and is one of the reasons for all the predictions of business users avoiding IT to deploy applications in “the cloud.”

IT capacity planning strategy has been to anticipate the need for additional capacity early enough that the resources are available when the need arises. This has typically resulted in over-provisioning, because it’s based on the anticipation of need, not actual demand. It’s based on historical trends that, while likely accurate, may over or under-estimate the amount of capacity required to meet historical spikes in demand.

Cloud computing purports to provide capacity on-demand and allow organizations to better manage resources to mitigate the financial burden associated with over-provisioning and the risks to the business by under-provisioning. The problem is that provisioning resources isn’t an instantaneous process. At a minimum the time associated with spinning up a new instance is going to delay increasing capacity by minutes. Virtual images don’t (yet) boot up as quickly as would be required to meet an “instant on” demand. The processes by which the application is inserted into the network and application delivery network, too, aren’t instantly executed as there are a series of steps that must occur in the right order to ensure accessibility. An instance that’s up but not integrated into the ecosystem is of little use, after all, and the dangers associated with missing a critical security step increase risk unnecessarily.

The end result is that capacity planning in the cloud remains very much an anticipatory game with operators attempting to prognosticate from historical trends when more capacity will be required. Operations staff needs to be just as vigilant as they are today in their own data centers to ensure that when the demand does hit a cloud-based application the capacity to meet the demand is already available. If the cloud computing environment requires a “mere ten minutes” to provision more capacity, then the operations staff needs to be ten minutes ahead of demand. It needs to project out those ten minutes and anticipate whether more capacity will be required or not.

Visibility is required to achieve efficient capacity planning in any data center model, but more-so with cloud computing because while it may not be instantaneous, it is a smaller window within which operations has to recognize the need for additional capacity and do something about it. Unless you employ automation and infrastructure services capable of applying policies based on organizational need for capacity. Ultimately what you want is a way to codify capacity planning requirements via the cloud management framework such that thresholds are based on the appropriate time frame and specific parameters (performance, users, connections, bandwidth, etc…)

Certainly a ten-minute process is much more efficient and leads to finer-grained capacity-related policies which should result in reduced operational costs and minimize the possibility of loss of business due to an unavailable site. The trick is to fine-tune those policies based on the process bandwidth required to provision additional resources. Testing of the provisioning process to ensure the right policies are being deployed as well as the time it takes to do so will better enable operators to adjust monitoring and watch historical capacity needs based on the appropriate lead-time required.

If you don’t know how long it takes from initial launch to available for consumption you need to know; you need to test the process and ensure you understand what the granularity of time is for on-demand provisioning. Whether a particular cloud provider’s framework is “fast enough” for your capacity needs depends on the predictability of demand and the length of time required to add capacity within their environment.

If this test isn’t part of your standard “cloud” acquisition process, it should be, because “fast enough” is highly dependent on whether you need capacity available in the next hour, the next minute, or the next second.