We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSpecification.Cloud.PaaS - FIWARE Forge Wiki


From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Cloud.PaaS
Chapter Cloud,
Catalogue-Link to Implementation Pegasus
Owner Telefónica I+D, Henar Muñoz Frutos, Fernando López Aguilar



Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.


Copyright © 2012-2015 by Telefónica I+D. All Rights Reserved.

Legal notice

Please check the following FIWARE Open Specification Legal Notice (implicit patents license) to understand the rights to use these specifications.


The main functionality that the PaaS Manager provides is:

  • Management of Application Environments, which involves the provisioning and configuration of IaaS resources (eventually including NaaS features), and installation, configuration and management of the Products Instances (PIs) required for the application components to be deployed.
  • Management of Application Components (ACs) (lifecycle and configuration) with the help of SDC GE for the installation and configuration of ACs.

The PaaS Manager executes orchestration logic that is specified in the Environment element specified as part of the PaaS Open RESTful API Specification. Environment information can be previously registered in the Environment Catalogue or it can be provided by the user.

The PaaS Manager GE interacts with the IaaS DCRM GE for the deployment of the hardware infrastructure (virtual machines or servers and networks) and with the SDC GE for the installation and configuration of the software.

The figure below shows the architecture of the PaaS Manager. There are three layers and a persistence mechanism: the implementation of the PaaS interface, the set of managers in charge of executing the tasks, and the clients to interact with other GEs (DCRM GE and SDC GE). By using these GEs, the PaaS Manager GE orchestrates the creation of different VDCs for different customers, and the provisioning of VMs or servers and deployment of the corresponding software products over which the applications can be deployed.

PaaS Manager Enabler Architecture Overview

PaaS Manager architecture specification

Target Usage

The PaaS Manager GE provides a new layer over the IaaS GE in the aim of easing the task of deploying applications on a Cloud infrastructure. Therefore, it orchestrates the provisioning of the required virtual resources at IaaS level, and then, the installation and configuration of the whole software stack of the application, taking into account the underlying virtual infrastructure. It provides a flexible mechanism to perform the deployment, enabling multiple deployment architectures: everything in a single VM or server, several VMs or servers, or elastic architectures based on load balancers and different software tiers.

Basic Concepts

Following the above FMC diagram of the PaaS Manager, in this section we introduce the main concepts related to this GE through the definition of their interfaces and components and finally an example of their use.

The PaaS Manager manages the lifecycle of applications and platforms software where they are deployed on top of VMs. There is a distinction between specification of resources and the actually deployed resources. For most of the resources, there is a software component that implements its lifecycle management.


The following figure depicts the main entities managed by the PaaS Manager:

  • Software Product Release & Product Instance (PI). They represent an installable software (usually middleware) that is installed previous to the deployment of the application components, e.g., Apache Tomcat, MongoDB, MySQL, etc. The software product release contains the information about the software to be installed, while the product instance refers to the product release already instantiated.
  • Tier & Tier Instance. An application is structured into tiers, each one comprising a set of VMs that share the same virtual image and where the same set of software products is installed. Nodes in a tier are clonable, typically in order to handle elasticity. A tier instance is the result of instantiating a given Tier definition (Tier template). Example of a tier is the one associated to the farm of web servers serving static web pages in the given portal associated to a CRM application
  • Environment & Environment Instance, which represent the complete software stack, including all the tiers, required for the deployment of an application. As an example, an on-line shop application maybe structured into three tiers, the first tier associated to the farm of web servers, a second tier associated to application servers running business logic and a third layer hosting a NoSQL data management layer. Nodes in the first tier would typically host Apache Web Server software. Nodes in the second tier may host some given Java application server (e.g., JBoss) while the third tier may comprise nodes hosting shard daemons of MongoDB.
  • Application Release & Application Instance, represent an application specification with all the artefacts and configuration attributes, and its deployment over an Environment Instance. E.g.: Mediawiki.

There are two components in the architecture of the PaaS Manager where these entities are handled:

  • Resources Catalogue, which contains all the specifications of resources that can be managed by PaaS Manager, including environment, product release information to be deployed. This catalogue can be populated by using an API.
  • Resources Inventory, which represents the actual instantiation of resources for a specific deployment. For each element in the inventory (called *-Instance), there is an equivalent in the catalogue.

It is important to highlight that the ApplicationType's and EnvironmentType's are catalogued in order to provide typical deployment environments for applications (Java-Web, Java-Python, etc.). ProductType's and ArtifactType's are also catalogued in order to provide common management mechanisms (deployment, configuration, etc.). Thus, besides having a good catalogue for typical environments, the GE can efficiently manage new application patterns that haven’t been catalogued. That way, the PaaS Manager GE is flexible to manage new contexts.

