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