1. TOSCA Interoperability Demonstration
Topology and Orchestration Specification for Cloud Applications (TOSCA) Standard
TOSCA Interoperability Demonstration
Participating Companies:
Join the TOSCA Technical Committee

2. Complete cloud application modeling and orchestration
TOSCA
Complete cloud application modeling and orchestration
Enable portability and semi-automatic management of cloud applications across clouds regardless of provider platform or infrastructure thus expanding customer choice, improving reliability, and reducing cost and time-to-value.
The TOSCA standard…
Contributing Members
provides the Interoperable Description of:
Applications, their component Services and Artifacts
Platform and Infrastructure services,
Relationships between these services, and the
Management and Operational behavior of these services
facilitates higher levels of Solution Portability:
Portable deployment to any cloud that can orchestrate TOSCA service templates
Simplify Migration of existing customer apps. to cloud
Dynamic, Flexible Scaling and bursting of multi-cloud applications
Enables Software Defined Environments (SDEs)
Template contents provide the means to optimize the underlying cloud infrastructure

3. Business Value of TOSCA
Open Ecosystem for Cloud Services
Vendor-independent definitions of complex Cloud services provide new marketing channel for solutions in the Cloud
Decoupling of Cloud infrastructure and Cloud content helps focus on key aspects: Cloud Provider or Cloud Service Provider
Ability to deploy services in any standards-compliant environment avoids vendor lock-in and eases migration
Interoperability and Composition
Goes beyond VMs in describing the cloud application‘s components and their dependencies
Composition of services defined independently by their domain experts into a higher-value service
Key enabler for open hybrid Clouds
Easy Adoption of new Cloud Services
Model-driven creation of Cloud Services
Standardized deployment into various kinds of environments
from test to production, from cloud A to cloud B
Process-driven Cloud Service Lifecycle Management

4. FlexFrame Orchestrator
Interoperability Demonstration Overview
Demonstrating: different cloud orchestration tools from different vendors all interpreting and seamlessly running the same TOSCA service templates in the same way.
FlexFrame Orchestrator
Suite
Manage
Design
Orchestrate
Cloud Services
Cloud Monitoring
TOSCA
Cloud Application Marketplaces
Publish
Customize
Telco Cloud Solution
Workload Deployer and SmartCloud
Benefits: Using TOSCA service templates, enterprise customers can easily move their applications from one cloud to another and orchestrate them using the expert knowledge the application developers have built into them.

5. Overview – “Public TOSCA Interop. Demo”
Interoperability Demonstration Overview
Overview – “Public TOSCA Interop. Demo” 1
Vnomic’s Service Designer Tool
Models the TOSCA Interop. Demo App:
2-Tier SugarCRM App, MySQL Database
Widget.com
Compliance Tools 1 2
Export of SugarCRM Application as TOSCA CSAR file
Format: Cloud Service Archive (CSAR) file
Export to a Cloud Marketplace or “AppStore” of TOSCA Modeled Applications and Services
Service Designer 2
Hybrid Application 3
TOSCA “Cloud Marketplace”
Customers can rapidly discover and implement cloud solutions from TOSCA Service Templates 3
ISM Cloud Marketplace 4
Download / Import of SugarCRM to choice of:
Runtime Interop. - TOSCA-enabled clouds for seamless deployment <or>
Tooling Interop. - TOSCA-enabled tools that can alter TOSCA Service Template models
Pitched HP Product Teams 8/5; Expecting comeback 4 4 4 4 5
View SugarCRM in Cloud of Choice
Companies provide 3 minute video of SugarCRM in their tools or deployed to clouds
Companies can opt to show more if they desire and if asked to by press or analysts.
Others
TBD
IBM Workload
Deployer (IWD) +
IBM SmartCloud
Huawei
Cloud
Fujitsu
FlexFrame
Note: Companies can choose to work with SAP (in advance) to demonstrate a SAP CRM model for private interop. events.

6. Composing a TOSCA Service Template for a “SugarCRM” Application
using Vnomic’s Service Designer,
The SugarCRM application include 2 “Tiers”:
Web Application Tier (Linux, Apache, PHP, SugarCRM)
Database Tier (Linux, MySQL)

7. which encapsulates the Application Architect’s “Expert Knowledge”
The Cloud Application is made “Portable” and packaged using TOSCA’s Cloud Service Archive (CSAR) format
which encapsulates the Application Architect’s “Expert Knowledge”
for this demo, we choose to publish the “SugarCRM” Cloud Application
to IBM’s Integrated Service Mgmt. (ISM) Cloud Marketplace

