Enterprise Applications in the Cloud:                           Analysis of Pay-per-use Plans               Leonid Grinshp...
Hourly price for application X on pay-per-resource plan is calculated by formula:  price of one resource unit per one hour...
of hardware resources; 2) forecasting the size of additional or excessive resources bymodeling; 3) using modeling to estim...
Figure 1 Model 1 of a Cloud hosting three enterprise applications;        each physical server hosts three virtual machines.
To solve the model we have to specify the profile of each transaction (Table 2). Thetransaction profile is a set of time i...
We solve the model for workloads featuring a number of users ranging from 100 to1000. Figure 1 shows transaction times as ...
Figure 2 Transaction Times (seconds) for App A, B, CThe three following charts (Figures 3, 4, 5) characterize the percenta...
Figure 4 Utilization of system servers by App B                    Figure 5 Utilization of system servers by App CWe can f...
Number of CPUs in Use by Each Application in Each Server                                                    Total number o...
The number of CPUs in use depends on the workload (in our case, a changingcomponent of the workload is the number of users...
Table 5                   Cloud Throughput per Application (transactions/hour)                                            ...
for CPUs, but for other hardware assets, and calculation of its cost is more complicatedand requires monitoring of usage o...
Upcoming SlideShare
Loading in...5
×

Enterprise applications in the cloud: analysis of pay-per-use plans

615

Published on

The article provides guidance to Cloud users and Cloud providers on cost/revenue estimates of Cloud services. It explores cost/revenue models for two pay-per-use plans: pay-per-resource and pay-per-transaction.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
615
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Enterprise applications in the cloud: analysis of pay-per-use plans

  1. 1. Enterprise Applications in the Cloud: Analysis of Pay-per-use Plans Leonid Grinshpan, Oracle Corporation (www.oracle.com)The Cloud-computing paradigm is attractive to businesses not only because of itstechnological, logistical, and environmental advantages over traditional IT frameworks.For the most part its magnetic pull has its roots in economy—Clouds are also wellsuited to save IT cost as they implement pay-per-use policies.While relocating enterprise applications (EA) into the Cloud, the corporations have tobe aware of the cost associated with Cloud services and its dependence on dynamicallychanging EA workloads. The same is true for Cloud providers: they have to know therevenue derived from each hosted EA. This article provides guidance to Cloud usersand Cloud providers on cost/revenue estimates. It explores cost/revenue models for twopay-per-use plans: pay-per-resource and pay-per-transaction. A modeling approach isbased on methodology described in the author’s book [Leonid Grinshpan. SolvingEnterprise Application Performance Puzzles: Queuing Models to the Rescue, Willey-IEEEPress, 2012. http://www.amazon.com/Solving-Enterprise-Applications-Performance-Puzzles/dp/1118061578/ref=ntt_at_ep_dpt_1].The pay-per-resource plan charges for the hardware capacity an EA uses at any giventime. Typically, resources are priced per hour; below is an excerpt from a price list byOpSource, a company providing Cloud and managed hosting services:[http://www.opsource.net/Services/Cloud-Hosting/Pricing]
  2. 2. Hourly price for application X on pay-per-resource plan is calculated by formula: price of one resource unit per one hour * number of resource units assigned to application XOne resource unit represents one CPU as well as fixed amount of RAM and storage (forexample, 1 GB). Network hardware and bandwidth are also priced per usage.The pay-per-transaction plan charges per each transaction processed by the Cloud. Asan example, Cloud application LinkedIn charges a minimum of $2.00 per transactionthat takes a user to an advertised Web page.Hourly price for application X on pay-per-transaction plan is calculated by formula:price of one transaction * number of transactions per hour processed by Cloud for application XIn order to determine the hourly price of each plan, we have to determine the number ofresource units assigned to application X, as well as the number of transactions per hourprocessed by the Cloud for application X. Both numbers are the functions of intensity ofdemand from application users as well as architecture and specifications of hostinghardware. The perfection in Cloud management is achieved when, at any givenmoment for each application, this logical equation is true: Demand = Resources. Aprovider is losing revenue when Demand > Resources (application “appetite” forcapacity is not satisfied), and customer is priced unfairly when Demand < Resources(application is overprovisioned).In Cloud that hosts EA (EAC), Demand is highly dynamic with peaks and valleys andthe Cloud management system has to permanently synchronize Resources withDemand. Synchronization includes the following steps that have to be executed in theshortest time to maximize Cloud profitability: 1) identification of an excess or shortage
  3. 3. of hardware resources; 2) forecasting the size of additional or excessive resources bymodeling; 3) using modeling to estimate an impact of resources reallocation (changemanagement); 4) effecting changes by reprovisioning resources.Step 1 is implemented by monitoring usage of Cloud hardware and EA transactiontimes. Steps 2 and 3 require modeling; Step 3 is a must-have in multi-tenant Clouds.Step 4 can be executed quickly if it requires reprovisioning of resources within theexisting virtual machine (VM); the step is more complicated and lengthy if the new VMhas to be deployed and an additional instance of EA has to be installed on it.Cost/Revenue ModelThe queuing model on Figure 1 represents a Cloud hosting three EAs (App A, App B,App C) on three physical servers. EAs have their own users accessing applications overthe network. Each Cloud’s physical server has 24 CPUs and is broken down by threeVMs with 8 CPUs. The users, network and VMs are modeled by dedicated nodes.The workload for the cost/revenue model is defined in Table 1. We assume for clarity’ssake that the workload of each application consists of transactions identified byapplication name. One user executes a transaction a number of times per hour indicatedin the last column of Table 1. The model is analyzed for the total number of users for allthree applications ranging from 100 to 1000. Table 1 Workload 1 for Cost/Revenue Model Number ofTransaction name Number of users per application transaction executions per user per hourApp A transaction 50 100 150 200 300 400 350 400 450 500 10App B transaction 25 50 75 100 150 200 175 200 225 250 20App C transaction 25 50 75 100 150 200 175 200 225 250 5 Total number of 100 200 300 400 600 800 700 800 900 1000 users
  4. 4. Figure 1 Model 1 of a Cloud hosting three enterprise applications; each physical server hosts three virtual machines.
  5. 5. To solve the model we have to specify the profile of each transaction (Table 2). Thetransaction profile is a set of time intervals (service demands) a transaction has spent inall processing units it has visited while served by the application. Table 2 Transaction Profiles (seconds) Time in Time in Web Time in App Time in Database Network node server node server node server node App A transaction 0.001 0.4 2.0 5.0 App B transaction 0.0015 0.2 1.0 5.0 App C transaction 0.003 0.4 5.0 5.0The workload identifies an intensity of requests generated by application users, whilethe transaction profile characterizes the time interval a single transaction will use Cloudresources. Table 3 specifies maximum transaction times acceptable by Service LevelAgreements (SLA): Table 3 Maximum Acceptable Transaction Times per SLA (seconds) Time (seconds) App A transaction 8.0 App B transaction 7.00 App C transaction 12.00To solve the model we specify the modeled hardware resources:We also specify the workload and transaction profiles for all EAs:
  6. 6. We solve the model for workloads featuring a number of users ranging from 100 to1000. Figure 1 shows transaction times as a function of the number of users. Themaximum accepted by SLA transaction time for App A is seven seconds; it is markedby character A and reached for 800 users. The maximum accepted by SLA transactiontime for App B is eight seconds; it is marked by character B and reached for 900 users.
  7. 7. Figure 2 Transaction Times (seconds) for App A, B, CThe three following charts (Figures 3, 4, 5) characterize the percentage of utilization ofsystem servers by each application. Figure 3 Utilization of System Servers by App A
  8. 8. Figure 4 Utilization of system servers by App B Figure 5 Utilization of system servers by App CWe can find out the number of CPUs consumed by each application as a function of thenumber of users. One CPU accounts for 100% / 8 = 12.5%; the number of CPUs per VMrounded up to the next integer is presented in a table below.
  9. 9. Number of CPUs in Use by Each Application in Each Server Total number of users Server name 100 200 300 400 500 600 700 800 900 1000 Application A Web server A 1 1 1 1 1 1 1 1 1 1 Application server A 1 1 1 1 2 2 2 3 1 3 Database server A 1 2 3 3 4 5 5 7 7 8 Total number of CPUs 3 4 5 5 7 8 8 11 9 12 Application B Web server B 1 1 1 1 1 1 1 1 1 1 Application server B 1 1 1 1 1 1 1 2 2 2 Database server B 1 2 3 3 4 5 5 7 7 8 Total number of CPUs 3 4 5 5 6 7 7 10 10 11 Application C Web server C 1 1 1 1 1 1 1 1 1 1 Application server C 1 1 1 1 1 1 2 2 2 2 Database server C 1 1 1 1 1 2 2 2 2 2 Total number of CPUs 3 3 3 3 3 4 5 5 5 5This table defines the number of CPUs in use by each application depending on thenumber of its users. Visual interpretation of this table is as follows: Number of CPUs per App A Number of CPUs per App B Number of CPUs per App C
  10. 10. The number of CPUs in use depends on the workload (in our case, a changingcomponent of the workload is the number of users). As we can see, because the Cloud’sprice per application is a function of the number of CPUs in use by that application, itultimately depends on the application’s workload fluctuation.Our model helps to determine the hourly cost of Cloud services for each application asa function of the number of users of the pay-per-resource plan (see chart on Figure 6,we assume that the cost of one CPU per hour is $1.00). Figure 6 Hourly cost of Cloud services as a function of the number of users of the pay-per-resource plan (cost of one CPU per hour is $1.00)A similar cost analysis can be executed for the pay-per-transaction plan using themodel-generated data in Tables 4 and 5. Table 4 Cloud Throughput per Application (transactions/sec) Total number of users Application 100 200 300 400 500 600 700 800 900 1000Application A 0.14 0.27 0.41 0.54 0.68 0.82 0.95 1.09 1.22 1.36Application B 0.13 0.27 0.40 0.54 0.67 0.81 0.94 1.07 1.21 1.34Application C 0.03 0.07 0.10 0.14 0.17 0.21 0.24 0.27 0.31 0.34
  11. 11. Table 5 Cloud Throughput per Application (transactions/hour) Total number of users Application 100 200 300 400 500 600 700 800 900 1000Application A 504 972 1476 1944 2448 2952 3420 3924 4392 4896Application B 468 972 1440 1944 2412 2916 3384 3852 4356 4824Application C 108 252 360 504 612 756 864 972 1116 1224Chart on Figure 7 shows hourly cost of Cloud services for each application as a functionof the number of users of the pay-per-transaction plan (we assume that cost of onetransaction is $0.01). Figure 7 Hourly cost of Cloud services as a function of the number of users of the pay-per-transaction plan (cost of one transaction is $0.01)Both charts let compare two pricing plans. The pay-per-transaction plan features alinear increase in hourly cost when the number of users increases; it enables a providerto forecast revenue without running models every time the number of users changes.The pay-per-resource plan exhibits more complicated behavior with linear as well asflat segments, making useless linear extrapolation. Moreover, this plan charges not only
  12. 12. for CPUs, but for other hardware assets, and calculation of its cost is more complicatedand requires monitoring of usage of all hardware components of the Cloud.With cost-revenue models at hand, a provider can forecast the Cloud’s profit as afunction of the applications workload, pricing plan and Cloud’s maintenance expenses.Takeaway from the Article 1. The most popular pay-per-use plans offered by Cloud providers are pay-per- resource and pay-per-transaction. 2. The pay-per-transaction plan is characterized by a linear increase in hourly cost when the number of users increases. 3. The pay-per-resource plan demonstrates more complicated dependence of its cost from a number of users with linear as well as flat segments; that makes linear extrapolation misleading. 4. Cost-revenue queuing models assist providers with forecasting the Cloud’s profit as a function of the application’s workloads, pricing plan and the Cloud’s maintenance expenses.About the AuthorLeonid Grinshpan has worked as an Oracle consultant for the last 15 years and washands-on engaged in performance tuning and sizing of enterprise applications forvarious corporations (Dell, Citibank, Verizon, Clorox, Bank of America, AT&T, BestBuy, Aetna, Halliburton, Pfizer, Astra Zeneca, Starbucks, etc.).

×