To Move or Not to Move: The Economics of Cloud Computing

Byung Chul Tak Bhuvan Urgaonkar Anand SivasubramaniamThe Pennsylvania State University

AbstractCloud-based hosting promises cost advantages over

conventional in-house (on-premise) application deploy-ment. One important question when considering a moveto the cloud is whether it makes sense for ‘my’ appli-cation to migrate to the cloud. This question is chal-lenging to answer due to following reasons. Althoughmany potential benefits of migrating to the cloud can beenumerated, some benefits may not apply to ‘my’ ap-plication. Also, there can be multiple ways in whichan application might make use of the facilities offeredby cloud providers. Answering these questions requiresan in-depth understanding of the cost implications of allthe possible choices specific to ‘my’ circumstances. Inthis study We identify an initial set of key factors affect-ing the costs of a deployement choice. Using bench-marks representing two different applications (TPC-Wand TPC-E) we investigate the evolution of costs for dif-ferent deployment choices. We show that applicationcharacteristics such as workload intensity, growth rate,storage capacity and software licensing costs producecomplex combined effect on overall costs. We also dis-cuss issues regarding workload variance and horizontalpartitioning.

1 IntroductionCloud-based hosting promises several advantages over

conventional in-house (on-premise) application deploy-ment. (i) Ease-of-management (although argumentsagainst this have also been made [6]): since the cloudprovider assumes management-related responsibilities,the customer is relieved of this burden and can focuson its core expertise. (ii) Cap-ex savings: it eliminatesthe need for purchasing infrastructure; this may translateinto lowering the business entry barrier. (iii) Op-ex re-duction: elimination of the need to pay for salaries, util-ity electricity bills, real-estate rents/mortgages, etc.Oneoft-touted aspect of Op-ex savings concerns the ability ofcustomer’s Op-ex to closely match its evolving resource

needs (via usage-based charging) as opposed to depend-ing on its worst-case needs.

The quintessential question when considering a moveto the cloud is: should I migratemy application to thecloud? Whereas there have been several studies into thisquestion [1, 7, 14], there is no consensus yet on whetherthe cost of cloud-based hosting is attractive enough com-pared to in-house hosting. There are several aspects tothis basic question that must be considered. First, al-though many potential benefits of migrating to the cloudcan be enumerated for the general case, some benefitsmay not apply to my application. For example, benefitsrelated to lowered entry barrier may not apply as muchto an organization with a pre-existing infrastructural andadministrative base. Second, there can be multiple waysin which an application might make use of the facili-ties offered by a cloud provider. For example, using thecloud need not preclude a continued use of in-house in-frastructure. The most cost-effective approach for an or-ganization might, in fact, involve a combination of cloudand in-house resources rather than choosing one over theother. Third, not all elements of the overall cost consid-eration may be equally easy to quantify. For example,the hardware resource needs and associated costs maybe reasonably straightforward to estimate and compareacross different hosting options. On the other hand, laborcosts may be significantly more complicated: e.g., howshould the overall administrators’ salaries in an organiza-tion be apportioned among various applications that theymanage? Answering these questions requires an in-depthunderstanding of the cost implications of all the possiblechoices specific tomy circumstances. Given that theseanswers can vary widely across applications, organiza-tions, and cloud providers, we believethe best way is toexplore various applications case-by-case in an attemptto draw generalities or useful rule-of-thumbs.This pa-per represents our first step towards this endeavor and wemake the following contributions.• We identify an initial set of key factors affecting the

costs of a deployment choice (in-house, cloud, and com-binations). We classify these as “quantifiable” and “lessquantifiable” based on how amenable they are to pre-cise quantification. We also classify costs into the well-regarded “direct” and “indirect” categories: the former’scontribution to the cost can be easily traced and ac-counted (e.g., server costs) while the latter’s contributionmay be ambiguous and require more meticulous account-ing (e.g., cooling costs).• Besides the two extreme deployment choices of purein-house and pure cloud-based hosting available to an ap-plication, we identify a spectrum of hybrid choices thatcan offer the best of both worlds. Our hybrid choicescapture both “vertical” and “horizontal” ways of parti-tioning an application, each with its own pros and cons.• Using benchmarks representing two different“commercial-like” applications (built using open-source vs. licensed software), cloud offerings (IaaSvs. SaaS), and workload characteristics (stagnant vs.growing, “bursty” or otherwise) we study the evolutionof costs for different deployment choices.

