The promises of cloud computing are well known: significant cost and agility benefits plus a scalable environment. So far, so good. In practice, however, standardized descriptions of the topology of applications, their interactions, and their dependencies with environment variables are still lacking. This obstacle rears its head when using an application in multiple clouds or when migrating between them; this is where ARIA TOSCA comes in.

TOSCA (Topology and Orchestration Specification for Cloud Applications) inevitably evokes associations with Puccini's opera of the same name, in which the celebrated opera diva Floria Tosca tragically plunges to her death from the parapet of Castel Sant'Angelo. In this case, TOSCA does not stand for a tragic end; instead, TOSCA is intended to eliminate incompatibilities between cloud solutions and increase interoperability.

Interoperability Ensured

When a company wants to change cloud providers, unexpected problems arise in the final stages. The OASIS project has addressed this problem by developing the TOSCA specification, which defines a meta model to describe cloud services. Put simply, TOSCA provides a framework in which cloud applications with all their aspects are written to a template that can theoretically be exchanged between providers. A template includes service definitions, structures, and other information. The declared goal of TOSCA is to prevent a dependency on individual cloud computing providers.

Thanks to its independence and interoperability, TOSCA offers a high degree of flexibility, paving the way for standardized cloud solutions. The standardized description of components, their relationships and dependencies, and their requirements and capabilities not only enable portability, but also enable automatic management between cloud computing providers, regardless of the underlying platform or architecture. As a positive side effect, the agility and accuracy of cloud services have reached a new level.

For customers, TOSCA increases the comparability and choice of cloud offerings while reducing costs. Cloud service developers also benefit, because they can develop for different platforms and choose the appropriate provider, regardless of incompatibilities. However, providers also benefit from standardization because adoption is simplified, and they can expand their own range of services and drive forward their own developments.

TOSCA comprises two parts: the topology, which describes the components and the relationships between the applications, and orchestration, especially the modeling management of the application.

ARIA TOSCA

To benefit from TOSCA, you need an environment in which the templates and service descriptions can be developed, tested, validated, and executed. This is where the Apache Incubator project ARIA TOSCA [1] comes in. It is a library and console tool for network function virtualization (NFV) and hybrid cloud orchestration. ARIA TOSCA is a manufacturer- and technology-independent TOSCA implementation. In addition to the command-line interface for template development, it includes an SDK for the development of TOSCA-compliant software. The Apache Software Foundation provides ARIA TOSCA to promote industry acceptance of TOSCA.

ARIA TOSCA is a framework designed to accelerate the implementation of orchestration software based on the open standard (Figure 1). ARIA provides a library and programming interface that can be used to connect to existing environments, the great advantage being that no changes need to be made to existing configurations.

Figure 1: ARIA TOSCA has a wealth of plugins that support connections to IaaS solutions, management environments, containers, and software-defined network environments.

The ARIA TOSCA DSL Parser plays an important role. It serves to interpret the TOSCA templates, generate a deployment diagram of the application, and validate the template with regard to its validity. TOSCA determines the blocks in question for template creation, and the parser can recognize relationships or possible relations. The template data is written in declarative YAML with normative TOSCA types. Additionally, technology-specific types can be introduced and integrated into the environment with ARIA plugins and without the need to modify the parser code. The current version of ARIA natively supports TOSCA Simple Profile in YAML v1.0 and TOSCA Simple Profile for NFV.

Another important element is ARIA workflows, which are automated process algorithms that allow for dynamic interaction with the graph described by the application topology template. What sounds abstract at first glance is simple in itself: The workflows determine which tasks are processed in which order. A task can be an operation or other action. Operations, especially complex operations, can optionally be implemented as plugins. Other actions combine the execution of user-defined scripts or code.

