BUSINESS MODELS BASED IN CLOUD COMPUTING ELASTICITY NEEDS

Transcription

1 BUSINESS MODELS BASED IN CLOUD COMPUTING ELASTICITY NEEDS Nikolaos Chelmis: Department of Digital Systems University of Piraeus, Greece Marinos Themistocleous: Department of Digital Systems University of Piraeus, Greece Dimosthenis Kyriazis: Department of Digital Systems University of Piraeus, Greece Abstract Nowadays, interest on Cloud Computing as a technical and business best practice has grown to great length. There is a huge pool of available cloud applications and services offered to end users. As application requirements, reflected to resources requirements (i.e. network, storage, computing capacity), are set by the application provider, a key issue relates to the resulting elasticity needs and their modelling. In addition to elasticity needs, application providers aim to maximize their customer base while considering the associated costs. To this end, business models are needed in order to attract customers while considering cost constraints. Their aim is to optimize the performance of the investment for resources compared to the expected number of customers. Nevertheless, the latter is directly linked to the provided quality of service and users quality of experience. To this direction, in this paper we present three sample business models that dynamically map current and expected number of users with the planned and estimated resources based on varying needs. Keywords: Cloud Computing, Elasticity, Scalability, Business Model, Quality of Service. 1 INTRODUCTION Cloud computing as a whole has rapidly evolved and became one of the most challenging paradigms of Information Technology. It has gained popularity for its ability to enable fast and effective access to large pools of virtualized resources and services that are dynamically provisioned to adjust to variable workloads and usage optimization (Grance, 2011). This pool of resources is typically exploited by a pay-as-you-go (Suleiman et al., 2012) pricing model with the cost of using a cloud asset depending on the resources consumed. To this direction, cloud computing offers mechanisms to automatically scale applications in order to meet user's needs, thus making possible for them to rapidly adapt their resources to the workload minimizing the cost of overprovisioning. While scalability enables smooth application execution even when number of users grows, two approaches are mainly used to make new resources available (Rimal et al., 2009): (i) Vertical scalability (scale up/down) increases or decreases the resources (commonly the Central Processing Unit - CPU number, the memory or bandwidth) of an element in the system. (ii) Horizontal Scalability (scale in/out) replicates or removes instances of system elements (usually Virtual Machines - VMs) to balance the workload. Elasticity is the ability to scale an infrastructure on demand within minutes (seconds in an optimum case) to avoid under-utilization and over-utilization of resources. Scalability is 1

2 a prerequisite for elasticity, but it does not take into consideration how fast or how often scaling actions can be performed thus it is not directly related to how well the actual resource demands are matched by the provisioned resources an any point of time (Herbst et al., 2013). Moreover, modern business trends highlight opportunities for service provisioning via cloud infrastructure to the end users. Three main models have prevailed: (i) direct service provision to the end user (e.g. Dropbox), (ii) use of cloud infrastructure for an organization s internal purposes (e.g. internal network of a bank) and (iii) use of cloud infrastructure to provide a service to the end users. This paper focuses on the third model, which is being exploited by application providers / owners - referred as brokers. The service provided may be any software system, consisting of one or more components. Its architecture, in terms of components, interfaces and logic, is considered to be known and can be precisely described by the provider / owner. As application requirements, regarding the resources, are formulated by the aforementioned brokers, a key issue relates to the resulting elasticity needs and their modelling. Elasticity and requirements are dependent on the following parameters: (i) application s nature (i.e. use of multiple processors), (ii) usage (i.e. variable exponential growth of end-users) and (iii) infrastructure vendors (i.e. resource availability). In order to analyse elasticity requirements, models that meet the above parameters and allow use of the analysis results to provide resources based on demand are required. In addition to elasticity issues, application providers / owners aim to maximize their customer base while considering the cost. Towards this direction, dynamic business models that suggest ways to attract customers are required, with an ultimate goal to optimize the investment made for resources compared to the foreseen number of customers. Nevertheless, the expected number is directly linked to the Quality of Service (QoS) provided and users Quality of Experience (QoE). For example if provisioned resources follow demand, a number of users will have to wait for resource s availability and hence the use of service. In economic terms overprovisioned resources are easily measured but underprovisioned is way harder. End users who were unable to use the application or experienced performance degradation (lower levels of QoS) may never become returning customers and discredit the service. Based on the above, a dynamic model, efficient for business, regarding both current users and expected ones compared to elasticity needs, is required. Nonetheless, the efficiency of business models needs to be linked to the required resources that accommodate the users expectation regarding QoS. The linkage / mapping should allow elasticity models to be followed compared to different business model (aggressive, passive, neutral) resulting in the optimal resource management. Furthermore business models should be able to be flexible and correspond to different types of applications (i.e. applications that heavily use CPU or Memory etc). In this paper we present sample business models enabling the latter. The remainder of this paper is structured as follows: Section 2 presents the related work while Section 3 proposes the dynamic business models. Section 4 discusses the validation method and finally section 5 summarizes future plans and concludes our work. 2 RELATED WORK Elasticity, a term originally defined in physics, is considered one of the central attributes of the cloud. Cloud providers use the term in advertisements and even in the naming of products or services and implement it in different degrees. It is defined in (Herbst et al., 2013) as the degree to which a system is able to adapt to workload changes by provisioning and deprovisioning resources in an autonomic manner, such that at each point in time the available resources match the current demand as closely as possible. Microsoft s Windows Azure consists of three main components providing a set of services to cloud users for running applications and storing data. Azure offers specific VM instances with predefined sizes (CPU, Memory). Automatic scaling is offered through application rules via a configuration file specified by users. 2