2 Background and Overview2.1 Net Present Value

The concept ofNet Present Value(NPV) is popularlyused in financial analysis to calculate the profitability ofan investment decision over its expected lifetime consid-ering all the cash inflows and outflows. Walker et al.have recently employed this concept in their work, fo-cusing mainly in separately exploring the feasibility ofrenting computing [14] and storage [15] from the cloud.While we employ the same NPV concept, we go be-yond this work: (i) as opposed to comparing rental vs.in-house costs only for a given hardware base, we com-pare the costs for hosting specific workloads (ii) we in-corporate additional costs such as software licenses, andelectricity, (iii) we study the impact of workload evo-lution/variance and cloud models (IaaS vs. Saas), andfinally (iv) we consider combinations of in-house andcloud hosting. Borrowing existing notation, we definethe NPV of an investment choice spanningY years intothe future as:NPV =

∑Y −1t=0

Ct

(1+r)t wherer is thedis-count rateand Ct the cost at timet. The role of thediscount rate is to capture the phenomenon that the valueof a dollar today is worth more than a dollar in the future,with its value decreased by a factor(1 + r) per year.

2.2 Cost ComponentsFigure 1 presents our classification of costs. Certain

cost components are less easy to quantify than others,and we use the phrases “quantifiable” and “less quantifi-able” to make this distinction. Examples of less quan-tifiable costs include effort of migrating an applicationto the cloud, porting an application to the programming

���������� �����������

��������

��

��������

��

������������� ������������������� �������� ���������� ���������� ����������

��������

���

�� �����

���������������������������������������

����� ���!����������������"��� � ��� ����#��#���������������$%&������ � � ������

��'����������� �#�������'���������#�������(�������������� ������!�� ��)

�!����������� ������*�����!���������#�

��+���� ���!� ����+���������#�����#� ���������,���#�����������

Figure 1: Classification of costs related to migration.

API exposed by a cloud (e.g., as required with Win-dows Azure), time spent doing the migration/porting,any problems/vulnerabilities that arise due to such port-ing or migration, etc. Adhering to well-regarded con-vention in financial analysis, we also employ the clas-sification of costs into the “direct” and “indirect” cate-gories based on their ease of traceability and accounting.If a cost can be clearly traced and accounted to a prod-uct/service/personnel, it is a direct cost, else it is an indi-rect cost. As shown in Figure 1, examples of direct costinclude hardware & software costs; examples of indirectcost include staff salaries. It should be noted that cer-tain costs may be less quantifiable yet direct (e.g., portingan application). Similarly, certain costs may be quantifi-able yet indirect (e.g., staff salaries, cooling, etc.) In thiswork, we restrict our focus to only quantifiable costs andleave less quantifiable costs for future work.

2.3 Application Hosting Choices

Besides pure in-house and pure cloud-based hosting,a number of intermediate/hybrid options have been sug-gested, and are worth considering [4]. We view theseschemes as combinations of different degrees of “verti-cal” and “horizontal” partitioning of the application. Ver-tical partitioning splits an application into two subsets(not necessarily mutually exclusive) of components - oneis hosted in-house and the other migrated to the cloud -and may be challenging if any porting is required [4].Horizontal partitioning replicates some components ofthe application (or the entire application) on the cloudalong with suitable workload distribution mechanisms.Such partitioning is already being used as a way to han-dle unexpected traffic bursts by some businesses (e.g.,KBB.com and Domino’s Pizza [16]). Such a partition-ing scheme must employ mechanisms to maintain con-sistency among replicas of stateful components (e.g.,databases) with associated overheads1. Given myriadcloud providers and hosting models (we consider IaaSand SaaS), there can be multiple choices for how a com-ponent is migrated to the cloud, each with its own cost

