The document discusses T-Systems' proof of concept (POC) for orchestrating services with TOSCA, aimed at assessing its capabilities in deploying cloud applications. It outlines the objectives, methodology, and findings of the project, which included defining application stacks, deployment plans, and the challenges of using TOSCA for interoperability and portability in cloud computing. The evaluation reveals limitations in TOSCA resources, documentation, and the need for further examples to aid developers in utilizing the framework effectively.

1. T-Systems’ ODCA Service Orchestration with TOSCA PoC
T-Systems, T-Labs, FZI
– strictly confidential, confidential, internal, public – 9/26/2014 1

2. Agenda
9/26/2014 2
 Brief PoC Overview
 Q&A
 General Comments & Recommendations

3. PoC Overview

4. 9/26/2014 4
Abstract
In context of machine level service orchestration:
 Define an application stack
 Package the Application stack using TOSCA
 Trigger the deployment/un-deployment of the application to/from a target
platform
Thereby determine:
 General capabilities and specificity of TOSCA
 Opportunities, shortfalls and challenges when using TOSCA for Service
Orchestration
 Current level of industry tools which support TOSCA
 General acceptance levels in the industry for TOSCA as a standard

5. The objective of our work
Investigate the capabilities and maturity of TOSCA specification in the context of
designing and deploying Cloud applications through a Proof of Concept project.
 Explore the available solutions and/or build the necessary components for deploying an
application using TOSCA
Project duration: 6 months
Funded and coordinated by T-Systems
Testbed provided by Telekom Innovation Laboratories
 Openstack infrastructure for the resources
 Opscode Chef server for configuration management
5

6. Motivation
6
Cloud portability
 The ability of cloud computing users to move their data or applications between cloud
environments at low cost and minimal disruption.
 Migrate a fully-stopped Virtual Machine (VM) instance from one provider to another.
Interoperability
 The ability of two or more systems or components to exchange information and to use the
information that has been exchanged
Cloud interoperability => Cloud portability
Conflicting or absent cloud interoperability standards result in:
 Vendor/technology lock-in
 Deployment inflexibility
 Increased cost for ongoing development and lifecycle management/migrations

7. Current State-of-the-Art
Standards (are) adopted by cloud providers -> developers create their applications
independently of specific platform environments
 TOSCA (more details in following slide), HEAT, CAMP
Intermediation: An intermediate layer (exists) that decouples application development from
specific platform APIs
 E.g. mOSAIC, PaaS Semantic Interoperability Framework (PSIF), SimpleCloud
Orchestration: Technologies (manage the deployment) of applications, management of
resources (Software Defined Infrastructure) etc.
 E.g. Chef, Puppet
IaaS: Interoperability between hypervisors (is well supported)
 E.g. OVF
 White Paper, T-Systems Telekom Innovation Laboratories, FZI, Intel, “Virtual Machine Interoperability” Usage Model -
Open Data Center Alliance
7

8. OASIS TOSCA
Topology and Orchestration Specification for Cloud Applications
 Aims to leverage portability of application layer services between various Cloud environments
 XML-based language describes application topologies and management procedures
Definitions all the necessary Nodes and Relationships, their interfaces and properties must be defined. Apart from the abstract
definitions, the implementation of each entity is specified.
Service Template this is the structure of the Cloud application presented as a Topology Template. Apart from the overall
architecture of the topology, the manageability of it is defined through the Plans section.
Plans are defined as process models, i.e. a workflow of one or more steps. The TOSCA specification relies on existing languages
like Business Process Modelling Notation (BPMN) or Business Process Execution language (BPEL).
Topology Template
Version 1, 25 November 2013
Version 2 is ongoing
Node
Template
Relationship
Template
Service Template
Node Types
{ }
Interfaces
Properties
Node Type
Relationship Types
{ }
Plans
Interfaces
Properties
Relationship Type
8

9. PoC Scenario
High Level Process
1. Application Developer
creates a new TOSCA-compliant
Application Topology
2. Define the application deployment/un-deployment
plan using BPMN language
3. Use the provided tools to upload the
TOSCA file and initiate the deployment
(Pre-defined TOSCA types
and artifacts might be used)
9
Application
Topology Definition
Deployment
process (TOSCA
Plan) definition
Upload TOSCA xml
file to TOSCA
Container
Trigger deployment
process against
Plans engine
VM node creation
and software
installation

10. Use case definition
10
Basic 3-tier application
 Load balancer – HA Proxy
 Web application on application server – Tomcat server
 Database - MySQL
DemoWeb
Application
Application
Server
Application
Server
DemoWebAp
plication
Database Server
Load Balancer

11. Modeling the application topology with TOSCA
11
Types
Node Types Relationship
Types
Node Types
Impl
Relationship
Types Impl
Service Template
Plans

