Cloud 101 - Lesson 3.5 - The Exact Relationship Between Cloud Performance and Cost Cannot Be Known
Lesson 3, "Behind The Scenes in Determining the Costs of Cloud Computing" continues with this discussion of why the exact relationship between cloud performance and cost cannot be known, which makes comparing vendors somewhat difficult. This lesson builds on the previous ones. Please see the overview in Lesson 3.1 if you have not already read it.
Cloud vendors, like any company that has to buy computer equipment over time, cannot (and don't want to) buy the same models of servers year after year. Instead, they take advantage of improving server cost and performance over time by buying the latest models so that they can pass those improved economies to their customers or offer higher levels of performance. This causes a problem in giving the cloud customer a known amount of CPU power per dollar, since CPU power keeps rising over time. This is where the “hardware abstraction” promise of cloud computing breaks down.
Let's look at an example. Suppose that a cloud vendor promises a price of $1 per CPU-hour based on an older model server, and they buy a new server with a 20% faster CPU. They could simply offer 80% of the new CPU at the same price, and customers would get the same performance whether their software was running on the old or new server. However, this creates a fragmentation problem: what to do with the remaining 20% of the new server's CPU? To solve this problem, fixed or quantized-instance vendors create a “virtual CPU” with a certain speed rating that doesn't change over time. Amazon, for example, calls a “core” equivalent to a 2006 1-1.2 GHz Opteron. However, if the cloud vendor buys a server that doesn't have a CPU with a multiple of the power of the virtual CPU, they are faced with a choice: either divide the extra computing power among the virtual CPUs on the server, or waste the extra power.
If the vendor divides the extra resources among customers' virtual CPUs, the customer gets something near but not exactly equal to the number of virtual CPUs they have ordered. As long as the customer never uses any specialized performance measurement software, they will not know if they're getting a little more or less than they have been promised, depending on how the cloud vendor deals with the fragmentation. However, customers will always have slightly different amounts of CPU while paying the same for them.
This problem occurs for the variable resource allocation vendors as well, but they have more options in resolving the fragmentation, since at any time, some of their customers will request very small instances that can potentially use the extra CPU. However, variable resource allocation vendors have an additional problem as well: since customer's instances can be moved to new servers at any time, they have to allow for those servers to have slightly different CPU power, which may potentially also change the customer's CPU allocation slightly. One possible solution is that the vendor rates CPU power in Gigahertz, like the processor vendors (AMD, Intel) do, but this presumes that different CPUs with the same clock frequency perform equivalently, which is generally not true.
Ultimately, the customer has no easy way of validating how serious this problem is, or even if it is a problem. Vendor transparency, and the trust it creates, is the only solution to this problem.
TrackBack URI for this entry