8. Showing “SugarCRM” as a newly published service by Vnomic into IBM’s “Cloud Marketplace”
TOSCA service templates could be published and shared on both public and private marketplaces
Demonstrating the vision of an “Open Ecosystem” of cloud services based upon TOSCA standardized service templates

9. The “SugarCRM” Application’s Topology Template Viewed in IWD
Web Server Tier (left), Database Tier (right)
… developers can choose to edit the components’ properties or simply use the defaults settings packaged in the CSAR file prior to deployment

10. The “SugarCRM” TOSCA Application is Fully Deployed and Running using IBM SmartCloud Foundation Services
… we can see that both the Web Server and Database Tiers are running
and assigned Public IP Addresses

11. Login to “SugarCRM” application running on an IBM Cloud
Demonstrating Seamless TOSCA “Run-time” Portability
… using the IP Address allocated by IBM’s Cloud for the Apache Web Server which was part of the Web Server Tier of the TOSCA “SugarCRM” application

12. More on
TOSCA Modeling…

13. Modeling Topologies with TOSCA
Service Topologies are described using the TOSCA “Meta-model”:
Nodes
Represent Components of an application or service and their Properties. Example nodes include:
Infrastructure: Compute, Network, Storage, etc.
Platform: OS, VM, DB, Web Server, etc.
Granular: functional Libraries, Modules, etc.
Include Operations which are the management functions for the node
e.g. deploy(), start(), stop(), connect(), etc.
Export their dependencies on other nodes
as Requirement and Capabilities
Relationships
Represent the logical Relationships between nodes
e.g. “hostedOn”, “connectsTo”, etc.
Describes the valid Source and Target nodes they are designed to couple
e.g. source “web application” node is designed to “connectTo” a target “database” node
Have their own Properties and Constraints
Service Templates
Group the nodes and relationships that make up a service’s topology
Allowing modeling of sub-topologies
Service Templates “look like nodes” enabling:
Composition of applications from one or more service templates
Substitution of abstract Node types with available service templates of the same type
Artifacts
Describe Installables and Executables required to instantiate and manage a service. Currently, they include:
Implementation Artifacts:
Executables or Plans that implement a Node’s or Relationship’s Operations (e.g. a Bash script)
Deployment Artifacts:
Installables of the components (e.g. a TAR file)
A service’s Topology Model is included in a TOSCA Service Template which is packaged and shared, along with all dependent artifacts, as a TOSCA Cloud Service Archive (CSAR)

14. TOSCA service templates can model any cloud application or infrastructure pattern
Business Application Layer
Application Patterns
on either PaaS, IaaS platforms
Composition Layer
app db
Service Oriented Applications
Software Defined Environments
Infrastructure Patterns
compute
network
storage
App. Resource Relationships
PaaS Layer
Generalized, Normative Types
OpenStack is one example
IaaS Layer
Heat Engine
CFN / HOT
Platform and Infrastructure
Resources
(using Heat Engine)
“Backplane” Drivers
HW / Provider Specific
SLAs describe attributes for operations, billing, availability, serviceability, performance and penalties for violations
Measures include (NIST): Response Time, Automation, Agility, Linearity, Elasticity, Durability, Load Balancing, Reliability, Throughput, Availability
compute
Compute1,
single
Compute2,
scalable
Network2
Network1
Storage
Hardware
Derived, Custom Types
Optimized Workloads
tmForum SLA Standard:
Service Level Agreement (SLA)
The Service Level Agreement serves as a means of formally documenting the service(s), performance expectations, responsibilities and limits between cloud service providers and their users.
A typical SLA describes levels of service using various attributes such as: availability, serviceability, performance, operations, billing, and penalties associated with violations of such attributes.
Service Level Agreements: are referenced by the master service level agreement. They can contain:
Business level objectives (BLO):
Business Level Objectives (often in form of a Business Policy) relate to the measurements that are not service specific but impacting Cloud Buyers’ business objectives such as disaster recovery, data privacy etc.
Service level objectives (SLO):
SLOs are specific measurable characteristics of the service being monitored. They are usually specified in a Service Level Specifications (SLS) template.
SLOs are composed of one or more quality of service (QoS) objects or Service Metrics
Service Design Phase: Software factory tools and processes can help govern and facilitate the Cloud service design phase. These tools will be implemented according to standards of Standardized Service Templates that contain information that will contribute to the SLA calculation at the design phase, for example a typical Response Time of 3-5 seconds.
Service Deploy Phase: System or policy engineer may provide additional information for the specific deployment, such as response time must less than 4 seconds and using high-security encryption mechanism
Service Operation Phase: Monitoring and data retrieval activities happen. The management applications need to have a consistent method to access and/or retrieve and report from each instance of the service. This can be achieved via SMI and the management and monitoring threshold based on the information that is provided in a catalogue/repository from various stakeholders.
Value: enables rapid and continuous delivery of diverse set of workloads with agility and optimization on programmable heterogeneous infrastructure leveraging reusable building blocks

