Ask IDEAS: How Do Cloud Service Providers Make Money?

There are a number of ways a cloud service provider can profit by offering infrastructure as a service (IaaS). However, although there are excellent blogs describing the cost from the point of view of the consumer, not much economic information is available about the provider. This lack of knowledge can cause some confusion. One avenue towards profitability comes from the fact that cloud providers tend to operate large data centers that can buy hardware at a big discount and can run extremely efficiently. Providers can then sell compute time as a utility because the costs are much lower for them than for individual end-users. However, there are also less intuitive ways IaaS can satisfy the bottom line. 

In order to develop an understanding it is sometimes useful to start with a simplified model. Here Max and Hanna own two servers. Max starts work at 10 AM on most mornings (90% of the time). Max then uses his server for 50 minutes and stops for the rest of the day. Hanna starts work at 11 AM on most mornings (90% of the time) and works for an hour on her server. Treating their server utilization as constant, a graph of their Usage vs. Time appears below:

 
Caption: A better approximation would have server utilization follow the two waves above (white lines), but, as can be seen in the graph, the two boxes are a worst case scenario (plus, the boxes make the math easier).

On some mornings though (10% of the time) Max starts work 10 minutes late and on some mornings Hanna starts work 10 minutes early (10% of the time). Like two flips of a coin, the actions of Max and Hanna are independent. In independent coin flips the chances of getting a heads in a single flip is ½, and the probability of getting two heads in two flips is 1/2*1/2=1/4 (because of independence they multiply). By similar means, the probability that Max is using a server at the same time as Hanna is 1 in 100 - (10%)*(10%) = .01! The math means that a cloud provider can buy one server, offer compute resources to both Max and Hanna simultaneously, and would only default on its obligation 1% of the time (think of it as a 99% Service License Agreement). Moreover, if each server cost $1 (daily amortization) the cloud provider can offer its services for $0.75 to each customer, which is less than either paid for their individual servers, and still make money: 2 customers x $0.75 cost  -$1 server = $0.50 profit! Cloud computing then becomes attractive to both provider and users alike. 

Naysayers may point out that 1% is still a large rate of default, but fortunately the math scales.  If there are two people like Max and two people like Hanna (all independent of each other) with four servers among them then the chances that all four would be using their resources at the same time is one in every 10,000 mornings (or over 27 years) -(10%)*(10%)*(10%)*(10%) = 1/10,000! The rest of the math follows below (click links for formulas):

  

Now in reality, the situation is a bit more complicated. The actors may not be independent, and there are surely other variables to consider. Also, there might not actually be a gap of zero utilization. However, the scaled up model still works as long as there is a valley that is less than one server between Max and Hanna’s usage.

Although this model is somewhat simplified, it approximates many real life scenarios. Researchers at universities are rarely pushing in-house server usage to the limits (except in the case of HPC workloads for scientific computing), so there are often gaps there. Time zone difference and its effect on utilization is another obvious application. To take another real world example, suppose there are a thousand programmers writing software at a company. Coding is, for the most part, text editing, but compute calculations spike during compiling and testing, so the model applies there as well. The gap model then can help explain how greater efficiency through aggregate usage can actually lead to lower cost for both user and provider while simultaneously satisfying SLA requirements.