3 Google App Engine is optimized for web applications. It handles the deployment, monitoring and launching of service instances making use of Google s core engine. Automatic scalability is transparent to the application providers / owners with no option for the developer to write his own scaling rules based on application s specific needs. Amazon EC2 (Amazon) allows VMs to scale vertically in order to reciprocate with resource requirements. Customers can change resource requirements but in order to achieve horizontal scalability a cluster of VMs must be created and configured according to needs. This is a manual process which does not include application configuration of a VM. Amazon EC2 enables the preparation of the VM but not the automatic configuration which is a major requirement for an elastic platform. Amazon offers a service called Spot Instances, an elasticity solution based on cost. Spot Instances are virtual servers sold per hour via an action. Based on bids and available capacity Amazon determines a price (Spot Price) and if the maximum bid price exceeds the current Spot Price the request is fulfilled. RightScale is an application management platform for clouds addressing the Infrastructure-as-a- Service (IaaS) service model. RightScale provides control and elasticity capabilities, assisting the user to design, deploy and manage applications on a number of underlying clouds (i.e. Amazon, Rackspace, private solutions like CloudStack, OpenStack and others). Various monitoring metrics are used and users can define alerts based on these metrics. OnApp is a software package for IaaS cloud providers. It states that it enables replication and redimensioning on VMs allowing changes manually or automatically, based on rules defined by user and metrics obtained by the monitoring mechanism. Lim et al. (Lim et al., 2009)proposed an automatic mechanism based on a target range for a specific system metric, rather than a threshold to trigger actions. The key point is that the system reacts when the defined metric is outside the range, reducing resources allocations. Internal provider resources management and use of elasticity is addressed by Meng et al. (Meng et al., 2010). According to authors, management tasks (like VM creation, migration etc.) are expensive in terms of computation and more likely to occur in bursts. Lack of resources to handle this workload will affect users applications performance. Based on this observation, TIDE: a self-scaling framework for virtualized data center management, was proposed. The main idea is to treat management workload the way application workload would be treated. When bursts in management workload are encountered by TIDE, it powers up dynamically additional server management instances. When burst subsides, management instances physical resources can be used for user application workloads. The approaches discussed above, use reactive techniques in order to meet the demand on resources. The use of reactive techniques is quite common in most commercial solutions and is found in a lot of academic works. These solutions are based on the pattern Rule Condition Action (Vaquero et al., 2011) in which a rule is composed of a set of conditions that when satisfied trigger some actions over the underlying cloud. Every condition considers an event or a metric of the system which is compared against a threshold. The information about metrics values and events is provided by the infrastructure monitoring system or by the application. The proposed v make use of the aforementioned pattern while implementing the business logic in it, thus making it easier for an application owner to fully exploit the cloud infrastructure while achieving maximum return on investment. 3 BUSINESS MODELS Dynamic business models reflect how the current and the forecasted number of users relate to the application needs (and thus resource requirements) for specific predefined QoS levels. Given that the provided service can be charged based on different models, three main ones are proposed (i) Aggressive, (ii) Passive, (iii) Neutral. Each model guarantees different response time, therefore aims to different customer base size. Concept of man hours, cost for supplies etc. are out of the scope of this 3