15. TOSCA Service Templates support …
Allow developers to describe the topology of their applications and encapsulate their expert knowledge, including service configurations, policies and dependencies.
Complete Topology Modeling
Full Lifecycle Orchestration
Go beyond simple deployment; services can provide instructions for any lifecycle operations enabling precise orchestration and control of application management tasks.
Supports the ability to substitute logical parts of applications through composable service templates providing choice in both service vendor and implementation.
Service Composability

16. Primer Scenarios: Developing a “Single-Tier MySQL Database”
Containment
MySQLDatabase
Database
Nodes can “Host” or contain other Nodes of specified types
Nodes can export the types of nodes they are “capable” of hosting,
These are matched to other nodes that export their specific host container “requirements”
In this example:
A MySQL Database node is “hostedOn” a “MySQL Database Management System (DMBS) node
The MySQL DBMS node, in turn, is “hostedOn” a “LinuxOS”, and so on…
hostedOn
MySQL
DBMS
Component “Containment” Relationship Type
hostedOn
MySqlLinuxOS
Operating
System
hostedOn
“Tier” is a topological concept used to describe sets of nodes (or sub-topologies) that can be deployed and managed as a single group
MySqlVM
Server
This service template contains a reusable MySQL “database tier”. It includes the entire set of dependent service component layers necessary for deploying a standalone MySQL Database on a MySQL Database Management System (DBMS). The DBMS’ required hosting environment is also described which includes a Linux Operating System (OS), a Virtual Machine (VM) container and “Tier” container which is used to logically group them for overall management.
hostedOn
DBTier
Tier

17. Primer Scenarios: “Two-Tier SugarCRM Web Application”
DBTier
Service Template
Connectivity
SugarCRMApp
Web
Application
DependsOn
Nodes can “Connect” to other specified node types
Nodes export the types of nodes they require “require” connectivity to,
These are matched to nodes that export they are “capable” of accepting specific connections
In this example:
The SugarCRM Application node “connectsTo” a database node in another “tier”
The “DB Tier” components are packaged into a separate service template permitting Substitution
SugarCRM
Database
ConnectsTo
hostedOn
hostedOn
PHPModule
Apache
Module
Apache
WebServer
MySQL
DBMS
hostedOn
ApacheLinuxOS
Operating
System
MySqlLinuxOS
Operating
System
hostedOn
MySqlVM
Server
ApacheVM
Server
This service template contains a typical, two-tier Apache Web Application customized to host an open source Customer Relationship Mgmt. (CRM) application called “SugarCRM”. The “Web Tier” includes the entire set of dependent service components necessary for deploying the SugarCRM web application on an Apache web server, with PHP Module support. It’s required hosting environment also includes a Linux Operating System (OS), a Virtual Machine (VM) container and a “Tier” container to logically group all related components. It also contains a similarly composed MySQL “Database Tier” which the “Web Tier” connects to during the SugarCRM Application's lifecycle.
Network “Connectivity” Relationship Type
hostedOn
DBTier
Tier
WebTier
Tier
Components grouped into composable service templates.

18. Advanced Scenarios: “Scalable SugarCRM Web Application”
Scalability
ApacheLB
LoadBalancer
WebTier
Service Template
DBTier
Service Template
“Tier” Node Types convey scalability
The “Web Application Tier” is declared Scalable with upper bounds “n” instances
Note: the “Database Tier” remains a single instance
A Load Balancer node is added to the previous template to route requests among “Web Application Tier” instances
Both tiers are packaged into their own service templates permitting Substitution
SugarCRMApp
Web
Application
SugarCRM
Database
Apache
WebServer
MySQL
DBMS
ApacheLinuxOS
Operating
System
MySqlLinuxOS
Operating
System
ApacheVM
Server
MySqlVM
Server
This service template contains a typical, two-tier Apache Web Application customized to host an open source Customer Relationship Mgmt. (CRM) application called “SugarCRM”. The components of both the “Web Tier” and “Database Tier” are packaged into their own “Service Templates” to support Substitutability. In this manner, the service template can be treated as a pseudo-node exporting its aggregated requirements and capabilities. In addition, the “Web Tier” is declared “Scalable” and the composite application’s template includes a “Load Balancer” node that understands how to connect to and scale it.
1..n
WebTier
ScalableTier 1
DBTier
Tier
The range of instances would be a property of the “Tier” Node Type
Components grouped into composable service templates.