Performance‐based service‐level agreement in cloud computing to optimise penalties and revenue

IET CommunicationsVolume 14, Issue 7 p. 1102-1112 Research ArticleFree Access Performance-based service-level agreement in cloud computing to optimise penalties and revenue Afzal Badshah, Department of Computer Science & Software Engineering, International Islamic University, Islamabad, PakistanSearch for more papers by this authorAnwar Ghani, orcid.org/0000-0001-7474-0405 Department of Computer Science & Software Engineering, International Islamic University, Islamabad, PakistanSearch for more papers by this authorShahaboddin Shamshirband, Corresponding Author shahaboddin.shamshirband@tdtu.edu.vn Department for Management of Science and Technology Development, Ton Duc Thang University, Ho Chi Minh City, Vietnam Faculty of Information Technology, Ton Duc Thang University, Ho Chi Minh City, VietnamSearch for more papers by this authorGiuseppe Aceto, Department of Electric Engineering and Information Technologies, University of Napoli Federico II, Naples, ItalySearch for more papers by this authorAntonio Pescapè, Department of Electric Engineering and Information Technologies, University of Napoli Federico II, Naples, ItalySearch for more papers by this author Afzal Badshah, Department of Computer Science & Software Engineering, International Islamic University, Islamabad, PakistanSearch for more papers by this authorAnwar Ghani, orcid.org/0000-0001-7474-0405 Department of Computer Science & Software Engineering, International Islamic University, Islamabad, PakistanSearch for more papers by this authorShahaboddin Shamshirband, Corresponding Author shahaboddin.shamshirband@tdtu.edu.vn Department for Management of Science and Technology Development, Ton Duc Thang University, Ho Chi Minh City, Vietnam Faculty of Information Technology, Ton Duc Thang University, Ho Chi Minh City, VietnamSearch for more papers by this authorGiuseppe Aceto, Department of Electric Engineering and Information Technologies, University of Napoli Federico II, Naples, ItalySearch for more papers by this authorAntonio Pescapè, Department of Electric Engineering and Information Technologies, University of Napoli Federico II, Naples, ItalySearch for more papers by this author First published: 01 April 2020 https://doi.org/10.1049/iet-com.2019.0855Citations: 5AboutSectionsPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onEmailFacebookTwitterLinked InRedditWechat Abstract Cost, performance, and penalties are the key factors to revenue generation and customer satisfaction. They have a complex correlation, that gets more complicated when missing a proper framework that unambiguously defines these factors. Service-level agreement (SLA) is the initial document discussing selected parameters as a precondition to business initialisation. The clear definition and application of the SLA is of paramount importance as for modern as a Service online businesses no direct communication between provider and consumer is expected. For the proper implementation of SLA, there should be a satisfactory approach for measuring and monitoring quality of service metrics. This study investigated these issues and proposed performance-based SLA (PerSLA) framework for cost, performance, penalties and revenue optimisation. PerSLA optimises these parameters and maximises both provider revenue and customers satisfaction. Simulation results confirm that the proposed framework is adequate in revenue generation and customers satisfaction. Customers and providers monitor the business with respect to agreed terms and conditions. On violation, the provider is penalised. This agreement increases the trust in relationship between provider and consumer. Nomenclature workload running time workload response time task initialisation time task finalisation time resources availability time resources down time total agreed time resources execution time request type resources type SS service scalability number of SLA violations penalties due Per resources performance QoS quality of Services Eff efficiency of services CS customer satisfaction total costs total costs for unit hired network costs security costs internal migration costs external migration costs avail resources availability prices prices for reserved services prices for demand based negotiated based pricing fail resources failure per performance margin constant first threshold second threshold third threshold penalty rate uploading bandwidth downloading bandwidth Prof total profit earned agreed QoS objectives 1 Introduction Cloud computing is a successful and widespread paradigm, effectively delivering desktop services over the internet like other common utilities as telephone, gas and electricity distribution [1]. Rather than investing capital amount on infrastructure, software, registrations and IT experts, customers pay cloud providers for the use of the services or for the leasing of resources [2]. The characteristics of the service that is paid for are agreed upon in the form of service-level agreements (SLAs), the legal contract negotiated and signed by consumer and provider party [3]. In the frame of an SLA, complete service-level objectives (SLOs) are discussed and desired quality of service (QoS) variables are defined and agreed upon as well [4]. Service provision is monitored with agreed terms and conditions: on SLA violation, the defaulter is penalised [5]. Given these practices, it is self-evident that clearly explained SLAs, with understandable ties to the customer's business interests, are the key to help providers offer the best service for customer's requirements and maximise customer satisfaction [6, 7]. Indeed, Business Intelligence tools and data-driven automation are the more and more becoming central to any commercial activity, and having a significant part of the ICT infrastructure outsourced to cloud providers makes harder to apply insight-driven automation in the management (and re-negotiation) of rented cloud services [8, 9]. Performance, penalties, cost and revenue are interrelated in a complex way, with both direct and inverse proportional effects [10, 11]. Actually, by assuming a temporary intuitive definition for such key parameters from the point of view of the cloud provider, we consider the performance (of the provided service), costs (paid for the service), penalties (paid by the provider for SLA violation), and revenues (earned from offering the service). These parameters show the following behaviour: a raise in performance maximises the revenue and minimise the penalties, although, performance is also directly proportional to the cost, which is inversely proportional to the revenue. The further complication is implied as there is no generally adopted framework clearly defining such parameters in relation to the SLA life cycle. Fig. 1 shows the life cycle of the proposed performance-based SLA( PerSLA). Fig. 1Open in figure viewerPowerPoint PerSLA in cloud computing Although SLA, performance, and penalties are widely investigated in the scientific literature, we could not find an analysis of SLAs aimed at joint optimisation of revenue for the provider and satisfaction for the customer. Authors in [12-17] investigated different types of SLAs but did not pursue our stated objective. From the point of view of maximising revenue generation for the cloud provider, SLA for optimal resources scheduling have been discussed [18] separately, also QoS management for cloud customer satisfaction has been explored [19, 20]. Recent advances in Information Technology and infrastructures fueled a massive transition from in-house ICT services to cloud computing. Furthermore, new data processing paradigms (e.g. Big Data) have opened new business models, creating new technological requirements, and increasing need for cloud services. Due to the massive customers' workloads and internet business, extensive automation is required. Therefore it is essential to have clear-cut SLA to avoid disastrous consequences in the customer business. This paper investigated an SLA framework aimed at optimising both customer satisfaction and provider revenues, considering performance and penalties. Moreover, a threshold-based approach is proposed to avoid SLA termination, that is a radical resolution strategy in cases of SLA violations and major business concern for the cloud computing industry [21]. In the proposed approach, SLA violation does not lead directly to termination, but on earlier small violations the service prices are decreased, constituting the initial incentive to the provider to adjust the performance. It can be hypothesised that an initial small decrease in performance is unlikely to result in the customer dropout and loss of trust. Moreover, the reduced QoS that has been actually delivered is automatically compensated for with the price reduction. The proposed mechanism, therefore allows for more flexibility in SLA management and prevents unnecessary SLA termination. The feasibility and efficacy of the proposed approach have been validated in simulation, using the CloudSim simulator to evaluate the modelled cloud system in various topological and temporal circumstances. Nomenclature section shows the symbols used in the formulation. Contributions of this article are as follows: • A comparative analysis of literature is performed according to multiple criteria pertaining to the SLA management approach. • The design of an SLA framework that can maximise performance (hence user satisfaction) and increase the revenue for the provider. • In the proposed framework, a layered structure of SLA penalties, to incentivise the cloud provider to offer the best performance while avoiding unnecessary SLA termination. • An experimental evaluation of the proposed framework within a simulated environment with multiple scenarios. • A determination of optimum values for monitored parameters to maximise provider revenues and customer satisfaction in the simulated scenarios. The rest of the paper is arranged as follows. Section 2 reviews the related work on revenue maximisation, pricing strategies and IaaS resources allocation in cloud computing. Section 3 explores the SLA, performance and its parameters, cost and pricing model, penalties model, and revenue maximisation. Section 4 explains the proposed algorithms for implementing the PerSLA. Section 5 explains and analyses the experimental setup and series calculation and analysis. A series of measurements are carried out to prove the efficacy of the proposed framework in a simulated environment. Finally, Section 6 concludes all work. 2 Related work Web SLA (WSLA) was proposed by Alexander and Heiko [12] to handle the initial internet business. It was for web service context to define and monitor web services. It had three main segments which were parties, service definition and service objection. It provided an effective way to monitor the services. WSLA was a helpful structure for cloud computing services, however, the challenges with WSLA were that it did not explain how to convert low-level parameters to high-level parameters. Second, it did not discuss the performance. Due to the spread of the internet, the online business also grew. Academia and market gave special attention to this business. Christpher et al. [13] introduced the automatic SLA (ASLA). ASLA used history, user requirements and features evaluation to automatically suit to SLA. This was proposed to link the difference between two different SLAs. ASLA overcame market cost. ASLA is a great work in terms of saving customers' time and cost but unfortunately, it does not guarantee performance. SLA studies were further investigated by Jennifer et al. [14], and they proposed the personalised SLA (PSLA). PSLA works as a broker, connecting the service providers and customers. It hired different types of services from different providers and supplied it further to customers according to their needs and SLAs. ASLA solved the major issue of provisioning different services from one floor but the primary concern with it is the integration of different services, having different performance and SLA. Hamsanandhini and Mohana [18] investigated the customers' satisfaction to maximise providers' revenue. The most affecting parameters are QoSs and price of services (PoSs). They probed the correlation of these parameters. QoS presents the required performance while PoS presents the association between predefined prices and the actual prices. They proposed a model to optimise the quality and prices of customers satisfaction. Focusing on dynamic changing customers' demands are very important for any SLA life. Advancing this idea, Wu et al. [22] worked on resources allocation. This proposal tried to handle dynamic customers' demands. The provider delivered the services by using its own application or hiring others. Software providers try to increase their profit and ensure QoS to broaden provider business. Resources allocation were further analysed by Kundu et al. [23]. They worked on resources allocation to dynamic demands to maximise the revenue. For the best economic VM selection, the used MaxGain and MaxLos functions. Optimal capacity was utilised by Toosi et al. [24] to maximise the provider revenue. They placed a check on admission control. Only those SLAs are accepted which gave better revenue. Hadji and Zeghlache [25] probed Insourcing and outsourcing in a federation to maximise the cloud providers' revenue. Tevi Yombame and Zbigniew [26] worked to minimise the usage of power by about 80% of all the data centres. Mei et al. [27] worked to maximise the customers' satisfaction for revenue maximisation by QoS and prices. Adil et al. [19] proposed a monitoring approach to expose SLA violations and enforces penalties. Macías et al. [28] proposed a framework which accepted the higher revenue SLAs to maximise the performance and lower the penalties. Market analyser and capacity planer was used by Hong and Baochun [29] to maximise the providers' revenue. Adil et al. [19] used dynamic pricing for dynamic requests customers. It attracted more customers to maximise revenue. Zhao et al. [30] worked on cost and run time minimisation to maximise the revenue of the provider. 3 System model Fig. 2 shows the structure of PerSLA. Three types of parties participated in this model. Provider provides the services, consumer rents the services, and monitoring party monitors the services according to agreed terms and conditions to ensure the QoS. In the proposed model, service definition explains the services which are to be provided. Parameters are defined by metrics. In our scenario, we discussed response time in seconds, execution time in seconds, availability of memory in MBs, availability of storage in GB and bandwidth in Mbps per seconds. Fig. 2Open in figure viewerPowerPoint PerSLA structure in cloud computing Matrices and variables are used to measure services. The obligation is actually a conditional structure which checks the provision of the services with the agreed terms and conditions. Here in this model, we proposed two threshold values to check the services. To determine the SLA violation, all services are monitored with respect to the agreed terms and conditions. Performance analyser examines the performance of the services. Penalties are enforced on the failing party in case of unsatisfactory services. 3.1 Service level agreement SLA violation is the main cause of penalties. Violations occur in case of QoS degradation. This may be due to overload or network delay [28]. Penalties are applied on provider to satisfy the customers. These penalties may be in terms of direct cash or price reducing. In this model, prices are reduced for downtime. Three penalty layer structure is used in this framework. Three threshold values are used to apply penalties on violation of SLA. It increases customer retention. Table 1 shows the threshold values used in this study. Symbols , , and represents the threshold. Table 1. Threshold values SLA parameter Thr () Thr () Thr () response time, s 2 5 10 execution time, s 3 7 15 availability, % 99 97 95 bandwidth, Mbps 9.9 9.8 9.5 3.1.1 Execution time Execution time shows the time used to complete the customer's demand. Execution time is an important parameter of SLA. This depends on the request type and also the resources on which the request is executed. If the resources are not appropriate, it takes longer than usual [31]. (1) (2) (3) 3.1.2 Response time Response time is the waiting time of customer request in the waiting queue. Response time depends on the underlying resources utilisation and network bandwidth. If the underlying resources are heavily utilised, it takes longer to execute new tasks [19]. (4) (5) (6) 3.1.3 Resources availability Availability defines the presence of the agreed resources when they are required. Availability discusses all these resources which are discussed in SLA [19]. avail∝ 1_ fail avail∝S avail∝χ we calculated the availability as (7) where shows the total computation time agreed in SLA, shows the total availability of computation time and shows the downtime during running. 3.1.4 Resources scalability Resource scalability is vital for QoS. If the resources are non-scalable, they will be over utilised leading to penalties and revenue degradation. Most of the performance parameters directly depend on the resources scalability [32, 33]. If the resources are not scaleable, execution and response time may increase. To address this issue, external resources may be hired from the third party to maximise the scalability of the resources. Resources scalability depends on the total capacity of the provide. SLA violation happen due to non-scalable resources. Below equation discuss the negative effects of non-scalable resources. (8) (9) (10) (11) (12) 3.1.5 Resources reliability Resources reliability is defined as that resources perform the predefined functionality for the agreed time under agreed terms and conditions. The resources are reliable if they are fault-tolerant and automatically recoverable. Reliability also discusses the fault tolerance, recoverability and resources constancy. Lower reliability minimises customer retention which leads to lower revenue [19]. In our case, reliability depends on the performance, and availability. We consider the system as reliable if its performance is good and available on demand. (13) (14) 3.2 The cost and prices model Pricing methods have a significant part in revenue generation. Different pricing methods are used in cloud markets. In the reservation pricing, customers reserved the resources for a particular time such as a month or year etc. Due to the reservation and massive use, customers get a heavy discount. However, they pay the prior registration fee. In on-demand pricing, customers pay for units they consumed. In this scheme, prices are comparatively high, however, customers are paid for SLA violations [24]. The primary cost is calculated as (15) This study uses joint prices for customers' satisfaction. Prices are fixed for high performance and reserved customers. On-demand prices are employed for dynamic customers, demanding high performance. In the case of underutilisation, negotiation-based prices are used. In the actual cloud background, it will increase the resources utilisation and customer satisfaction. Prices are calculated as (16) (17) (18) where Δ>ψ 3.3 Penalties Penalties greatly affect the cloud business. Usually, providers admit weighted workloads but later on, they fail to provide resources as per the agreement and in the result, they have to pay much of their revenue in penalties. To put a limit check on penalties, it must not exceed from 10% of the service charges [34]. If the rate of penalty increases from 10% of the services charges, SLA should be terminated. This will help to maintain business between provider and consumer. If penalties increases from 10 %, it will have a very bad impact on provider [19]. Penalties decrease prices or may have direct sanctions on provider party. It also decreases the reputation of the provider and in future, customers would not trust on such a provider [6] (see Table 2). Table 2. Penalties structure SLA parameter , % , % response time 5 10 SLA termination execution time 5 10 SLA termination availability 5 10 SLA termination bandwidth 5 10 SLA termination When the first threshold is violated, prices are decreased by and if second threshold is crossed prices are charged less, and if performance goes down from the third threshold, business is terminated. Penalties are calculated automatically. The claim may be registered for higher loss. The market implementer may change or extend it according to their scenario. 3.3.1 Execution time For execution time () three types of threshold values are declared. If the resources is below the no penalties are imposed on the provider. But, if the increases by and provider is penalised by and , respectively. SLA is terminated if increases by . (19) 3.3.2 Response time Response time has three threshold values. if the resources is below the no penalties are imposed on the provider. However, if the increases by and , provider is penalised by and , respectively. SLA is terminated if increases by . (20) 3.3.3 Availability Availability refers to the available time of resources with respect to the agreed time of the particular resource. It also discusses the storage and memory availability according to agreed SLA. (21) 3.3.4 Bandwidth Bandwidth is of two types, upload and download bandwidth. It has three threshold values. if the resources BW violation threshold is below the no penalties are imposed on the provider. But, if the BW increases by and , provider is penalised by and , respectively. SLA is terminated if BW violation increases by . (22) penalty calculation (23) total penalty (24) the final profit is calculated as (25) (26) If the resources are not properly scheduled on VMs, they lead to penalties. To overcome these issues, algorithms create the mapping between all free VMs and customers' request. Such VMs are selected which are best fit in terms of QoS and cost. 3.4 Monitoring Monitoring is the main component of SLA. Monitoring is important for the QoS and tenants trust. It uses the formulation as discussed earlier, agreed SLA parameters and the current status of the services. Cloud service providers (CSPs), as well as tenants, need reliable and efficient monitoring to ensure SLA on both sides. Reliable monitoring increases trust between CSP and tenants. 4 Proposed algorithms Two algorithms are proposed for PerSLA. The first algorithm properly implements the SLA and the second algorithm optimises the scheduling three stages for threshold are defined. On the first threshold violation, prices are reduced by 5%, on second threshold violation prices are reduced by 10% and on the third violation, SLA is terminated. The first threshold is optimised at such a point which will not much hurt the customers but notify the provider to adjust the performance of the resources. Fig. 3 uses the values and monitoring report statistics of the Nomenclature and Table 1 to apply penalties on failure party. Every parameter of SLA has a different threshold and penalties values. Penalties are imposed according to the nature of violations. Fig. 3Open in figure viewerPowerPoint PerSLA algorithm Fig. 4 is called by the threshold call of I and II. Fig. 4Open in figure viewerPowerPoint Scheduling algorithm for PerSLA It works for performance adjustment. If the system receives reports regarding performance degradation, this algorithm tries to adjust the performance by migrating the workload from over utilised to under utilised VMs. It maximises the performance and revenue. In the case of limited resources, Fig. 4 searches the global provider to scale the resources. 5 Performance evaluation This section explained the experimental setup to assess the performance and working of this model. It is very costly and complicated to create cloud labs. To overcome this issue, different simulations tools are used to simulate the cloud environment. CloudSim, Cloud Analyst, Green Cloud and ICanCloud are the leading cloud simulation tools. To measure the performance of the proposed PerSLA model and algorithms, CloudSim simulator is used. 5.1 Experimental setup CloudSim is widely used simulator for cloud architectures simulation. It used java as a command line. It helps to virtually build servers, data centers and virtual machines etc. Workloads deployment and various scheduling algorithm can be easily executed. CloudSim uses cloudlet as user workload. Different algorithms can be implemented to schedule different customers workload on different resources. Fig. 5 shows the experimental structure of the PerSLA. Fig. 5Open in figure viewerPowerPoint PerSLA experimental setup The CloudSim simulator has been extended to assess the performance of the PerSLA. We added new classes, PerSLA, penalties and prices to calculate and adjust the performance and prices. Penalties are automatically calculated according to the PerSLA class inputs. Prices are also adjusted according to the PerSLA and penalties classes input. In the proposed scenario, 1700 VMs are created as resources and 2000 cloudlet as customers workload [34, 35]. Simulation is executed for the number of time, changing VMs from 50 to 1700 and cloudlets from 50 to 1700 [35]. During the simulation, various factors like the running time, waiting time, SLA violation, revenue generation and penalties of both servers were observed. 5.2 Evaluation result In this portion, numbers of tests are presented which were carried out in order to understand how the proposed study contribute to the core parameters optimisation. Numbers of VMs and cloudlet are created and run during experimentation. It is assumed that the capacity of the provider resources is scalable. Experimental results are calculated by changing data centers from 1 to 5, cloudlets from 50 to 1700 and VMs from 50 to 1700. The size every cloudlet is 300,000 MB, every VM's RAM is 3 GB and processor is 3.2 GHz. Experiments were conducted in three different rounds. In the first turn, the dynamic number of cloudlets and VMs were run on a single data center as shown in Table 3. We changed the cloudlets and VMs from 50 to 400 and run it on a single data center. In the second round, data center were changed according to the requirement of Cloudlets, keeping VMs constant on 500. Table 4 shows the second round results. In the third round, we used the PerSLA algorithms to adjust the resources according to the performance violation. Table 5 shows the third experiment results. Table 3. Penalties ($) and revenue ($) calculation by runningdynamic workload(cloudlet) on single data center Simulation no Data centers Number of cloudlet Number of VMs Execution time Waiting time Penalties Revenue 1 1 50 50 3 10 0 0 0 0 35 2 1 100 100 8 18 0 0 0 0 70 3 1 200 200 16 26 6 0 0 7 132 4 1 300 300 23 33 0 14 0 20 188 5 1 400 400 32 42 0 0 22 277 0 Table 4. Penalties ($) and revenue ($) calculation by runningdynamic workloads(cloudlet) on constant VMs Simulation no Data centers Number of cloudlet Number of VMs Execution time Waiting time Penalties Revenue 6 5 500 500 8 10 0 0 0 0 347 7 5 600 500 9 19 0 0 0 0 417 8 5 700 500 11 21 0 0 0 0 386 9 5 900 500 14 24 4 0 0 31 594 10 5 1100 500 17 27 0 7 0 76 688 11 5 1300 500 19 29 0 10 0 90 812 12 5 1500 500 23 33 0 13 0 104 937 13 5 1700 500 27 37 0 0 17 1180 0 Table 5. Penalties ($) and revenue ($) calculation by runningworkloads (cloudlet) on VMs using PerSLA algorithm Simulation no Data centers Number of cloudlet Number of VMs Execution time Waiting time Penalties Revenue 14 2 100 100 3 10 0 0 0 0 70 15 2 200 200 8 18 0 0 0 0 139 16 2 300 300 13 23 0 0 0 0 208 17 2 400 400 14 24 6 0 0 7 278 18 3 500 500 12 22 0 0 0 0 347 19 3 600 600 16 26 6 0 0 20 417 20 5 700 700 11 21 0 0 0 0 486 21 5 800 800 12 22 0 0 0 0 555 Fig. 6 shows the execution time by running equal numbers of VMs and cloudlet on a single data center. The result shows that as the cloudlet reaches 200, first threshold violation happens. second threshold violation occurs on 300 cloudlets and on increasing the workload up to 500 terminate the SLA. Fig. 6Open in figure viewerPowerPoint Execution time (s) by running workloads (cloudlets) on constant data centers Fig. 7 shows the execution time by running dynamic cloudlets from 500 to 1700 keeping VMs constant on 500. Data centers were increased as the increase in workload. Fig. 7 shows that violation starts as the workload increases from 900 cloudlets. From 100 to 1500 cloudlets, the system remains in second threshold violation. SLA is terminated as it reaches to 1700 cloudlets (see Fig. 8). Fig. 7Open in figure viewerPowerPoint Execution time (s) by running workloads (cloudlet) on constant VMs Fig. 8Open in figure viewerP