1Note that pure in-house and pure cloud hosting can be viewed asextreme cases of both these kinds of partitioning.

2

implications. In this work, we choose three such options(in addition to pure in-house and pure cloud-based) thatwe described next.

2.4 Our Methodology: A Brief Outline

We consider hosting options offered by two prominentcloud providers: Amazon and Windows Azure, includingboth IaaS (EC2 instances) and SaaS options (AmazonRDS and SQL Azure). We consider the following fivehosting options: (i) fully in-house, (ii) fully EC2 (the en-tire application is migrated to Amazon cloud within ap-propriately provisioned EC2 instances), (iii) EC2+RDS(similar to fully EC2 except the database which usesAmazon’s RDS SaaS), (iv) in-house+RDS (a verticalpartitioning where the database is migrated to Amazon’scloud to use its RDS SaaS while the remaining com-ponents are in-house), and (v) in-house+SQL Azure (avertical partitioning similar to (iv) with RDS replacedwith Microsoft’s SQL Azure SaaS). We compare thesehosting options for the following two applications fromTPC [12]: (1) TPC-W (a benchmark that emulates anonline bookstore) and (2) TPC-E (a benchmark that em-ulates online transaction processing in a brokerage firm).We assume that TPC-W is built using open-source soft-ware components (Apache, JBoss, Mysql) except for theOS (Windows), whereas TPC-E uses licensed software(SQL Server 2008 and Windows Server 2008). Both ap-plications have three tiers: Web, Java-based applicationlogic, database.

Our cost comparisons require us to make a number ofprojections/assumptions. We allow for a function that de-scribes workload growth over time (increasing, decreas-ing, or stagnant in its form) and incorporate this intoour NPV calculation. We incorporate both hardware andsoftware upgrades to up-to-date products at typical re-fresh cycles (4 years for both hardware and software).We project CPU, memory capacities based on Moore’sLaw (similar to [14]). E.g., we assume CPU speed dou-bles every two years.

Finally, we need to estimate the hardware needs ofour applications for a range of workload intensities (ex-pressed in transactions/second or tps). Our goal is to findconfigurations across hosting options that offer similar,satisfactory performance. We discuss the salient aspectsof our estimation here and present the details in a techni-cal report [8]. By running TPC-W on machines in our lab(each containing Intel Xeon 3.4GHz dual-processor with2GB DRAM), we identifymarginal throughput gainsof-fered by adding an extra server (and CPU) to a tier. Usingmicrobenchmarks, we determine cloud instance config-urations that offer “comparable” computing power andmemory (encouragingly our results match well with ex-isting work that has benchmarked RDS [5]). Since EC2instances come in much smaller sizes, a comparable in-

10K

20K

30K

40K

50K

1 2 3 4 5 6 7 8 Years

Cost(

$)

10K

30K

50K

70K

90K

110K

1 2 3 4 5 6 7 8 Years

(Hypothetical costassuming EC2 CPUpower improves by Moore’s Law)

(a) 20 tps at start, 20% growth (b) 100 tps at start, 20% growth

10K

20K

30K

40K

50K

1 2 3 4 5 6 7 8 Years

Cost(

$)

Fully InhouseFully EC2

EC2+RDSInhouse+RDS

Inhouse+SQL Azure

10K

30K

50K

70K

90K

110K

1 2 3 4 5 6 7 8 Years

Fully InhouseFully EC2

EC2+RDSInhouse+RDS

Inhouse+SQL Azure

(c) 20 tps, 0% growth (d) 100 tps, 0% growth

Figure 2: NPV over a 10 year time horizon for TPC-W.We consider small (20 tps at t=0) and medium workloadintensity (100 tps), as well as stagnant and 20% growth.

cloud configuration has a larger number of VMs. E.g.,the EC2small instance has an effective CPU of 1.1 GHzimplying each of our lab machines is equivalent to aboutthree of these. For TPC-E, we are unable to carry out abenchmarking-based estimation since we do not have thelicense for a MS SQL server. Instead, we employ perfor-mance and cost results offered for TPC-E on the TPCWeb site for a number of machine, network, and storageconfigurations [12]. We note that the general problemof modeling resource needs is non-trivial with extensivework for in-house (including ours [13]) and emergingwork for the cloud [11], and incorporating such estimatesinto our costs may be a useful future direction.

