Who should read this?
This blog entry is intended for any person who has to develop components to be deployed in PaaS 4 SLA. This entry provides some basic ideas behind PaaS for SLA relevant for software development purposes and pointers to other documentation and resources that extend it.
PaaS for SLA intro
PaaS for SLA, based on ECloud, is a Platform as a Service, PaaS, designed to manage the life cycle events of services deployed on it.
Those services are meant to be elastic. This means that this PaaS scales up and down them at runtime in order to ensure the Quality of Service (QoS) established in the Service Level Agreement (SLA) (e.g. in terms of performance, availability, security, etc.) in front of varying conditions.
Moreover, PaaS for SLA makes transparent to the service provider -and its code the management of the resources needed to guarantee this QoS.
ECloud service model
The ECloud service model is the specification that a software application has to follow (design, implementation, deployment) in order to run it in ECloud as a service.
The current version of the ECloud service model specification -[available in the C2NET portal]- details that:
- a service is a deployed and running instance of a service application
- which is composed by several components
- that interact among themselves through channels
Information about channel types (and when to use them), how to prepare components, build a service application and prepare a service is available in the ECloud service model specification.
As you will see: a) part of preparing components, b) defining a service application c) and deploying it requires to define Manifest files. Those configuration files are used by the PaaS for SLA platform in order to know how to handle them.
Before going on with the ECloud service model specification we recommend to start with the Quick Start Guide.
Preparing components for PaaS for SLA
As software developer in C2NET project probably you will have to prepare (and may be also implement) components to be part of the C2NET service application (cloud side). Thus, you will have to:
-
Prepare your software as a component. This implies several things: to select the base runtime image 1 2, to define its component Manifest, to implement the Component class (used by the PaaS for handling the component) making use of the declared channels...
-
Test your component. Check that it is properly deployed in the cloud and that interacts as expected through channels with the components it has to.
1: Nodejs: eslap://c2netproject.eu/runtime/nodejs/1_0_0
2: Java: eslap://c2netproject.eu/runtime/java/1_0_0
Tools and Testing Integration Framework
In order to help and support you several tools have been provided. All them are available in the PaaS for SLA SDK git repository under tools and testing folder. The current list of tools is:
- Log-viewer: tool that allows to process logs generated by the Testing Integration Framework
- Local-Stamp: tool for testing services and components locally. To be released in the short term.
- Manifest-validator: tool which checks syntactically Manifest.json files.
- Runtime-tools: tool that allows to manage _ECloud runtimes locally.
Moreover, a Testing Integration Framework has been prepared for helping you to test your components. The Quick Start Guide explains how to use it.
Guidelines and Examples
The following guidelines have been provided:
- Quick Start Guide: introduces the service application structure, explains how to generate one and how to test it.
- How to generate a custom runtime: explains how to generate a custom runtime for your component when the C2NET base runtime does not provide all your needs.
Several examples have been generated in order to show how to prepare components. Currently available examples are:
- Clock Java example: shows how to prepare a Java based component.
- Clock nodejs example: shows an example of a nodejs component.
- EchoTest example: shows an example of a nodejs component.
Moreover, you can also gain knowledge about how to prepare components looking at some C2NET cloud components already developed.
- nodejs: DS.sql component is an example of a nodejs component.
- TCP proxy: DS.sql component gives you the client side view while MariaDBWrapper component gives you the server side.
Support
If you have any problem or doubt when trying to prepare or test your component for PaaS for SLA please create a ticket in PaaS for SLA ticketing system.