This blog post gives a short overview of what elasticity requirements are, how they can be expressed using the SYBL language [Copil, 2013a], and gives a short overview on who can enforce them and in what manner.
We can say that in real life everyone has requirements. Whether we are talking about requirements with regards to products bought at a supermarket, to a clothing item, or to expectations on the new show we are going to see. So it is only natural that cloud customers would have certain expectations on how the application will behave in a cloud infrastructure, and on the amount of money they are going to pay for this. Giving that the application behavior needs to be adaptive with regard to multiple properties like cost, resources or quality, we see these automatic adaptions on multiple dimensions as elasticity [Dustdar, 2011].
Let’s take different stakeholders who are interested in elasticity requirements. The application owner (e.g., a service provider), who can also have the role of software provider, is usually interested in the behavior of the application from a high-level point of view. For example, s/he will usually not know, or only guess the low-level resource requirements for the application in different workloads and with different number of users (i.e., “I want a memory size of 6 GB for my application”). Most likely the application stakeholder would have requirements on quality, on performance, on the freshness of data used by his/her application, on data accuracy and certainly on costs. The figure above shows the multiple dimensions of elasticity, from a higher level to low level view. For instance, quality elasticity can be decomposed into computational quality elasticity and data quality elasticity, while data quality can further be decomposed into data accuracy, freshness, or completeness.
For specifying the elasticity requirements, we have defined SYBL [Copil, 2013a]. SYBL is a directive-based language, which uses the multi-dimensional view of elasticity [Dustdar, 2011] and four levels of requirements for addressing the needs of different types of stakeholders that may use the language.
The requirements can be tied to the different parts of the application, according to our representation model described in [Copil, 2013b]. The four requirement levels are: application, complex component, component and code region. These levels facilitate different types of stakeholders to specify elasticity requirements. In the case of the cloud provider, s/he does not possess any knowledge on the application structure, so s/he will not be able to have elasticity requirements for parts of applications, just for the application as a whole. On the other hand, the application owner can have elasticity requirements specific to each component while the application developer can have elasticity requirements for a code sequence.
We can define elasticity SYBL elasticity requirements as directives or policies which are part of various languages:
An example of an application for which we have elasticity requirements at multiple levels is shown in the image below. We have, for instance, the requirement over the Event Processing Service Topology for the case when constraint Co3 is fulfilled, thus having response time less than 350 ms, and the throughput is quite small, meaning that we don’t have too many clients, and we need to enforce a scale-in action.
For enforcing these elasticity requirements we have implemented SYBL Runtime (rSYBL) prototype, which manages the fulfillment SYBL elasticity requirements (more details in [Copil, 2013b]) and is the CELAR’s Decision Module. rSYBL takes as input the description of the application and of the available infrastructure providers, and provides runtime elasticity control. rSYBL is highly configurable, and can work with different monitoring solutions (e.g., Ganglia, MELA), and different enforcement platforms (e.g., CELAR Orchestrator, Flexiant FCO User API, OpenStack). So, go ahead, download rSYBL, and start controlling your application: https://github.com/tuwiendsg/rSYBL.
For more details on how to use it, you can consult published papers [Copil, 2013a] [Copil, 2013b] or just watch the demo on how SYBL and MELA work together, presented in ICSOC in 2013
[SYBL+MELA, 2013]:
Research Assistant
Distributed Systems Group
Information Systems Institute
Vienna University of Technology
A-1040 Wien, Argentinierstrasse 8/184-1
Tel +43-1-58801-184830
URL: http://www.infosys.tuwien.ac.at/staff/ecopil/
[Copil, 2013a] G. Copil, D. Moldovan, H.-L. Truong, and S. Dustdar. “SYBL: an Extensible Language for Controlling Elasticity in Cloud Applications”. 13th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing – CCGRID2013, Delft, the Netherlands, May 14-16, 2013.
[Copil, 2013b] G. Copil, D. Moldovan, H.-L. Truong, S. Dustdar, “SYBL+MELA: Specifying, Monitoring, and Controlling Elasticity of Cloud Services”, the 11th International Conference on Service Oriented Computing. Berlin, Germany, on 2-5 December, 2013.
[Dustdar, 2011] S. Dustdar, Y. Guo, B. Satzger, H.-L. Truong. „Principles of Elastic Processes”. IEEE Internet Computing 15(5): 66-71 (2011)
[SYBL+MELA, 2013] G. Copil, D. Moldovan, H.-L. Truong, S. Dustdar: SYBL+MELA: Specifying, Monitoring, and Controlling Elasticity of Cloud Services. the 11th International Conference on Service Oriented Computing. vol. 8274, pp. 429–436. Berlin, Germany, on 2-5 December, Springer, Heidelberg (2013)