4 work therefore are not taken into consideration. The core set of parameters incorporated in the considered business models follow: 1. Cloud Resources (a) Type (e.g. CPU, Memory) (b) Availability 2. Usage (a) Number of users currently using application (b) Target users (c) Number of acquired users 3. Cost (a) Cost of acquiring resources (b) Gain from users acquired The above parameters are directly and dynamically linked / related to each other. For instance, increase of users means more revenue but it also means increase in response time. In order for the response time to be maintained within specific limits, additional resources may need to be acquired. Accordingly, decrease in the number of users means lower response time, reducing the need for resources. In order to create the dynamic business models the concepts of minimum (t L ) and maximum (t U ) response time are introduced. Response time should never exceed any of these two limits. Another key element taken into consideration is spin-up time (Brebner, 2012). The amount of time needed, since initial acquisition request, for required resources to be ready for use is called spin-up time. All the attributes used for the creation of the business models are summarized in Table 1. Components RT t L t U t SU initdep res Explanation Response Time Best Minimum guaranteed response time Worst Maximum response time Spin Up Time Initial Deployment Resources a, b, c Weighting factors Goal Users Number of target users Table 1. Business Models Components Based on the above, the following paragraphs present the business models taken into account in the current work: Passive, Neutral, and Aggressive. 4

5 3.1 Passive Model This model ensures that users do not experience violation of the maximum response time but allows response times to be close to the maximum ones. To achieve that the difference between current response time and minimum response time is examined and if it exceeds a predefined amount (e.g. 500ms) then more resources are requested. Bursting (i.e. extreme growth in user numbers) is also taken into consideration as current response time is contradicted to maximum response time. Cloud burst is a QoS metric used to gauge cloud solution scalability and measure software application capability and performance on hosted cloud platforms. Spin-up time is not taken into consideration at this model. Finally, to avoid overprovisioning current response time is compared to minimum response time and if it is less then all acquired resources are released. This model is described in (1) and its flowchart is illustrated in Figure 1. Figure 1. Passive Business Model 3.2 Neutral Model This model s target is to prevent users, even in bursting, to come too close to maximum response time. It follows same logic as the above model comparing current response time with minimum and maximum. This model takes into consideration spin-up time in cases of bursting. Furthermore if 5

6 number of target users is reached more resources are acquired as a bonus to users. This model is described in (2) and its flowchart is illustrated in Figure 2. Figure 2. Neutral Business Model 3.3 Aggressive Model This model makes sure users are as close as possible to minimum response time. It is similar to Neutral model although it s weighting factors are bigger. This model is described in (3) and its flowchart is illustrated in Figure 3. 6

7 Figure 3. Aggressive Business Model 4 RESEARCH METHODOLOGY Various research methods can be used to test the aforementioned business models. A Descriptive / Qualitative research method involves describing in details specific situation using research tools like interviews, surveys, and observations. It focuses on gathering of mainly verbal data rather than measurements (SERVECenter, 2008). Descriptive / Quantitative requires quantifiable data involving numerical and statistical explanations. It generates numerical data or information that can be converted into numbers. The presentation of data is through tables containing data in the form of numbers and statistics. 7

8 Since the main goal of this paper is to test in practice the proposed models and compare them with current ones, numeric results need to be produced. An experimental procedure which is a subset of Descriptive / Quantitative research method will be followed in order to achieve this goal. In our case the dependent variable is the response time while the independent variables are the (i) resources and (ii) number of users. According to (Saunders et al., 2011) an experiment will typically involve: 1. Definition of a theoretical hypothesis; which in our case is the proposed business models; 2. Selection of samples of individuals from known populations; 3. Random allocation of samples to different experimental conditions; 4. Introduction of planned intervention or manipulation to one or more of the variables; 5. Measurement on a small number of dependent variables 6. Control of all other variables To conduct the experiment an application based on Service-Oriented Architecture (SOA), which produces a random alphanumeric code on request will be deployed and tested as part of the Pincloud project (Koumaditis K. et al., 2014). The rules of each business model will be applied in every experiment. To create traffic (i.e. number of users) apache JMeter will be used (Suffian et al., 2014). Apache JMeter is a tool that can be used to test applications utilizing HTTP or FTP servers. It is Java based and highly extensible through a provided API. The test will involve creating a loop and a thread group which is designed to simulate a concurrent load. The loop simulates sequential requests to the server with a preset delay. Each test will run three times (one for each business model). Goal is to replicate real world scenarios like: (i) rapidly increasing number of users (ii) slowly increasing number of users (iii) a steady amount of users and an occurring burst (iii) steady amount of users and multiple occurring bursts (iv) a steady decrease in the amount of users and finally (v) a rapid decrease in the amount of users. The aim of the aforementioned tests is twofold. First to test the validity of the proposed business models while in second time to explore and present which business model should be used in any given real world scenario. 5 CONCLUSION & FUTURE WORK The objective of this paper was to present dynamic business models whose aim is to optimize the performance of the investment for resources compared to current and expected number of customers. Application requirements reflected to resources requirements where modelled and mapped to elasticity needs. Emphasis was given in QoS ensuring while maximizing the customer base. An application provider, according to the expecting number of users, may use one of the above business models. The pattern Rule Condition Action (Vaquero et al., 2011) which was discussed in Section 2 was implemented. The aforementioned models explicitly set the rules which compose the conditions. Thresholds are set based on the response time promised by the provider. Spin up time is taken into consideration so even in situations which bursting occurs end users will not experience any delays. Weighting factors can be set according to application s nature and user s growth. These models are highly customizable. Instead of using the Initial Deployment value (referred as initdep) specific metrics can be set (e.g. CPU, or Memory). Accordingly resources (referred as res) can be set specifically in order to meet application s exact needs. 8

