Telechargé par hbkstudio1

WhitePaper TOSCA

Cloud computing has seen an immense rise in recent years, both in new technologies being released as in
subsequent use by industry. The use of resources spread across the globe in an on-demand scalable manner,
tied to pay-as-you-grow payment schemes, has made the Cloud very attractive. However in part due to this
rapid growth, limitations are showing in the majority of Cloud-enabling technologies. More specifically,
they lack the capability of providing a standardized view on similar resources served by different providers
or through different Cloud middleware solutions [2]. This results in an inability to migrate applications
across different platforms without investing high cost and time. As per [3], this is called the vendor lock-in
problem and in order to resolve it, each component of an application, their relationships and management
configurations must be encoded in a portable, standardized and a machine readable format.
To this end, TOSCA -- the Topology and Orchestration Specification for Cloud Applications
(Version 1.0) [1] was released. This standard offers a structured (XML based) language that defines
different components of an application and relations between them using an application topology while
capturing all management tasks in management plans. The main motivation behind this document is to
provide an informational overview of TOSCA to people who are new to the recent developments in the
field. As such, this document contains a description of a representative set of works in literature that made
contributions to TOSCA.
TOSCA objectives
TOSCA is an OASIS standard which was mainly designed to address the automation, portability and
interoperability aspects of complex cloud applications, i.e., applications composed of multiple services.
TOSCA provides automatic deployment, termination and a multitude of other management facilities [3]. It
binds all the different components of an application with their specified relations and provides an
informative, standardized, and portable structure to achieve its main goal of automatic management and
deployment of composite applications. The objectives of TOSCA can further be divided into different sub
goals [7] which are stated as follows:
1. Automated deployment and management of composite applications: Automated
deployment and management of complex applications possessing multiple (possibly distributed)
services, is a major concern as well as demand of the IT enterprise, because manual management
is a tedious and often a faulty process. In order to achieve the desired objectives, TOSCA aims at
capturing the knowledge of the application developer formally. More specifically, TOSCA captures
the information about the internals using a topology template and management plans, where the
topology template provides an abstract view of an application’s structure, while the management
plans help achieve automated deployment and management by defining different workflows.
2. Portability of application descriptions and their management: One of the major problems
with cloud applications today is that some of the existing technologies do not support the migration
of an application from one cloud provider to the other. This is mainly due to the fact that migration
of applications between heterogeneous environments requires rebuilding some of the management
functionalities. Sometimes it may even lead to re-implementation of some components of an
application [3, 7]. These problems that arise due to application migration, thus render it as a highly
cost ineffective process. According to [9,10,11], encoding of an application’s topology and its
management plans in a self-contained way is one of the steps facilitated by TOSCA to resolve the
issue of portability and deliver better results when compared to the existing solutions. Moreover,
TOSCA provides a generic way to describe the application topology of composite cloud
applications and leverages portable workflow languages to ensure portability of deployment and
management plans [5]. Note that, TOSCA facilitates provisioning of the portability of an
application and its management descriptions, and not the portability of the actual application itself.
3. Interoperability and reusability of application components: Interoperability is the ability
to establish effective communication between different components of an application, under some
well-defined set of rules (protocols). TOSCA provides interoperability by describing dependencies
between various components of an application [3]. Moreover as discussed above, TOSCA allows
packaging of an application in a self-contained way, thus further facilitating a standardized
approach to reuse these applications in other complex ones.
The TOSCA Service Template
As discussed above TOSCA aims to provide various management facilities in order to reduce the
complexity of composite applications. TOSCA provides an XML-based modelling language which encodes
an application as a “Service Template” [1, 4]. In other words, the Service Template should be interpreted
by a TOSCA-complaint environment, which in turn operates different cloud services and manages their
instances [5], as shown in Figure 1. It consists of a typed topology graph called the Topology Template and
their management tasks defined using different Management Plans. More specifically, the topology
template is a multi-component cloud service representation which captures the relations between different
nodes (here nodes are different components that constitute a service). On the other hand, management plans
provide scale up, scale down and other strategies for different application components. We will discuss this
in the following sections of this article. To summarize, the TOSCA Service Template broadly defines two
separate parts to denote the structure of a Cloud application:
a) Topology Template: A topology template can be understood as a congregation of different node
templates and relationship templates, all of which collectively define a cloud application (flow)
using a graph. Each node is represented by a node template whereas the relationship between two
nodes is represented by a relationship template. Each node template belongs to a node type and
similarly the relationships between different nodes can also belong to various relationship types.
Both node types and relationship types are reusable entities. In other words, the application
components and their relations are represented by means of typed “Node and Relationship
Templates” [7].
Figure 2 presents the Topology template involving some of the components of a sample cloud
application -- MakeMyHome (a more detailed Topology template shown in Figure 6), using the
node and relationship templates. This application provides the ability to search for commercial /
residential properties with the objective to fulfill the majority of the requirements of a customer.
By means of this example, readers of this article should get a clear idea about the difference between
Node Template, Relationship Template, Node Type, Relationship Type and other management
operations. Each application component / constituent is represented by a node template with its
corresponding node type in parenthesis. For example, “Apache Tomcat” that represents a node
template, is one of the components of this application with “Web-server” as its node type (Tomcat
is a specific type of web-server providing different functionalities). Similarly, the “Apache HTTP
server” could also be one of the node template with the node type as “Web-server”. Moving ahead,
“Ubuntu 12.04 LTS” represents a node template for the “Operating System” node type. Note that
Mac, Windows 2013 Server can also replace Ubuntu as node types for the operating system node
Figure 1: TOSCA Service Template defines the structure of a complex cloud Application [1].
Figure 2: Topology template of sample application, where nodes are components / constituents of an
application and edges represents the relationship between these components [10].
A node template specifies the occurrence of a node type as a component / constituent / building
block of an application [1]. Both node and relationship templates are typed and preserve some set
of type-specific properties (for example integer (int) and floating point (float) data-types for
different type of variables in C or in any other programming language) with the type templates
while retaining instance specific properties with the node template itself. The three conceptual
layers in figure 3, namely – (1) types (2) templates and (3) instances better define this behavior.
1) Type defines the reusability of component with its specific properties, which is further used
to construct the application topology by templates. Node type is the major building block
of a service and it maintains the definition of implementation artifacts and deployment
artifacts for different components. Artifacts represent the content needed to realize a
deployment and management operation of an application component [7]. Artifacts
represents any type of content for example executable programs, scripts, libraries etc.
2) Instance layer depends on the runtime of TOSCA and represents instances of the
component and relationship defined by templates [3].
Similar to the description of node templates and types, we now provide a description of relationship
templates and its types. All four components of our MakeMyHome application, in Figure 2, are
connected to each other with the relation “hosted on”, which specifies a relationship type. As an
example: the Ubuntu 12.04 LTS components of our application (of node type Operating System) is
hosted on an Amazon EC2 server (of node type Virtual Server), represented by the relationship
template “UbuntuOnEC2” which is of relationship type “hosted on”. Similarly, the Tomcat
webserver is hosted on the operating system together with the war file by which the application is
deployed, again represented by a relationship of type “hosted on”. Although, this example presents
relationships of a specific singular type, it is possible to define many other relationship types
between different components of an application, viz. installed on, depends on, deployed on etc.
Figure 3: Different levels of TOSCA concepts [3, 5].
b) Management Plans: Organizations that develop cloud applications, seek efficient management
processes for these applications. Typically, most of the organizations learn how to manage their
services on their own (e.g. how to efficiently operate these services, how to scale them up/down).
In specific cases, scripts are also designed for some of the frequently used components in order to
make their management easy and semi-automated. For example, a developer can create a bash
script (in Linux) for compiling a huge library, which in turn prevents having to rewrite a large
number of commands on a frequent basis. However, this may not be the most cost effective method,
since sometimes migration of an application from one cloud provider to the other, requires
rebuilding the application or even re-implementing some of the application components. This
quickly becomes a complex task for applications consisting of a large number of components. To
this end, TOSCA enables the developers to capture the frequently used management tasks as
management plans, which in turn significantly decrease subsequent manual effort and facilitate
automatic execution of applications and their deployment.
TOSCA provides the ability to manage all the components of an application and obtain different
models for best management practices. The main advantage of TOSCA management plans is that
it facilitates production of portable plans so that a cloud service can easily migrate between different
environments. This type of management practice significantly reduces management costs and
provides better results. These plans are defined in terms of a workflow, which further aggregates
the operations performed by various nodes in the application topology to provide a sequence of
steps. Management plans describe the management operations associated with various components
and relationships of an application. In addition, they also capture the sequence of operations
involving different nodes and/or relationships of an application [OASIS 2010]. Further, as
discussed above, the portability of workflow definition languages used to describe these
management plans, allows for portable management of applications as well.
Figure 4: Example of a Management Plan to deploy an Application in two steps [11]
Usually, plans belongs to two broad types, namely (1) Build Plans – that help create an instance
of a service template and (2) Termination Plans – that help destroy a service template instance.
Theses build and termination plans include various strategies for scaling, deployment and
termination of an application. Management plans also define a set of constraints that need to be
satisfied. These constraints can for instance define the required response time for a query by a
customer and the overall management budget for an application. Monitoring information required
to achieve these different constrains are specified in the plans, for example detection of response
time, resource utilization and throughput etc. Figure 4 presents a simple management plan to deploy
an application in two steps, namely – (1) Installing Apache Tomcat on an Ubuntu operating system
and (2) Deploying the application on the Tomcat server. TOSCA does not provide a new language
for executing these plans. However, it uses existing workflow languages such as the Business
Process Execution Language (BPML) and Business Process Model and Notation (BPMN,
recommended workflow language for TOSCA management plans) [1, 3]. Each task of a defined
plan, refers to a topology node (Figure 5). Each topology node (typed) may have interfaces,
properties, requirements exposed to the management plans. Interfaces are in turn bound to a
concrete implementation, for example implementation artifacts (scripts, executables etc.) and
deployment artifacts (installable, images etc.).
TOSCA Packaging
TOSCA provides a service template that represents the overall structure of a complex composite cloud
application and management plans to manage different components of an application. Different files are
maintained such as implementation artifacts, deployment artifacts, Plans, XML schemas, scripts etc., in
order to achieve the management functionalities of cloud applications. All these files need to be packaged
together with the service template into the TOSCA archive called the “Cloud Service Archive (CSAR)”
[OASIS 2012, 3]. CSAR provides a method to package an application in a self-contained way along with
all of its management functionality. The TOSCA runtime environment provides support for TOSCA
archives and is able to process (installing the application package) said archives. Figure 5 shows the
structure of TOSCA archive.
Figure 5: Packaging of all the files with service template into TOSCA archive called “CSAR” [11].
Example – TOSCA-enabled MakeMyHome application
To make the preceding sections more clear, we present an example of a TOSCA-based application, the
MakeMyHome application, with all its different components in Figure 6. The MakeMyHome application is
an online platform for customers, which provides the capability to search for residential/commercial
properties as per their requirements. This application mainly consists of two stacks, namely -- (1) Stack
S1 that describes the web-framework of the application and (2) Stack S2, which describes the different
properties stored in a MYSQL database. This database is accessible through a database connection made
by the PHP application.
The infrastructure layer of S1 consists of a “Virtual Machine” node type with node template “Amazon
EC2 Server”. Ubuntu operating system, represented by node type “Operating System” with node template
“Ubuntu 12.04 LTS” is hosted on this virtual machine (EC2 Server). A “webserver” node type with node
template “Apache HTTPD Server” is installed on this operating system. Moreover, a node template “PHP
Container” with node type “PHP Module” is installed on the Apache HTTPD Server. Node template
“MakeMyHomeApp” with node type “PHP Application” implements the GUI of MakeMyHome
application hosted on a PHP container.
Figure 6: Example of TOSCA based topology template for “MakeMyHome” Application
On the other side, the infrastructure layer of stack S2 describes the product data for our web-based
application. It consists of a “Virtual Server” node type with node template “Amazon EC2 Server”. On this
virtual server, a node type “Operating System” with node template “Ubuntu 12.04 LTS” is installed further.
Moving ahead, a node template “MYSQL” is installed (maintains information about all the
commercial/residential properties) on the Ubuntu 12.04 LTS operating system, which is represented by the
“MakeMyHomeDatabase” is deployed on this MYSQLDatabase. Finally, the “MakeMyHomeApp”
application directly interacts with the “MYSQLDatabase” using a “DBConnection” to store the data into
this database.
The corresponding build plan of “MakeMyHome” is shown in Figure 7. A build plan helps in creating an
instance of the service template and is responsible for deployment of both the software stacks (S1 and S2)
mentioned above. The recommended workflow language for TOSCA management plans is BPMN, which
supports parallel execution of tasks. This facilitates the deployment of both the software stacks in parallel.
We first describe the steps for the deployment of S1. The first activity in order to deploy the stack S1 is to
install the Ubuntu 12.04 operating system on the Amazon EC2 virtual server whose IP address is given by
the input message of the build plan. To execute the build plan, the operator needs to know the IP address
of the server and should hence mention it in the input message.
Figure 7: Build Plan for TOSCA based “MakeMyHome” Application
After installation of the operating system, the next step is to configure it by performing specific activities /
actions, such as configuring the firewall rules etc. The next step involves installation of the Apache HTTPD
Web Server on the Ubuntu OS, followed by the installation of the PHP Module on the Apache Web Server.
Finally, the PHP Application is deployed on the PHP Container. The second branch supports, in parallel,
the deployment of the second stack S2. We begin by acquiring an instance of the Ubuntu OS on the Amazon
EC2 Server. Next, MYSQLDB, which contains the data for products, is installed on the Ubuntu operating
system. The last step is to setup an endpoint for the PHP Application to seamlessly interact with the product
database. Once both stacks are deployed, the PHP application is done with the deployment and the front
end of this application is presented to the end-user.
In this article, we discussed about the OASIS standard, TOSCA -- Topology Orchestration Specification
for Cloud Applications. We described the three main objectives of TOSCA and studied the Service
Template provided by TOSCA. Next, an in-depth description of Service Template was provided, which
further explained the Topology template and Management plans. The detailed study of the Topology
template (with the description of Node Type, Node Template, Relationship Type, Relationship Template)
and Management plans, further helped us clearly demarcate their objectives. Towards the end, we described
TOSCA archives and studied the way in which different files are packaged into an application.
To summarize, TOSCA is a mature standard with the capability to resolve major problems addressed in
cloud (i.e Automatic deployment, portability etc.). The readers of this document are expected to gain basic
understanding of TOSCA and its different features. At the end of this article there is a further reading
section which should be helpful for users who want to know more about the TOSCA standard and its
contributions to the field of cloud computing.