Today I read a blog from David Linthicum in which he said that the corporate datacenter is safe from cloud computing because issues around compliance, privacy, fear, and control will cause companies to want to keep their computing in-house.   However, I'm not sure that this is an us-vs-them issue, and there is a good reason that the corporate datacenter will stick around for a long time: it's cost-effective, though only if well-run, and large enough to provide the economies of scale that make it so. What cloud computing will do is provide a benchmark for the cost-effectiveness of the internal datacenter by providing an alternative.

I think the discussion on whether cloud computing will kill the datacenter should be reframed: it's more like "The king is dead. Long live the King!"  Once the hype of cloud computing has been overcome, I think it will be shown to be a set of *technologies* that enable a set of *services*, rather than a specific set of branded products as it is being marketed now.  And those technologies are just as useful inside the corporate datacenter in a "private cloud" as they are in a service provider's datacenter serving up a public cloud.
The issues around compliance, privacy, fear, and control will have to be played out inside the enterprise just as well as they are in the public forum as these technologies do actually provide advantages no matter where they are applied and will create revolutionary change in any case. What are these technologies?  Virtualization of compute, I/O, and storage; pay-per-use microbilling; IT workflow automation; and application template libraries.  If IT staff think that their jobs are safe from radical change just because their company isn't outsourcing its computing to the cloud, I think they'll be in for a surprise because these technologies - collectively "cloud computing" - will impact them anyway.

Lesson 3, "Behind The Scenes in Determining the Costs of Cloud Computing" continues with this discussion of a method of allocating cloud computing resources to customers in adjustable, granular chunks.  Please see the overview in Lesson 3.1 if you have not already read it.

Variable Resource Allocation

With this packing strategy, the vendor allows the customer to select whatever values for CPU and memory allocation that they desire.   In our housing analogy, this corresponds to the developer allowing families to have the most efficient housing allocation by having their houses built to specification, with any number of bedrooms and baths.  This creates a packing problem for the vendor because the instances have sizes that do not evenly fit into their servers, leaving lots of fragmentation.

To solve the fragmentation problem, vendors using variable resource allocation buy very large servers with lots of CPU and memory, so that the fragmentation is a small percentage of the overall server size, and hence cost.  In addition, some vendors allow on-the-fly resizing of instances, which in our housing analogy corresponds to allowing families to remodel their houses to add rooms, or even subtract them.  This truly fulfills the "pay for what you use" promise of cloud computing from the customer's point of view.   This technology also benefits the vendor in reducing fragmentation because it is based on the ability to move instances around from server to server easily (often without disrupting the customer's running software) to coalesce free server resources so that they can be sold to other customers.   The ability to resize instances also means that the instances are persistent, meaning that the state of the instance (including the loaded software and stored data) is saved even if the instance is turned off, resized, or the underlying hardware fails.  Instance persistence offers significant benefits to customers since the software need not be written to take into account dissolution of the instance, and additionally, vendors can offer uptime guarantees for the instance.

This packing strategy moves the fragmentation from inside the customers' instances (where they are paying for it) to the vendors' servers, where they are generally better able to manage it by packing other customers' instances into the unused spaces.

Once a vendor offers variable resource allocation, monitoring the customers' usage and then adjusting the resources allocated to the instance(s) automatically becomes a possibility, which can reduce costs dramatically for highly variable computing loads, as well as ensure the performance of the application if the demands on it spike.

Advantages of Variable Resource Allocation

-        Flexibility.  Customers can allocate exactly the resources that their software applications need. In addition, if the vendor supports on-the-fly resizing (often called scaling), customers can adjust resource allocation to optimize performance or payments as computing loads change.

-        Ease of Use.  Variable Resource Allocation often is offered with instance persistence, allowing customers to write software without worrying about the reliability of the underlying cloud platform.

-        Cost.  Since this is truly pay-as-you-go computing, the customer can optimize their overall costs.  By allowing the customer to remove unused resources from their instances, the fragmentation in the cloud is moved from inside the customers' instances into the vendors' servers, where they are generally better able to deal with it.  Automated scaling can save customers with highly variable computing loads large amounts on their computing bill.  As an example, most physical datacenters run at between 2-25% utilization, so automated scaling can return resource savings of 75-98%!

-        Easy to Understand.  Since customers get exactly the resources they request, pricing can be simplified to a simple rate per resource used, like dollars per CPU-hour.  This can be an advantage as well as a disadvantage, see below.

Disadvantages of Variable Resource Allocation