9 Furthermore, a limitation of the research presented herein is that the models discussed above cover only applications which are response time depended. In other words, since user s expectations differ from application type to application type (e.g. an application which offers storage capacity is storage depended) the proposed models are not suitable. Future work may include a complete categorization for application types and at a second time business models covering all application s types based on criteria which will derive from the aforementioned categorization. Acknowledgments. The research leading to the results presented in this paper has received funding from the European Union and the Greek National Strategic Reference Framework Programme (NSRF ), Project PinCloud under grant agreement number 11SYN_6_1013_TPE. References Amazon EC2 Spot Instances [Online]. Available: Google App Engine [Online]. Available: Microsoft Windows Azure [Online]. Available: onapp [Online]. Available: RightScale [Online]. Available: AMAZON. Amazon EC2 [Online]. amazon.com: amazon. Available: BREBNER, P. C. Is your cloud elastic enough?: performance modelling the elasticity of infrastructure as a service (iaas) cloud applications. Proceedings of the third joint WOSP/SIPEW international conference on Performance Engineering, ACM, GRANCE, P. M. A. T NIST Definition of Cloud Computing, Version NIST. HERBST, N. R., KOUNEV, S. & REUSSNER, R. Elasticity in Cloud Computing: What It Is, and What It Is Not. Proceedings of the 10th International Conference on Autonomic Computing (ICAC 2013), San Jose, CA, KOUMADITIS K., THEMISTOCLEOUS M., VASSILACOPULOS G., PRENTZA A., KYRIAZIS D. & F.., M Introducing a Patient-Centered e-health Record Over The Cloud. The Third International Conference on Global Health Challenges (GLOBAL HEALTH 2014). Rome, Italy. LIM, H. C., BABU, S., CHASE, J. S. & PAREKH, S. S Automated control in cloud computing: challenges and opportunities. Proceedings of the 1st workshop on Automated control for datacenters and clouds. Barcelona, Spain: ACM. MENG, S., LIU, L. & SOUNDARARAJAN, V Tide: achieving self-scaling in virtualized datacenter management middleware. Proceedings of the 11th International Middleware Conference Industrial track. Bangalore, India: ACM. RIMAL, B. P., EUNMI, C. & LUMB, I. A Taxonomy and Survey of Cloud Computing Systems. INC, IMS and IDC, NCM '09. Fifth International Joint Conference on, Aug SAUNDERS, M. N., SAUNDERS, M., LEWIS, P. & THORNHILL, A Research methods for business students, 5/e, Pearson Education India. SERVECENTER Types of Research Methods. Available: ter.pdf?p=6cc6799f8c1371f6c790a fe8b3fdbe6a7d64bce3b4886d72bd474 &Type=D. 9

10 SUFFIAN, M. D. M., FAHRURAZI, F. R. & IBRAHIM, S The Design and Execution of Performance Testing Strategy for Cloud-based System. International Journal of Software Engineering and Technology, 1. SULEIMAN, B., SAKR, S., VENUGOPAL, S. & SADIQ, W Trade-Off Analysis of Elasticity Approaches for Cloud-Based Business Applications. In: WANG, X. S., CRUZ, I., DELIS, A. & HUANG, G. (eds.) Web Information Systems Engineering - WISE Springer Berlin Heidelberg. VAQUERO, L. M., RODERO-MERINO, L. & BUYYA, R Dynamically scaling applications in the cloud. ACM SIGCOMM Computer Communication Review, 41,