3 Our NPV Analysis: Key Results3.1 Workload Intensity and Growth

Figure 2 presents NPV calculations for up to a 10 yeartime horizon for TPC-W. We present results with twoworkload intensities at the beginning: (i) 20 tps and (ii)100 tps, which represent “small” and “medium” in theoverall spectrum we consider [8]. We also present twointensity growth scenarios: (i) stagnant and (ii) 20% in-crease per year; we have also considered other growthrates. As the workload intensity grows, TPC-W re-quires more servers and higher IO bandwidth but itsstorage capacity needs do not change. Overall, we findthatin-house provisioning is cost-effective for medium tolarge workloads, whereas cloud-based options suit smallworkloads.For small workloads, the servers procured forin-house provisioning end up having significantly morecapacity than needed (and they remain under-utilized)since they are the lowest granularity servers availablein market today. On the other hand, cloud can offerinstances matching the small workload needs (due to

3

�����

����

�����

�����

���������

��������������

������������ �����

���������������

����������

����� ����

�����

����� ����

�����

�������

���������������

����� �� ���

���������������� �� ���

����

��������������

���������

����������

������

�����������

���� ���� ��������������

�����

����

���������

����

������������� �

�����

��������������������

������ ���������

�������

��������

(a) Fully EC2 ($22K) (b) EC2+RDS ($29K) (c) In-house+RDS ($70K) (d) In-house+SQL Azure ($63K)

Figure 3: Closer look at cost components for four cloud-based application deployment options at 5th year. Initialworkload is 100 tps (Transaction Per Second) and the annual growth rate is 20%.

the statistical multiplexing and virtualization it employs).For medium workload intensity, cloud-based options arecost-effective only if the application needs to be sup-ported for 2-3 years, and become expensive for longer-lasting scenarios. These workload intensities are ableto utilize well provisioned servers making in-house pro-curement cost-effective.

An interesting trend is thesignificantly slower NPVincrease for in-house compared to cloud-based options,which may be partly explained as follows. Since we as-sume hardware capacity growing according to Moore’sLaw, unless the workload growth matches or exceeds thisrate, the number of servers required in-house will actu-ally shrink each year. However, things evolve differentlywith cloud-based options. The computing power as wellas price of a cloud instance are intentionallyengineeredto be at a certain level (via virtualization and statisticalmultiplexing) even though cloud providers may upgradetheir hardware regularly (just as in-house). E.g., sincethe start of EC2 in 2006, the computing power/memoryper instance has remained unchanged while there hasbeen only one occasion of instance price reduction. Inother words, while in-house hosting enjoys improvementin performance/$ with time, trends over the last 5 yearssuggest that the performance/$ offered by the cloud hasremained unchanged2. Even if we assume the perfor-mance/$ offered by the cloud improves with time (say, aninstance of given capacity becomes cheaper over time),cloud-based provisioning still remains expensive in thelong run since data capacity and transfer costs contributeto the costs more significantly than in-house (See Fig-ure 2(b)).

3.2 Data Transfer, Storage Capacity, SoftwareLicenses

We illustrate in Figure 3 detailed breakdowns of NPVfor five-year long hosting of TPC-W for options involv-ing the cloud (i.e., options (ii)-(v) from Section 2). Over-all, we find thatdata transfer is a significant contribu-tor to the costs of cloud-based hosting- between 30%-

2It is important to remember that the improvements in perfor-mance/$ for in-house accrue due to investments made in upgrades.

70% for TPC-W. This suggests thatvertical partition-ing choices may not be appealing for applications thatexchange data with the external world.Data transfercosts in Figure 3(c),(d) are larger than those in Fig-ure 3(a),(b) because traffic per transaction between Jbossand MySQL (16KB/tr) is larger than between clients andApache (3KB/tr).