PaaS Manager Model
PaaS Manager class diagram


The PaaS Manager Interfaces are:


The PaaS Manager GE includes three main blocks of components, a data repository, which keeps the definition of the environments and products persistent and the inventory of deployed environments and applications.

  • PaaS Communication Service (PMI) is responsible of offering a RESTful interface to the PaaS Manager GE users and to handle the asynchronicity of the calls through a set of asynchronous tasks. It triggers the appropriate manager to handle the request. PMI manages synchronous calls by providing a task id which can be checked to obtain its status.
  • Core PaaS Managers. A number of specialized manager components are responsible of managing the different entities.
    • ApplicationInstanceManager, is responsible for the installation of application components on an existing environment.
    • ApplicationReleaseManager, is responsible for managing the specifications of applications in the PaaS Manager GE.
    • ArtifactManager, is responsible of managing application components and to find the appropriate product to be installed in and configured in an environment.
    • EnvironmentInstanceManager, is responsible of deploying and managing environment instances.
    • EnvironmentManager, is in charge of the management of environment specifications.
    • ProductInstanceManager, is in charge of managing the installation and configuration of a product instance on a VM or server through the SWInstallationManager
    • ProductReleaseManager, in in charge of managing the catalogue of available products that can be used to define environments.
    • TemplateManager, responsible for creating templates from existing tier instances to be replicated during elasticity.
    • TierInstanceManager, which orchestrates the installation of all the products that are required in a VM or server to install the application components.
  • InfrastructureManager (Controller), manages the creation and lifecycle of required IaaS resources.
  • SWInstallationManager, provides the mechanisms to coordinate with the SDC GE the installation of products and artifacts on VMs or servers, and to configure them.

Example Scenario

The PaaS Manager GE is involved in three different phases:

  • Management of the catalogue of products and environments and the lifecycle of the environments.
  • Deployment of applications.
  • Management of applications at runtime.

Environment Management

The management of environments involves several operations that have to do the configuration and provisioning of the resources required for the deployment of applications.

First of all, the environments have to be defined. The definition of an environment includes the specification of the products that will be supported. This functionality is related to the capacities of the SDC GE, that is, the list of products that can be actually installed, configured and used. Therefore, the definition of environments involves the specification of products and their supported releases as well as the specification of tiers.

Secondly, in order to enable the deployment of applications, an environment has to be deployed. This can be performed on demand, just previous to the deployment of an application, or in advance, in order to enable faster deployments.

Finally, the environments and environment instances can be retired, redefined or evolved.

Application Deployment

Applications are specified together with the specification of the environment that has to be used for actual deployment. An application is described by the different artifacts that compose it, and the products and configuration attributes required for managing the deployment and configuration. The PaaS Manager checks if the application specification is compatible with the environment specification, essentially by checking the compatibility between the product requirements associated to the application and the environment specification. If they are compatible, the PaaS Manager GE coordinates the actual deployment and configuration of artifacts in the environment with the SDC GE. Once an application is deployed, a VM or server image is created for scaling the nodes at each tier.

Runtime Management

During the runtime of an application, the IaaS DCRM GE can detect the need to scale up the resources allocated to a given application. If the deployment architecture is scalable, the PaaS Manager GE determines whether a tier node has to be cloned and sends the proper request for instantiating the corresponding virtual image to the IaaS DCRM GE. This mechanism, based on the VM or server image created for each tier node during deployment, allows for a fast scale up, since the whole software installation and configuration process is omitted.

Main Interactions

The following picture depicts some interactions between the PaaS Manager, the Cloud Portal as main user, the DCRM and the SDC, in a typical scenario.

PaaS Manager Interactions
PaaS Manager sequence diagram

