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 fixed-size chunks.  Please see the overview in Lesson 3.1 if you have not already read it.

Fixed Instance Size Allocation

This strategy is the one that existing cloud computing customers may be the most familiar with, since it was chosen by Amazon EC2, one of the pioneers in cloud computing.   Originally, Amazon offered a small selection of virtual computer configurations, or "instances": small, medium, and large.  Each one offered a fixed ratio of CPU to memory.  As customers started complaining that these ratios didn't meet their needs, Amazon divided these instances into high-CPU and high-Memory instances which offered more of the type of resource that the customer needed more of.  Currently, they offer 5 different instance sizes.  In our analogy this corresponds to a housing developer creating a limited set of house plans for a housing development: customers have to choose from a small menu of bedroom/bathroom count combinations that best meet their needs.

Amazon took a very analytic approach to finding an optimal packing strategy.   Since their instance sizes have fixed ratios of RAM to CPU, and a limited number of choices for the quantity of each, they can pack customers' applications into their servers with nearly 100% efficiency.   The problem becomes much like solving a preschool-level jigsaw puzzle, in which the pieces are pre-designed to easily fit into a nice, rectangular whole. 

In the graphic, the large rectangle represents the server's resources (CPU and Memory), and the blue spaces represent unused resources. When a customer requests an instance, the Amazon system simply looks for a "hole" (free resources, shown in blue) in the jigsaw puzzle of one of their servers that fits the size of the "piece" (the new instance, represented by a colored rectangle).  Because the instances are all proportional to the ratio of CPU and memory built into the servers (though there may be more than one type of server depending on the variations in the offered instance types such as Amazon's High Memory Instances and High CPU Instances), the instances fit into the servers with very little unused space (called fragmentation) since new instances can always be placed into the empty spaces, so this is an efficient packing strategy.  However, the fixed size of the instances means that customers often have unused resources inside their instances since they have to always buy extra space to allow for peak or increasing load, memory leaks, or other growth in their application requirements.

Advantages of Fixed Instance Allocation

-        Low cost per instance.  The vendor can keep their servers busy with very little server fragmentation so they are used efficiently, reducing their costs and supposedly the prices that they charge customers (as we shall see in the next lesson, this assumption is not exactly true.)

-        It is simple.  Customers can easily understand what they are getting and what they will be paying for.

Disadvantages of Fixed Instance Allocation

Unfortunately, this strategy optimizes convenience and efficiency for vendor, not for the customer.

-        Doesn't meet customers' needs without additional effort.  Much like in the years before cloud computing, where customers had to buy a physical server and then use as much of it as they needed, customers have to deal with the instance either being too small or too large for their needs.  This packing strategy moves fragmentation in the server as whole into each customers' virtual server (where they are paying for the unused resources.)

-        Complexity.  Because of limitations in the Xen virtualization system used by Amazon and many price-focused cloud vendors today, instance sizes cannot be changed on-the-fly to accommodate changes in demand.  Also, changing them while in use would destroy the efficiency of the packing strategy, much like the example with oranges of different sizes.  To solve this problem, customers have two choices, both of which cost them money.  One choice is to buy a larger instance than they need to allow for future increases in server loading, which results in paying for more than they need.  Or, the customer must use the vendor's programming interface to get more resources.  This can be done in two ways, by either moving their programs and data to larger instance when their application comes close to reaching the limits of the instance it is deployed on, or they can design their software to distribute the computing load across multiple instances and start a new one when their existing instances cannot accommodate the load.  Moving the application from one size instance to another, like moving from one house to another, is a complex process that requires either people to detect the problem and solve it manually, or other instances to detect the need for the movement and execute the steps to do so.   Similarly, adding new instances to shoulder additional load, like splitting your family into two houses, is a complex process that requires an arbitrator instance or hardware unit (called a load balancer) to send requests for work to multiple instances, as well a as manager instance that detects the need for the additional instances and starts them.   Additionally, the application software generally must be written so that it understands the scaling method, or it will fail if it is moved or duplicated.

-        Cost.  Aside from having to pay for instances that might be too large, all the extra instances that are responsible for responding to changes in loading are, of course, an extra cost to the customer.  To solve the complexity problem, a host of cottage industries or value-added-resellers (VARs) for Amazon EC2 have sprung up that do this for you.  Naturally, they also charge for their services, which include the cost of the Amazon instances necessary to provide them.

-        Analyzing cost is confusing.  Whether these extra costs exceed the savings from the low instance prices that supposedly come from the efficiency of the packing strategy depends on analyses that the customer has to make which can be very, very difficult to do accurately.  Calculating TCD is a graduate-level project that is beyond most customers' capabilities, especially when taking into account additional fees that are often charged by vendors (see Lesson 4, Cloud Pricing Strategies)

Best Customer Match for Fixed Instance Allocation

-          Customers who like the very low prices for small instances.

-          Customers whose loads don't vary much so they don't need to manage unused instance capacity.

-          Customers who are highly technical and are capable of programming around the complexity of managing multiple instances to accommodate growth in demand.