Another determining factor to costs with cloud-basedhosting can be storage capacity. Whereas TPC-W posesrelatively small costs for storage capacity (its databaseonly needs a few GB and its storage capacity costs donot even show up in Figure 3), TPC-E has significant datastorage needs (about 4.5TB). Figure 4 presents the NPVevolution for TPC-E for two initial intensities - 300 tps(medium) and 900 tps (high) with 20% annual growthrate. We only present “Fully in-house” and two cloud(“Fully EC2” and “EC2+SQL server”) options since wehave already established the high costs of vertical par-titioning. We find that in-house provisioning for TPC-Ehas to make significant investments in high-end RAID ar-rays (gap A), that constitute about 75% of overall costs.For initial workload intensity of 300 tps, these costs godown substantially with “Fully EC2” (i.e., renting stor-age from EC2 is cheaper than the amortized cost ofprocuring this much storage in-house), causing the over-all costs to improve by 50% (year 1, shown as gap A) and28% (year 6, shown as gap B in Figure 4).

The software licensing fee for SQL Server and Win-dows can also be a significant contributor to TPC-Ecosts: second (17.4% of overall) and largest (67%) con-tributor, respectively, for “Fully in-house” and “FullyEC2” options. Usingpay-per-useSaaS DB allows theelimination of SQL Server licensing fees (shown as gapC in Figure 4) and results in even better costs.SaaSoptions can be cost-effective for applications built us-ing software with high licensing/maintenance fee. Notethat these concerns did not arise with TPC-W which em-ployed open-source software, implying a different order-ing of cost-efficacy among options.

It is also worth comparing the cost evolution for thetwo intensities in Figure 4. With medium intensity(300tps), in-house option is less attractive than cloud-

4

� � � � � � � � �

����

����

����

����

��

�� ���� ����

����

�����

����

� ����������� �� ���������������� �� �������������

�������

���������������

Figure 4: Two sets of TPC-E results at initial workloadof 300 tps and 900 tps.

based options for the entire 10 year period without everhaving a cross-over. However, at the higher intensity(900tps), cloud-based options quickly (after 2 years for“Fully EC2” and after 4 years for “EC2+SQL server”)become more expensive than in-house. This is qualita-tively similar to the observations for TPC-W. However,cloud-based options remain attractive for a larger rangeof workload intensity than for TPC-W (compare Figure 4with Figure 2(b) both of which have the same growth ratebut differ in intensity by a factor of 9) - the key reasonsfor this difference are gaps B and C, i.e., the higher stor-age costs for in-house TPC-E as well as the contributionof software licenses in non-SaaS options.

A final interesting phenomenon arises due to thefollowing: when buying cloud instances for TPC-Edatabase, we do find instances that offer required compu-tational power per core but limited in total number per in-stance. The most powerful instance has 8 virtual cores of3.6Ghz clock speed whereas In-house server used in theanalysis uses 12 cores. This forces the cloud-based op-tions to procure more number of instances than in-house.In addition to this, the pricing policy of charging the li-cense fee per virtual core drastically increases requiredSQL server licenses to purchase (since Microsoft chargesonly for the physical cores in non-virtualized environ-ment). This suggests thata reconsideration of softwarelicensing structures, particularly as applicable to large-scale parallel machines, may be worthwhile for makingcloud-based hosting more appealing.

3.3 Workload Variance and Cloud ElasticityOur cost analysis so far were based onaveragework-

load intensities. Given high burstiness (i.e., high peak-to-average ratio or PAR) in many real workloads, itis common in practice to provision close to thepeak.Whereas in-house provisioning must continue this prac-tice, the usage-based charging and elasticity offered bythe cloud open new opportunities for savings (for bothin-cloud and horizontal partitioning). We investigate

10K

40K

70K

100K

130K

160K

190K($)

1 2 3 4 5 6 7 8 Year

PAR=1.0PAR=1.54

PAR=11PAR=51

Fully EC2

5K

10K

15K

20K

25K

30K

($)

300 600 900 1.2K 1.5K tps

OptimalThreshold

In-house partCloud part

Overall

(a) In-house Cost Change (b) Horizontal Partitioning

