Where does the cloud make sense?

As you saw in the preceding example, a fixed-load model may have limited economic advantage over a cloud deployment. In figure 3.2, you see the total cost for deploying the original e-commerce example in each of the four models over time. The flat line represents the internal IT model, meaning an initial spend. Let’s assume no ongoing monthly costs, because in this model you’re consuming preallocated resources that al- ready exist and are accounted for. In comparison, the cloud model requires less initial cash outlay than the CAPEX in the internal IT case, and a full 18 months pass before it catches up to the cost of the internal IT deployment.

Cumulative Infrastructure Cost ($K)

Internal IT Colocation Managed Service Cloud Month $ K 350 300 250 200 150 100 50 0 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1

Figure 3.2 The total cumulative infrastructure cost for the example e-commerce application deployed in four different models. The internal IT model depicts a fixed initial cost due to capital equipment purchase and the implicit assumption that the organization is able to use existing operational resources allocated elsewhere, including the human resources to manage the infrastructure.

But certain application types are practically begging to be deployed in a cloud. Let’s examine several of these and look at specific case studies for companies of different sizes.

3.2.1 Limited lifetime requirement/short-term need

Applications needed for a short, well-defined period of time are good candidates for a cloud deployment model. The main reason for this is the large up-front fixed capi- tal cost for the hardware needed to run the application. Recalling the e-commerce application , let’s assume you have an application that must run at exactly the same scale as the original application, but which has a fixed lifetime of six months. You require the same hardware resources and initial expenditure, but instead of realizing value for it over the three-year depreciation cycle, you should calculate the cost of the hardware for only that half-year interval, yielding an effective cost due to hard- ware of $5,167/month.

A six-month term for colocation is somewhat harder to negotiate than a standard one-year term, but let’s suppose you can negotiate a $1,500/month fee with an initial $1,500 setup fee. Over the six-month term, this will translate into $1,750/month for hosting. In this example, you have, for both the internal IT and colocation models, an effective total cost of $5,167/month and $6,917/month, respectively.

What will it cost you in the cloud model? In the original example, you pay a one- time charge of $1,400 to lock in a price of $0.12/hour per large instance for three years. For an application you need for only six months, you can instead contract to lock in the same price of $0.12/hour for only one year at $910 per large instance. Over the six-month period, that amounts to a cost of $1,428/month for the instances plus the same costs as the original example for the bandwidth, load-balancer, VPN, and storage. This adds up to $580/month. The total cost becomes $2,008/month, which is clearly a substantial savings compared to either the internal IT or colocation models.

3.2.2 Scale variability/volatility

In the last section, what drove the cost savings for the cloud deployment was the finite time interval for which the application was needed. Let’s look at another application characteristic where the scale and load variability requirement can make it advanta- geous to deploy using a cloud model. Scale requirements for an application may vary in several ways. Some types of capacity variability are predictable, and you can antici- pate them. For example, the daily variations for financial or online trading applica- tions that see the most traffic and hence require the largest amount of capacity are at the open and close of the market. These applications typically see variations in traffic load of 4X between the open and close and the low point of the day.

Another example is the seasonal variation seen by online e-commerce sites in the days immediately following Thanksgiving, the traditional start of the Christmas shopping season. For these e-commerce applications, peak capacity requirements can be as much as 20X normal capacity requirements, as you can see in figure 3.3 for Target.com.

Daily United States People 09/02/09- 02/28/10

Oct ’09 target.com

Max: 3.0M 11/29/09

global stats not yet available for estimated data US

GLOBAL

Dec ’09

Nov ’09 Jan ’10 Feb ’10

Directly Measured Rough Estimate

1.2M 3.1M 2.5M 1.9M 1.3M .7M Rough Estimate

Figure 3.3 This chart shows the estimated daily number of U.S. visitors to Target.com as determined by Quantcast (www.quantcast.com/target.com) over a one-year interval. As it does for many

e-commerce sites, peak utilization occurs predictably at the end of November, at the start of the Christmas shopping season.

If you consider designing and building infrastructure in an internal IT or colocation deployment model to handle peak capacity 4X or 20X normal capacity, you’re look- ing at increasing the cost of the deployment by roughly the same factors. Granted, you’ll gain some efficiency by purchasing larger volumes, but these gains are minimal compared to the overall size of the difference in required investment to scale. At peak utilization times, the entire infrastructure will be maximally taxed servicing the appli- cation. At other times, it will be severely underutilized.

In the cloud model, you can manage predictable traffic peaks in a much more cost- effective manner. You can bring additional instances online to handle the increased load during the hours or days of the increased capacity. For example, if you require 4X the normal capacity at 9:00 A.M., and at other times of the day only four instances are needed, you can spin up 12 additional instances for the hour they’re needed and only pay for the additional instances when they’re active.

Other scale variations are less predictable. Event-driven spikes in scale requirements can hit with as little warning as a tsunami and have devastating effects on the operation of the application. One example illustrated in figure 3.4 is the spike in traffic on the TMZ.com website after they were the first to report the death of Michael Jackson on June 25, 2009.

Daily Global People 10/27/09-04/21/10 4.0M 3.0M 2.0M 1.0M 0 Dec ’09 Nov ’09

tmz.com Directly Measured

Embed Max: 3.9M Max: 290K Max: 108K Max: 187K Max: 86.8K Max: 2.9M 12/21/09 12/21/09 12/21/09 12/21/09 12/21/09 12/21/09 GLOBAL CA NL GB FI US Feb ’10

Jan ’10 Mar ’10 Apr ’10

Directly Measured Rough Estimate

1.7M 116K 4.3K 18.0K 1.1K 1.4M

Figure 3.4 This chart shows the estimated daily number of U.S. visitors to TMZ.com as determined by Quantcast (www.quantcast.com/tmz.com) between 6/03/09 and 8/31/09. This is an example of an event-driven spike in demand on 6/25/09, when TMZ.com was the first to report the death of Michael Jackson.

If you have to rely solely on resources deployed in either an internal IT model or a colocation model, you literally have no recourse but to try to weather out high-demand periods. If you have the ability to use the cloud and can dynamically spin up capacity, handling all the unexpected traffic will happen seamlessly.

3.2.3 Nonstrategic applications /low organizational value

The final example of a situation in which it may be economically advantageous to de- ploy in a cloud model is when you’re dealing with applications that are commodities and aren’t strategic to the business. Many tactical applications serve internal constitu- ents within an organization that could be moved to a cloud deployment, resulting in savings of scarce IT resources in an organization. A classic example is backup data stor- age . Instead of wasting internal IT resources on maintaining a backup system, you can use a cloud-based backup service . Because this is a core competency of the company providing the cloud backup service, it can be done more efficiently and economically by them than it can be by using internal IT resources. This can free up these resources to work on projects that are generally more strategic to the business.