SYBL: Simple Yet Beautiful Language From elasticity specification to multi-level elasticity control

rSBYL logo, SYBL

Elasticity Requirements Specification

SYBL is a language enabling elasticity requirements description for cloud services.

SYBL can be used by cloud providers, software providers, application developers or even end-users to describe their elasticity requirements concerning the application. The language allows for different levels of specification facilitating finer-grained elasticity specifications and enforcement depending on the actual needs of the users.

SYBL enables different levels at which users can specify elasticity requirements: application, component and programming. Application level allows for elasticity from the perspective of the whole application, while component-level and code-level elasticity requirements define user's elasticity needs for component, and respectively, sequnces of code.

Check the latest video illustrating runtime SYBL (rSYBL) with MELA!

SYBL Backus Naur Form (BNF)

Constraint := constraintName : CONSTRAINT ComplexCondition 
Monitoring := monitoringName : MONITORING varName=MetricFormula 
Strategy := strategyName : STRATEGY WHEN ComplexCondition : action(parameterList)|  
		strategyName : STRATEGY WAIT ComplexCondition| 
		strategyName : STRATEGY STOP| 
		strategyName : STRATEGY RESUME		 
MetricFormula := metric | number | metricFormula MathOperator metric | metricFormula MathOperator number ComplexCondition := Condition | ComplexCondition BitwiseOperator Condition| (ComplexCondition BitwiseOperator Condition) Condition := metric RelationOperator number| number RelationOperator metric | Violated(name)|Fulfilled(name) MathOperator := + | - | * | / BitwiseOperator := OR | AND | XOR | NOT RelationOperator := <|>|>=|<=|==|!=

Examples of using SYBL

Cost-related elasticity requirements

  • A cloud customer can specify that when the total cost is higher than 800 euro, there should be a scale-in action for keeping costs in acceptable limits.
    @SYBL_ApplicationContext(strategies="St1: STRATEGY CASE total_cost>800 Euro : ScaleIn")

Quality-related elasticity requirements

  • A software provider can specify constraints on the response time depending on the number of users currently accessing the provided software.
    	"Co1: CONSTRAINT rt<2ms WHEN nbUsers<1000;
    	Co2: CONSTRAINT rt<4ms WHEN nbUsers>=1000")
  • A developer could specify that the result from a data analytics algorithm must reach a certain data accuracy under a cost constraint without caring how many resources should be used for executing the code of that algorithm.
    	"Co1: CONSTRAINT dataAccuracy>90%; 
    	Co2:CONSTRAINT dataAccuracy>95% WHEN total_cost>400;
    	Co3:CONSTRAINT total_cost<800;"

Elasticity requirements on the relation between cost and quality

  • A cloud provider could specify its pricing schema or price computation policies, for example that when availability is higher than 99% the cost should increase by 10%.
    @SYBL_ApplicationContext(strategies="St1: STRATEGY CASE availability>99%: 

Multi-level Elasticity Control of Cloud Services

We consider the abstract model for cloud services described in the ICSOC Paper, and describe the cloud service following this structure using XML.

Cloud Service Model

Service Description

For each part of the application that needs to be controlled, we use can inject SYBL annotations within the XML, within the code or describe them as separate files through XML SYBL for describing the elasticity requirements. Cassandra DB directives state that the cpu usage should be less than 70% due to the fact that cassandra is cpu-driven, and the storage usage should be less than 50%. Cassandra Controller states that the cpu usage should be less than 85%, considering the fact that the controller is also a Cassandra seed and that it is also the one processing YCSB requests.

Cassandra DB DescriptionCassandra Controller Description



The SYBL Elasticity Control Runtime Engine (rSYBL) is presented in the following image.

SYBL Runtime System


The cloud service used for this experiment is the composed of two service topologies: a data service topology and a data processing topology. The data service topology is based on Cassandra No Sql Database, and contains in its turn a client sending requests, based on YCSB and a Cassandra topology which actually contains the Cassandra cluster.

Experimental Cloud Service

For evaluating how topology level scale compares to component level scale, we compare the configurations from the table below, each with different number of clusters, each cluster containing a single controller (Cassandra seed). Table 1 shows different configurations, justifying the need for actions at higher level than simple component level (in this case, at cluster level).

Config Controllers Nodes Time Cost
Config1 1 3 578.4s 0.48
Config2 1 6 472.1s 0.91
Config3 2 2 382.4s 0.42
Config4 3 4 372.2s 0.72
Table 1: Cassandra cluster comparison with different levels of scale

Table 2 gives some more examples on the behavior of the Data Serving Topology, showing how 2 clusters can decrease the cost as opposed to single cluster, and more importantly it can avoid errors due to overloading (i.e. for the more intensive and longer workload, workload 2, a single cluster, eventhough it has more than one virtual machines for the slave component, reaches a point where it cannot serve requests anymore).

Config Controllers Nodes Workload Time Cost
Config1 1 3 Workload 1 2648s (44 min) 2.92
Config3 2 2 Workload 1 1704s (28.4 min) 1.88
Config1 1 3 Workload 2 >3h + errors >12
Config3 2 2 Workload 2 6165s (102.75 min) 6.88
Table 2: Cassandra cluster comparison on different workloads

Multi-cloud Elasticity Control

The figure below shows an example of how using rSYBL one can control a service distributed among several clouds. It may be the case that sometimes, for improving performance or for decreasing costs, the service provider chooses to deploy only some service topologies on a cloud provider, while others are kept within other premises. For instance, in the figure below, some data access and analysis processes are deployed on the Dubai cloud, where also IoT data resides. The rest of the service, in order to have better performance, is deployed on the Flexiant cloud, and accesses only data analysis information, not the entire IoT data repository.

Multi-cloud Elasticity Control Example

For this case, following the configurations explained in detail on the rSYBL wiki, the rSYBL user (in this case the M2M DaaS provider) can obtain an application elastically controlled by rSYBL to follow SYBL requirements. Figure below shows a snapshot of MELA with the enforcement of a Flexiant action on the Event Processing Service Topology.

Example of Enforcing Control Action As presented in the rSYBL wiki, the SYBL requirements and high level structural information is exactly the same as the information used for single-cloud. What differs is the deployment information, received from the deployment tool (e.g., SALSA, OpenTOSCA), and the effects specification which specifies the provider on which the respective actions have the described effects.




Presentations given are available on slideshare:


If you need any further information please contact Georgiana Copil.