rSYBL

The SYBL language

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.

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

Elasticity requirements in cloud service descriptions

SYBL elasticity requirements can be injected in cloud service descriptions, be them TOSCA-based or custom. This is a simple process since SYBL requirements are close to day-to-day sentences and can be associated to different nodes existent in the description. Examples of such descriptions can be found in the git repository, tosca or xml

Elasticity requirements as Java annotations

For interpreting injected elasticity requirements, one needs to also deploy the Local module of the elasticity controller on each virtual machine/container where the unit is deployed. 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.

@SYBL_ComponentContext(constraints=
	"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.

@SYBL_ProgrammingContext(constraints=
	"Co1: CONSTRAINT dataAccuracy>90%; 
	Co2:CONSTRAINT dataAccuracy>95% WHEN total_cost>400;
	Co3:CONSTRAINT total_cost<800;"
priorities=
	"Priority(Co2)>Priority(Co1);
	Priority(Co3)>Priority(Co1);")

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%: 
				IncreaseCostBy(total_cost/10)")

The rSYBL elasticity controller

rSYBL API

Method Name	Type	Input type	Output type	Description
/{id}/prepareControl	PUT	application/xml	-	Sets the rSYBL controller in "prepare mode", for receiving all the necessary information for control.
/{id}/description/tosca	PUT	application/xml	-	Sends to rSYBL the TOSCA description of service with ID id
/{id}/description	PUT	application/xml	-	Sets rSYBL specific application structural description (e.g., here ) for service with ID id. When this is sent TOSCA description is not needed.
/{id}/deployment	PUT	application/xml	-	Sets current service deployment description for service with ID id (e.g., here).
/{id}/elasticityCapabilitiesEffects	PUT	application/json	-	Sets effects expected for primitive operations in JSON format (e.g., here) for service with ID id.
/{id}/compositionRules	PUT	application/xml	-	Sets composition rules for service metrics in MELA-specific XML format (e.g., here) for service with ID id.
/{id}/startControl	PUT	application/xml	-	Starts the control for the service with ID id.
/{id}/startControlOnExisting	PUT	application/xml	-	Starts the control on the service with ID id, which is already deployed and monitored.
/{id}/stopControl	PUT	application/xml	-	Stops the control (equivalent with a pause in control, for when the service is manually modified).
/{id}	DELETE	-	-	De-registers from rSYBL and MELA, and undeploys from the cloud the service with ID id.
/managedService/{id}	DELETE	-	-	De-registers from rSYBL and MELA service with ID id (does NOT undeploy) from the cloud.
/{id}/onDemandControl/unhealthy	PUT	plain/txt	-	Triggers health fix (recursive restart in top-down mode) for service with ID id, for service part sent as parameter (in the method body).
/{id}/startTEST	PUT	application/xml	-	Starts the rSYBL controller in testing mode
/{id}/{servicePartID} /testElasticityCapability/ {capabilityID}	PUT	application/xml	-	Enforces, for service with ID id, capability with capabilityID for service part with servicePartID.
/{id}/{servicePartID} /testElasticityCapability /{pluginID} /{capabilityID}	PUT	application/xml	-	Enforces, for service with ID id, capability with capabilityID for service part with servicePartID, by using a specific enforcement plugin of rSYBL, with ID pluginID.
/{id}/description	GET	-	application/xml	Gets current application structural description used, in rSYBL specific format (e.g., here )
/{id}/elasticityRequirements/xml	GET	-	application/xml	Returns elasticity requirements for the service with ID id, in XML format.
/{id}/elasticityRequirements/plain	GET	-	text/plain	Returns elasticity requirements for the service with ID id, in SYBL format.
/{id}/structuralData/json"	GET	-	application/json	Returns the service structural description in JSON format.
elasticservices	GET	-	text/plain	Returns the ids of all currently controlled services, separated by ','.
/{id}/deployment	POST	application/xml	-	Modifies current service deployment description for service with ID id (e.g., here).
/{id}/description	POST	application/xml	-	Modifies for service with ID id, the service description which is sent in the body of this call.
/{id}/compositionRules	POST	application/xml	-	Modifies composition rules for service with ID id (i.e., old ones are being replaced with the new ones sent in the message body).
/{id}/elasticityRequirements/xml	POST	application/xml	-	Modifies elasticity requirements for the service with ID id, with the ones received. The received requirements are for this method in XML format.
/{id}/elasticityCapabilitiesEffects	POST	application/json	-	Modifies elasticity capabilities effects for service with ID id, with the ones sent in JSON format.
/{id}/replaceRequirements/plain	POST	text/plain	-	Replaces elasticity requirements for service with ID id with the ones received in SYBL format.

Installing rSYBL

The instalation and customization process is described in prototype's wiki.

Please contact Georgiana Copil if you need help in using rSYBL.

Having trouble with rSYBL? Check out the documentation on the wiki or contact us via mail and we’ll help you sort it out.