Figure 5: Effect of workload variance and horizontal par-titioning on in-house cost.

costs of variance-aware provisioning for three degrees ofburstiness corresponding to time-of-day effects and flashcrowds. Researchers have reported the magnitude ofdaily workload fluctuations to be in the 40%-50% rangefor social networking applications, and about 70% fore-commerce Web site. Flash crowds can cause ordersof magnitude higher peaks than the average and becomea particularly appealing motivation for considering theuse (perhaps partial) of cloud. We choose PAR of 1.54(min=40, max=135 tps) to represent daily variations andPAR values of 11 and 51 to represent two flash crowdscenarios (i.e., peak of 10 and 50 times the average, re-spectively).

Figure 5(a) illustrates the effect of three levels ofburstiness on the in-house provisioning cost. We selectthe case of in-house with medium & increasing work-loads (Figure 2(b)). Provisioning for the diurnal fluc-tuation of 70% (PAR=1.54) does not impact the costwhereas flash crowd noticeably increases costs. Pro-visioning for PAR=51 shifts the cross-over point with“Fully EC2” from year 2.5 to year 10. The reason whydiurnal fluctuation does not affect the cost is becauseprovisioned servers already have enough capacity to em-brace the peak of diurnal fluctuation. But, provisioningfor flash crowds can substantially increase the cost.

We explore the benefits offered by a horizontal parti-tioning scheme that sets a threshold of workload inten-sity over which we create a replica in the cloud to handlethe excess. Fig. 5(b) shows the cost change over a rangeof threshold at year 1. We assume a lognormal(µ:0,σ:1)distribution (mean:500tps) to simulate the bursty traffic.Blue dotted line in Fig. 5(b) is the overall cost, the sumof two components - in-house and cloud part. As thethreshold moves to higher workload intensity, in-housecost rises in order to acquire more capacity, and the cloudcost lessens since the probability of overflowing the in-house server capacity diminishes. The equilibrium pointwhere the cost is minimum is found at 1100 tps. Thissuggests thathorizontal partitioning can be effectivelyused to eliminate the cost increase from provisioning forthe peak.

5

4 Related WorkWalker [14] has looked at issues related to the eco-

nomics of purchasing or leasing CPU hours using theNPV concept. The focus of his work is to provide amethodology that can aid in deciding whether to buy orlease the CPU capacity from the organization’s perspec-tive. His analysis ignores application-specific intricacies.For example, in calculating the cost of leasing the CPUhours from Amazon EC2, total required CPU hours is as-sumed to be statically fixed. Similarly, Walker et al. [15]also studied the problem of using storage cloud vs. pur-chasing hard disks. Our study differs from these in asense that we try to address the question at the level ofindividual applications.

Gray [3] has looked at economics in the context of dis-tributed computing and he came up with the amount ofresource users can buy with one dollar in the year 2003.He found that since data transfer costs are non-negligiblefor Web-based applications, it is economical to optimizethe application towards reducing data transfer. Armbrustet al. [1] have extended the cost analysis of Gray’s datainto the year 2008 and presented how the cost of eachresource type evolved at different rate. They have alsopointed out that cost analysis can be complicated due tocost factors such as power, cooling and operational costs,which are in many cases difficult to quantify.

In our prior work we have also addressed some eco-nomic issues of cloud migration as they apply to digi-tal library and search systems such as CiteSeer [10, 9].CloudCmp [7] attempts to develop a set of benchmarksthat allow users to compare various cloud providers andselect the most economical ones for their applications.Campbell et al. [2] carry out simple calculations to de-termine the break-even utilization point for owning vs.renting the system infrastructure for a medium-sized or-ganization.

5 Conclusions and Future DirectionsIn this study we have investigated the migration costs

of several deployment options using popular bench-marks. We have shown that application characteristicssuch as workload intensity, growth rate, storage capacityand software licensing costs produce complex combinedeffect on overall costs. We have also briefly explainedissues regarding workload variance and horizontal parti-tioning. Overall, we find that (i) complete migration totoday’s cloud is appealing only for small/stagnant busi-nesses/organizations, (ii) vertical partitioning options areexpensive due to high costs of data transfer, and (iii) hor-izontal partitioning options can offer the best of in-houseand cloud deployment for certain applications.