ARIA workflows can in turn be part of TOSCA templates and access graphs dynamically. The workflows are implemented in Python and use a dedicated API, which allows access to the graph and run-time context of an application. ARIA TOSCA is equipped with some basic workflows responsible for (1) installation, (2) uninstallation, (3) customization, and (4) repair of the installation. Even if these workflow configurations do not handle any cloud-specific functions, they are still useful as examples of application possibilities. User-defined workflows use the same APIs as these four standard processes.

ARIA plugins extend the normative TOSCA types, adding node and relationship types. Again, no modifications to the parser code are necessary. Like blueprints, these plugins can be extended to cover specific functional scopes and can even be combined with each other. For example, OpenStack Kilo and OpenStack Juno can be supported in one template along with a combination of various technologies (e.g., combining OpenStack nodes with VMware and Amazon, but also with routers, firewalls, a Kubernetes installation, etc.). Interaction with Infrastructure as a Service (IaaS) APIs, management environments, monitoring tools, and more is also possible with ARIA plugins. ARIA TOSCA natively supports the following plugins:

• IaaS plugins for OpenStack, AWS, VMware, and Google Cloud Platform (GCP) Azure
• CM plugins for Puppet, Chef, Ansible, and SaltStack
• Container plugins for Kubernetes, Docker, Mesos, and Swarm
• SDN plugins for OpenDaylight (ODL) and Open Network Operating System (ONOS)
• Script plugins for Bash, Python, and others

Fortunately, the plugins are part of the template package and are loaded dynamically on demand. ARIA TOSCA comes with some standard plugins, so developers and administrators can gain some initial experience.

Commissioning ARIA TOSCA

The TOSCA implementation is based on Python and requires a Python 2.6 or 2.7 interpreter; version 3 is not currently supported. ARIA TOSCA is available for download from the Python project site [2]; the easiest way to install it is from the repository:

$ pip install --upgrade pip setuptools
$ pip install apache-ariatosca

Alternatively, you can install from the source code by downloading the sources from the PyPI website, extracting the archive, switching to the dir directory, and executing the commands:

$ pip install --upgrade pip setuptools
$ pip install

The source code contains the relevant examples and documentation. ARIA has several optional dependencies that appear when running operations via SSH. Please note that the necessary licenses might not be compatible with Apache license 2.0, which you should check on a case-by-case basis. In Debian-based environments, run the commands:

$ apt-get install -y python-dev gcc libffi-dev libssl-dev
$ pip install apache-ariatosca[ssh]

ARIA TOSCA provides the simplest of all examples, "Hello World," which can be found in the examples subfolder of the ARIA installation (see the box titled "Hello World with ARIA TOSCA"). To use it, load the sample template into ARIA and assign it a name of your choice (e.g., my_service_template), create a server based on the template, name it my_service, and execute an installation workflow on the service configuration:

$ aria service-templates store examples/hello-world/helloworld.yaml my_service_template
$ aria services create my_service -t my_service_template
$ aria executions start install -s my_service

tosca_definitions_version: tosca_simple_yaml_1_0
node_types:
  WebServer:
     derived_from: tosca.nodes.Root
     capabilities:
      host:
       type: tosca.capabilities.Container
  WebApp:
     derived_from: tosca.nodes.WebApplication
     properties:
      port:
       type: integer
topology_template:
  node_templates:
     web_server:
      type: WebServer
     web_app:
      type: WebApp
      properties:
       port: 9090
      requirements:
       - host: web_server
      interfaces:
       Standard:
        configure: scripts/configure.sh
        start: scripts/start.sh
        stop: scripts/stop.sh
  outputs:
     port:
      type: integer
      value: { get_property: [ web_app, port ] }

<html>
  <header>
     <title>ARIA Hello World</title>
  </header>
</body>
  <h1>Hello, World!</h1>
  <p>
     blueprint_id = {{ ctx.service_template.name }}<br/>
     deployment_id = {{ ctx.service.name }}<br/>
     node_id = {{ ctx.node.name }}
  </p>
  <img src="aria-logo.png">
</body>
</html>

On the ARIA system, you can execute the template with a simple web server. To check the execution, open the URL http://localhost:9090 .