The interactions are:

  1. The Cloud Portal gets information about all the possible environments that can be deployed.
  2. The Cloud Portal gets detailed information about a specific environment (tiers, products, etc.).
  3. The Cloud Portal requests the creation of a new environment to be used for instantiation lately, providing all the details. The user can customize existing environments and create a new one based on them.
  4. The Cloud Portal can get information about the already deployed environments instances.
  5. The Cloud Portal can get the detailed information about a given environment instance.
  6. If there are no appropriate ready to deploy environment instances, the Cloud Portal requests to deploy an environment in the testbed, which is an environment instance. This request can take some time since the instantiation of an environment involves the deployment of virtual machines and the installation of the software on top of it. For avoid blocking the PaaS Manager component, the request is asynchronous. Thus, the Cloud Portal will be checking the status of the instantiation task.
  7. The PaaS Manager GE requests the IaaS DCRM GE to create a new service as well as to provision the different servers involved in the service.
  8. The PaaS Manager GE requests the IaaS DCRM to start up of all servers by asking for start service.
  9. The PaaS Manager GE requests the SDC GE to install the appropriate products for the environment in the different provisioned servers.
  10. It is possible for the Cloud Portal to get the complete list of applications installed in a given environment instance.
  11. The Cloud Portal may obtain and show the details of an application deployed on an environment. This might be useful to decide if another application can be deployed on the same environment instance.
  12. The Cloud Portal may request the installation of an application on a given environment instance.
  13. The PaaS Manager GE requests the SDC GE to deploy the artifacts of an application on an environment instance. This operation is usually requested several times.
  14. The PaaS Manager GE requests the IaaS DCRM GE to create a server or VM or server image upon an installed and configured tier instance (node) for future elasticity.
  15. The IaaS DCRM GE takes the decision to scale up based on monitoring information.
  16. The IaaS DCRM GE requests to scale a tier.
  17. The PaaS Manager GE clones the tier instance node by requesting a new server to the IaaS DCRM GE.
  18. The PaaS Manager GE starts up the new server.

Basic Design Principles

Design Principles

The PaaS Manager GE has to support the following technical requirements:

  • Decoupling the management of the catalogue (specifications of what can be deployed) and the management of the inventory (instances of what has been already deployed).
  • Asynchronous interface with polling mechanism to obtain information about the deployment status.
  • Decoupling the management of environments from the management of applications, since there could be uses cases where the users of those functionalities could be different ones.
  • Fast elasticity mechanisms, avoiding overhead or repeated work as much as possible during elasticity.

Resolution of Technical Issues

When applied to PaaS Manager, the general design principles outlined at Cloud Hosting Architecture can be translated into the following design approaches:

  • REST based automated self-provisioning interfaces, both for environments and applications.
  • The PaaS Manager GE relies on the DCRM for virtual machine provisioning, and therefore, the multitenancy is offered at the level of IaaS, and not PaaS. Nevertheless, the environments are created per customer on demand.
  • The PaaS Manager GE has been designed for elasticity and supports fast elasticity on demand, as requested by the IaaS DCRM GE.
  • The PaaS Manager GE inventory keeps control of all the resources provisioned for each user.

Detailed Specifications

Following is a list of Open Specifications linked to this Generic Enabler. Specifications labeled as "PRELIMINARY" are considered stable but subject to minor changes derived from lessons learned during last interactions of the development of a first reference implementation planned for the current Major Release of FIWARE. Specifications labeled as "DRAFT" are planned for future Major Releases of FIWARE but they are provided for the sake of future users.

Open API Specifications

Re-utilised Technologies/Specifications

The PaaS Manager GE is based on RESTful Design Principles. The technologies and specifications used in this GE are:

  • RESTful web services
  • HTTP/1.1 (RFC2616)
  • JSON and XML data serialization formats.

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be helpful to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FIWARE level, please refer to FIWARE Global Terms and Definitions

  • Infrastructure as a Service (IaaS) -- a model of delivering general-purpose virtual machines (VMs) and associated resources (CPU, memory, disk space, network connectivity) on-demand, typically via a self-service interface and following a pay-per-use pricing model. The virtual machines can be directly accessed and used by the IaaS consumer (e.g., an application developer, an IT provider or a service provider), to easily deploy and manage arbitrary software stacks.
  • Platform as a Service (PaaS) -- an application delivery model in which the clients, typically application developers, follow a specific programming model to develop their applications and or application components and then deploy them in hosted runtime environments. This model enables fast development and deployment of new applications and components.
  • Project is a container of virtual infrastructure that has a set of virtual resources (e.g., computing capacities, storage capacities) to support the former. In other words, a VDC is a pool of virtual resources that supports the virtual infrastructure it contains.
  • Service Elasticity is the capability of the hosting infrastructure to scale a service up and down on demand. There are two types of elasticity -- vertical (typically of a single VM), implying the ability to add or remove resources to a running VM instance, and horizontal (typically of a clustered multi-VM service), implying the ability to add or remove instances to/from an application cluster, on-demand. Elasticity can be triggered manually by the user, or via an Auto-Scaling framework, providing the capability to define and enforce automated elasticity policies based on application-specific KPIs.
  • Service Level Agreement (SLA) is a legally binding contract between a service provider and a service consumer specifying terms and conditions of service provisioning and consumption. Specific SLA clauses, called Service Level Objectives (SLOs), define non-functional aspects of service provisioning such as performance, resiliency, high availability, security, maintenance, etc. SLA also specifies the agreed upon means for verifying SLA compliance, customer compensation plan that should be put in effect in case of SLA incompliance, and temporal framework that defines validity of the contract.
Personal tools
Create a book