12. Node Types for Use Case
12
Node
Types
Virtual
Machine
OS
Data
base
Web
Server
Open
Stack
VM
Linux
Ubuntu
12.04
SQL
MySQL
Server
Load
Balancer
Apache
Tomcat
Server
HAProxy
m1.small
flavor
Relationship
Type
Commu-nication
Hosted
On
Software
Demo
Web App

13. Node Type Implementations
13
Node Type
Implementation
DemoWeb
App
MySQL
Server Impl
Apache
Tomcat
Server Impl
Apache Tomcat Installation
Artifact
DemoWebApp Deploy
Artifact
MySQL Installation Artifact
HA Proxy Installation
Artifact
HA Proxy
Impl
Deployment Artifact Deployment Artifact Deployment Artifact Deployment Artifact

14. Relationship Types
14
Relationship
Software hosted
on OS
Communication
OS hosted on VM
Ubuntu12.04
hosted on
M1.small
Hosted On
RemoWebApp
Communicate
MySQL
HA Proxy
Communicate
Apache Tomcat
Type
HA Proxy
hosted on
Ubuntu12.04
DemoWebApp
hosted on
Apache Tomcat
MySQL
hosted on
Ubuntu12.04
Apache Tomcat
hosted on
Ubuntu12.04

15. Topology Template
15
Ubuntu
12.04
MySQL
Server
HA
Proxy
m1.small
flavor
Ubuntu
12.04
m1.small
flavor
HostedOn
HostedOn
Demo
Web
App
HostedOn
Apache
TomcAaptache
Tomcat
HostedOn HostedOn
HostedOn
Demo
Web
App
Ubuntu
12.04
m1.small
flavor
HostedOn
Ubuntu
12.04
m1.small
flavor

16. Use case implementation constraints & assumptions
The use case application must be decomposed into three elements:
 Software components
 Operating system
 Virtual Machine
TOSCA allows inheritance within the Node Type definition section
Only the Software Node Types have an implementation (Node Type implementation),
and therefore Artifacts which include the Chef roles and recipes
The description of the infrastructure is realized through TOSCA Relationships
(HostedOn, communicate)
The deployment plan of the use case is written in BPMN language (Intalio Design)
 The Application Developer must use the Intalio Design tool to generate the necessary deployment
plan. (Now Winery)
16

17. TOSCA Container Architecture
Telekom Cloud Testbed
Apache Tomcat
Intalio BPMS
Deployment Process
Start Event
Interrupting
Service Task
End Event
Interrupting
TOSCA
Container
Web Service
OpenStack Cloud Environment
Nova
Compute
Service
Opscode Chef Server
SOAP Message Flow
Start BPMN Process
(Intalio Editor)
WSDL
Cloud User
Full TOSCA
Document
Knife
OpenStack Instances
JAX-WS
Cookbooks
Recipes
Roles
TOSCA Plan
in BPMN
(XML)
Quantum
Network
Service
17
TOSCA
server create cmd
Bootstrap roles
& recipes
deploy node

18. Intermediary, domain specific data model
18

19. Evaluation
10 successful deployment runs
 Avg of 17 minutes 25 seconds
Major effort is focused on defining
Software installations
Sequential deployment is necessary to guarantee that Chef ”recipes” can be
applied correctly
Cloud Formation experiment
 Average deployment time of 14 minutes 13 seconds
 Deletion time of 1:30 minutes
 The deployment time savings in these experiments may root from the use of hosted services
19

20. Findings on TOSCA v1.0
1. Limited resources available to effectively explain all the entities and concepts defined in TOSCA. The Specification document
20
lacks information when presenting new concepts.
2. The available TOSCA examples are at high level, and do not present a complete Cloud deployment scenario. Some
implementation examples for a complete basic application should be provided, to guide potential developers in using the
framework.
3. Based on the available resources, it appears that one application topology can be described in many different ways (by
defining different types or levels of NodeTemplates, RelationshipTemplates etc.) = very open and nonspecific for enabling
interoperability. No suggested mapping between TOSCA entities (e.g. Node Types) and cloud resources available
a) There are multiple ways to express certain properties
b) Limited available examples and supported documentation
c) No suggested API or architecture for a TOSCA Container
I. Every provider is left to implement his own system
II. Different interpretation of the schema (in combination with previous)
4. Additional documentation relating to guidelines and technical recommendations when adopting the TOSCA framework would
be extremely helpful.
a) Data Model & Reference Model
b) TOSCA Container description

21. OpenTOSCA
CloudCycle Project from University of Stuttgart IaaS Group
[http://www.iaas.uni-stuttgart.de/OpenTOSCA]
1. OpenTOSCA Container (TOSCA runtime)
2. Winery (TOSCA Modeling Tool)
[http://winery.opentosca.org/winery/relationshiptypeimplementations/]
3. Released September 2013
4. Current version 1.1 [http://files.opentosca.de/v1.1/]
5. Limited full market support of TOSCA, no validation beyond XML schema validation
6. Cannot restart containers
7. No support is provided
21

22. Thank you
Questions?
Ryan Skipp
ryan.skipp@t-systems.co.za