Our work opens up interesting possibilities for futurework. We would like to incorporate indirect costs (andalso less quantifiable costs in some meaningful way). As

immediate work, we are extending our study to a broaderset of applications such MapReduce and undergraduatelabs at Penn State.

AcknowledgmentsThis research was supported, in part, by NSF grant

CNS-0720456, NSF CAREER award CNS-0953541,and NSF grant 0615097.

References[1] A RMBRUST, M., FOX, A., GRIFFITH, R., JOSEPH, A. D.,

KATZ , R., KONWINSKI, A., LEE, G., PATTERSON, D. A.,RABKIN , A., STOICA, I., AND ZAHARIA , M. Above the clouds:A berkeley view of cloud computing, Feb 2009.

[2] CAMPBELL , R., GUPTA, I., HEATH, M., KO, S. Y., KOZUCH,M., KUNZE, M., KWAN , T., LAI , K., LEE, H. Y., LYONS, M.,M ILOJICIC, D., O’HALLARON , D., AND SOH, Y. C. Open cir-rustmcloud computing testbed: federated data centers for opensource systems and services research. InProceedings of the2009 conference on Hot topics in cloud computing(Berkeley, CA,USA, 2009), HotCloud’09, USENIX Association, pp. 1–1.

[3] GRAY, J. Distributed computing economics.Queue 6(May2008), 63–68.

[4] HAJJAT, M., SUN, X., SUNG, Y.-W. E., MALTZ , D., RAO, S.,SRIPANIDKULCHAI , K., AND TAWARMALANI , M. Cloudwardbound: planning for beneficial migration of enterprise applica-tions to the cloud. InProceedings of the ACM SIGCOMM 2010conf.

[5] K OSSMANN, D., KRASKA, T., AND LOESING, S. An evalua-tion of alternative architectures for transaction processing in thecloud. In Proceedings of the 2010 international conference onManagement of data(New York, NY, USA, 2010), SIGMOD ’10,ACM.

[6] K OTSOVINOS, E. Virtualization: Blessing or curse?Queue 8,40:40–40:46.

[7] L I , A., YANG, X., KANDULA , S.,AND ZHANG, M. Cloudcmp:comparing public cloud providers. InProceedings of the 10th an-nual conf. on Internet measurement(New York, NY, USA, 2010).

[8] TAK , B., URGAONKAR, B., AND SIVASUBRAMANIAM , A. ToMove or Not to Move: The Economics of Cloud Computing.Tech. rep., Penn State Univ.http://csl.cse.psu.edu/papers/tr cse 11 002.pdf.

[9] TEREGOWDA, P., URGAONKAR, B., AND GILES, C. L. Cite-seerx: A cloud perspective. InProceedings of the SecondUSENIX Workshop on Hot Topics in Cloud Computing(Jun2010).

[10] TEREGOWDA, P., URGAONKAR, B., AND GILES, C. L. Cloudcomputing: A digital libraries perspective. InProceedings of the2010 IEEE 3rd International Conference on Cloud Computing(Washington, DC, USA, 2010), CLOUD ’10, IEEE ComputerSociety, pp. 115–122.

[11] TICKOO, O., IYER, R., ILLIKKAL , R., AND NEWELL, D. Mod-eling virtual machine performance: challenges and approaches.SIGMETRICS Perform. Eval. Rev. 37(January 2010), 55–60.

[12] Transaction Processing Performance Council.http://www.tpc.org/.

[13] URGAONKAR, B., AND CHANDRA , A. Dynamic provisioningof multi-tier internet applications. InProceedings of the ICAC2005.

[14] WALKER , E. The real cost of a cpu hour.Computer 42(April2009).

[15] WALKER , E., BRISKEN, W., AND ROMNEY, J. To lease or notto lease from storage clouds.Computer 43(April 2010), 44–50.

[16] WINDOWS AZURE LESSONS LEARNED. http://channel9.msdn.com/Blogs/benriga/.

6