-        Hard to understand.  Customers often are not used to variable resource allocation, in which they become fully responsible for knowing how much resources their application actually needs to do its job, since a bad guess can result in an application crash.  This is a big change from the old non-cloud model where they would simply buy much more server than they needed and not worry about resource allocation, or even the fixed or quantized cloud packing models, where most customers still do the same.  This also makes it difficult for them to predict what their costs will be since those costs now depend on what is going on inside their software and on end-user activity, instead of some fixed amount that they are paying.  This problem is particularly bad for startup companies, who have no historic record of demand or software efficiency in meeting it.  Automatic scaling can eliminate the need to understand what resources the software needs by eliminating the need to predict appropriate instance sizing, but it still doesn't help to predict costs.

-        Cost.   Much like any scheme in which resources are allocated on demand, auto-scaling can surprise the customer with a large resource bill, so limits should be placed on its ability to increase instance resources. There is also a potential for slightly higher costs to the vendor due to increased resource fragmentation on their servers, which may be passed on the customer. Overall, the vendor is better able to manage fragmentation than the customers are, so this additional cost should be negligible or perhaps not even an issue.  The vendors' charges are generally straightforward since they are offered as a resource hourly rate, but calculating TCD with this allocation method is still difficult, mostly because customers have difficult calculating their resources requirements. 

Best Customer Match for Variable Instance Allocation

-          Customers who need to manage internal fragmentation to save money, and understand the resource usage profile of their application.

-          Customers who need to manage internal fragmentation, and have chosen a vendor with automatic resource scaling so that they don't need to understand their application's resource needs over time.

-          Customers who can save significantly on cost by taking advantage of automatic resource scaling (if the vendor offers it.)

-          Customers who wish to transfer a physical datacenter to the cloud without having to worry about sizing the resources correctly, or re-architecting their applications to accommodate fixed or quantized instance allocations

Lesson 3, "Behind The Scenes in Determining the Costs of Cloud Computing" continues with this discussion of a method of allocating cloud computing resources to customers in adjustable, granular chunks.  Please see the overview in Lesson 3.1 if you have not already read it.

Quantized Instance Allocation

Some cloud vendors have chosen to solve the problems of fixed instance allocation by creating a build-to-order service, where customers can order instances based on their actual needs, with some restrictions.  To make this packing strategy efficient, customers are only given the option of choosing either CPU or memory size in fixed increments, with the other being set by the vendor based on a formula.  In our analogy, this is the equivalent of the builder of a housing development offering custom-built homes, in which you may choose any number of  bedrooms, and you then get a proportional number of bathrooms, like for example ½ bath for every two bedrooms.  An example of a provider that uses quantized instance allocation is GoGrid.  This is a variation on fixed instance size allocation.

In effect, this packing strategy is like the fixed instance size strategy, but with many more options.  However, because there are more possible instance sizes, they don't fit into the vendor's servers as efficiently as a smaller set of instance sizes, increasing fragmentation.   Many new cloud computing services coming into the market use quantized instance allocation, perhaps to resolve some of the issues with fixed instance allocation as used by Amazon so that the new vendors can compete effectively.

Advantages of Quantized Instance Allocation

-        Flexibility.  Customers are offered more options for instance sizes so that they can choose the right ones for their needs, saving on costs.

-        Efficiency.  Packing is still relatively efficient if the cloud system does some optimization, so resource savings from this packing strategy can be passed on to customers.

-        Somewhat easy to understand.  Though not as simple to understand as Fixed Instance Size Allocation, customers generally understand this model well, and like the idea of sizing instances to their needs.

-        Cost.  Because vendors often offer more choice in instance sizes, customers may potentially save over fixed instance allocation because they don't need to order as many unused resources.

Disadvantages of Quantized Instance Allocation

-        Customers' needs not exactly met.  Limited and fixed selection of ratios between CPU and memory allocation means that customers' needs are not exactly met, resulting in overpayment to get the necessary resources, or inadequate performance.

-        Inflexibility.  Again, due to current technology limitations, and limitations of this packing strategy, instance sizes cannot generally be changed while the customers' application is running.  To solve this problem, customers have to use the same scaling methods as for fixed instance packing strategies.  Some cloud vendors assist with the necessary instance moves or load distribution, somewhat circumventing this problem.  However, the application software generally must be written so that it understands the scaling method, or it will fail if it is moved or duplicated.  Also, because of the fixed ratio between CPU and memory, customers have to buy more of the selectable resource than they need, if they need more of the dependent one.

-        Complexity.  Customers may have difficulty understanding the fixed relationship between CPU and memory that this allocation strategy requires, leading to potential frustration with the cloud vendor.

-        Cost.  Inefficiencies in the packing strategy as well as potential fees for services designed to mitigate its inefficiency and inflexibility can raise the cost of this type of service.   Calculating TCD is difficult.

Best Customer Match for Quantized Instance Allocation

-          Customers who need more flexibility than fixed instance allocation, or want to optimize their internal fragmentation.

-          Customers who are highly technical and want to administer their own instances and take responsibility for instance size management.

-          Customers who don't have applications that vary significantly in their resource usage over time.