1. Lifecycle Management Automation through TOSCA
September 2018

2. Orchestration and Operational Management
What is TOSCA?
OASIS TOSCA is an orchestration language for automating Service Lifecycle Management.
Service designers use TOSCA to create Service Templates that contain:
Model-based descriptions of services, platforms, infrastructure and data components, along with their relationships, requirements, capabilities, and configurations.
(Optionally) service-specific orchestration and lifecycle management directives and operational policies that operate on these models.
TOSCA assumes a Run-Time Environment (an “orchestrator”)
In which service models are processed
With the goal of
Orchestrating the service
Managing service lifecycles
TOSCA
Portable
Cloud
Application
TOSCA Service Template
Storage
Compute1 DB
Compute2
App
Network
Scaling
Policy
Orchestration and Operational Management

3. Copyright © 2018 Ubicity Corp.
TOSCA Features
Service modeling, onboarding, and instantiation
Automatically-generated workflows
Reusable building blocks
Pluggable framework for interacting with modeled entities
Support for specifying resource requirements
Deployment-time decisions about platforms and technologies
Closed-loop automation
Copyright © 2018 Ubicity Corp.

4. Copyright © 2018 Ubicity Corp.
TOSCA Features
Service modeling, onboarding, and instantiation
Automatically-generated workflows
Reusable building blocks
Pluggable framework for interacting with modeled entities
Support for specifying resource requirements
Deployment-time decisions about platforms and technologies
Closed-loop automation
Copyright © 2018 Ubicity Corp.

5. Service Modeling, Onboarding, and Instantiation
TOSCA uses Service Templates to model services
Service templates specify a service topology
A service topology is a graph that contains
The entities to be deployed (the nodes)
The relationships between these entities
Service templates are packaged together with service-specific orchestration artifacts in a Cloud Service Archive (CSAR) file.
CSAR files are typically onboarded into a Service Catalog maintained by the orchestrator
To allow service ordering and instantiation from the catalog.
Service templates define a number of service instance-specific input parameters
That need to be provided at service instantiation time
TOSCA Service Template
App DB
Compute1
Compute2
Network
Storage

6. Example TOSCA Service Model
Database Tier (container)
Application Tier (container)
Logging/Monitoring Tier (ELK)
logstash
elasticsearch
kibana
mongo_db
Database
paypal_pizza
store
WebApplication
SoftwareComponent
SoftwareComponent
SoftwareComponent
Capabilities
ConnectsTo
Capabilities
ConnectsTo
log_endpoint
search_endpoint
Requirements
Requirements
search_endpoint
nodejs
WebServer
Requirements
search_endpoint
Container
Container
mongo_dbms
Container
DBMS
logstash_server
elasticsearch _server
kibana_server
HostedOn
HostedOn
HostedOn
ConnectsTo
app_server
Compute
Compute
Compute
Compute
Capabilities
Capabilities
Capabilities
mongo_server
Compute
Container
Container
Container
collectd
rsyslog

7. Copyright © 2018 Ubicity Corp.
TOSCA Features
Service modeling, onboarding, and instantiation
Automatically-generated workflows
Reusable building blocks
Pluggable framework for interacting with modeled entities
Support for specifying resource requirements
Deployment-time decisions about platforms and technologies
Closed-loop automation
Copyright © 2018 Ubicity Corp.

8. Automatically-Created Workflows
TOSCA Workflows
Service Orchestration is the coordination of processes associated with creating and configuring the various service components (and their relationships) specified in a service topology
TOSCA uses workflows to coordinate these processes
TOSCA orchestrators create workflows automatically
Based on the dependencies between service components represented by relationships
Avoids the need to program workflows manually
Avoids the need to update workflows whenever service templates change
Copyright © 2018 Ubicity Corp.

9. Copyright © 2018 Ubicity Corp.
TOSCA Features
Service modeling, onboarding, and instantiation
Automatically-generated workflows
Reusable building blocks
Pluggable framework for interacting with modeled entities
Support for specifying resource requirements
Deployment-time decisions about platforms and technologies
Closed-loop automation
Copyright © 2018 Ubicity Corp.

10. Types—Reusable Building Blocks
TOSCA nodes and relationships have types
Types define the set of named properties and attributes (and associated data types) that must be supported by all entities of a given type
TOSCA orchestrators know how to process entities of a given type
Based on orchestration logic specified as part of type creation
Types are organized in profiles
A TOSCA profile is a collection of types for a specific application domain
TOSCA Simple Profile for YAML
A standard library that defines a set of common base types that can be used by cloud application designers
TOSCA NFV Profile
Collection of TOSCA types that encode the ETSI NFV IFA information models
Copyright © 2018 Ubicity Corp.

11. TOSCA Meta-Modeling Hierarchy
TOSCA Meta-Modeling Constructs support all phases of the service lifecycle
Instances
Created From
Templates
Using
Types
Defined By
Type Schema
Run-time
Simple constructs to model deployed services
Typically stored in Active Inventory
Can represent both instantiated services as well as available resources
Orchestration time
Add modeling constructs in support of orchestration
Typically stored in Service Catalog
Define Inputs for deployment-specific configuration
Design time
Types define reusable components
Typically stored in Component Catalog
Add “specifications” to define standard collections of attributes for similar components
DSL design
Language defines schema for creating new types
For all TOSCA entities
Copyright © 2018 Ubicity Corp.

12. Copyright © 2018 Ubicity Corp.
TOSCA Features
Service modeling, onboarding, and instantiation
Automatically-generated workflows
Reusable building blocks
Pluggable framework for interacting with modeled entities
Support for specifying resource requirements
Deployment-time decisions about platforms and technologies
Closed-loop automation
Copyright © 2018 Ubicity Corp.

13. TOSCA Interfaces, Operations, and Artifacts
Nodes and Relationships have Interfaces
Used by orchestrator to operate on nodes and relationships
When orchestrator runs workflows
Interfaces Types define
Operations that can be invoked on nodes or relationships by the Orchestrator
Inputs that need to be provided to each operation
Outputs that specify which node and relationship properties are affected by each operation
Artifacts Implement Operations
Service template designers provide operation implementations through (typed) artifacts
Bundled in Cloud Service Archive (CSAR) file
Or, stored in external repository and referenced by service templates
TOSCA includes normative interface types
Normative interface types are associated with normative node and relationship types
Copyright © 2018 Ubicity Corp.

14. Normative Interface Types
Normative interface type for managing lifecycle of nodes
Normative interface type for configuring relationships between nodes
Copyright © 2018 Ubicity Corp.

15. Copyright © 2018 Ubicity Corp.
TOSCA Features
Service modeling, onboarding, and instantiation
Automatically-generated workflows
Reusable building blocks
Pluggable framework for interacting with modeled entities
Support for specifying resource requirements
Deployment-time decisions about platforms and technologies
Closed-loop automation
Copyright © 2018 Ubicity Corp.

16. Expressing Requirements for Resources
TOSCA does not distinguish between service component models and resource models
Same models are used for both
Resource is a “role”, not an intrinsic characteristic of an entity
Instead, TOSCA node templates include Capabilities and Requirements
Resources expose Capabilities
Service components define Requirements
Relationships link Node Requirements to Node Capabilities
Requirement anchors the source of a relationship
Capability anchors the target of a relationship
Node Templates express need for resources from an inventory using dangling requirements
Requirements that are not fulfilled by other nodes in the template
Expressing requested target capability from a resource node
(Optionally) expressing Node Filter that further constraints nodes and capabilities with which to satisfy the requirement
connect_relationship
ConnectsTo
service_node
resource_node
Requirement
Capability
Copyright © 2018 Ubicity Corp.

17. Fulfilling Requirements at Orchestration Time
Service template specifies requirements
Orchestrator matches capabilities to requirements
Orchestrator
Entities in Active Inventory expose capabilities
Dangling requirements enable modular service design
Allow dynamic decisions about establishing relationships
Made at deployment time
Rather than having to statically specify relationships in service templates
At service design time
Avoids model proliferation
Active Inventory
Compute1
Compute2
Network
Storage
Copyright © 2018 Ubicity Corp.

18. Copyright © 2018 Ubicity Corp.
TOSCA Features
Service modeling, onboarding, and instantiation
Automatically-generated workflows
Reusable building blocks
Pluggable framework for interacting with modeled entities
Support for specifying resource requirements
Deployment-time decisions about platforms and technologies
Closed-loop automation
Copyright © 2018 Ubicity Corp.

19. Recursive Decomposition – Substitution of Abstract Services
Orchestrator makes substitution decisions at deployment time
Based on available infrastructure
Based on policies
Cloud Application
(Topology)
Java
Application
Monitoring
Service
(Abstract)
Monitoring Service
(Topology)
Collector
Web
Application
Server
Analytics
Service
(Abstract)
Analytics
Service
(Topology)
Monitoring
Framework
SQL
Datastore
Analytics
Engine
Logger
Service Topology 1
Hadoop
Service Topology 2
Service Topology 3

20. TOSCA is based on the Component Pattern
TOSCA supports only one single level of decomposition
Topologies are composed of nodes
Keeps composition in TOSCA extremely simple
Further decomposition is provided by the Component Pattern
A single node in one topology can be modeled as/substituted by an entire “sub” topology consisting of other nodes
Benefits of Component Pattern
Avoids the need to define service components as atomic or composite
Whether an entity is atomic or composite is not an intrinsic characteristic of that entity (even atoms are not atomic)
But rather it is a reflection of where the modeler stops decomposing
Supports abstraction
Drilling-down into lower-levels of abstraction
Rolling-up into higher-levels of abstraction
Allows dynamic reconfiguration of service topologies at run-time
By replacing different sub-topologies that substitute for the same node
Preferred mechanism for composing large systems from modular building blocks
Copyright © 2018 Ubicity Corp.

21. Copyright © 2018 Ubicity Corp.
TOSCA Features
Service modeling, onboarding, and instantiation
Automatically-generated workflows
Reusable building blocks
Pluggable framework for interacting with modeled entities
Support for specifying resource requirements
Deployment-time decisions about platforms and technologies
Closed-loop automation
Copyright © 2018 Ubicity Corp.

22. Closed-Loop Automation based on Policies
Orchestrators can evaluate Conditions based on Events that trigger Automatic or Imperative Actions
Policies can be declared independently and attached to various points in your models
Nodes
Groups of Nodes 2
Policy
Type
Event, Condition
Action
my_scaling_group
Scaling 1
Policy
Type
Event, Condition
Action
my_app_1
Compute
Capabilities
Container
...
Lifecycle
create
configure
backend_app
Compute
web-app
Compute
my_database
Compute 3
Policy
Type
Event, Condition
Action
Abstract
A key feature of any Cloud infrastructure is to provide auditing capabilities for compliance with security, operational and business processes.
In this talk we provide an overview of the recent enhancements made in OpenStack projects to support API and security auditing using the DMTF Cloud Auditing Data Federation (CADF) standard.
We will describe how auditing is seamlessly enabled for Nova, Glance, Swift, Cinder, Neutron and Keystone and illustrate what is audited, where it is stored, what the records contain and how this supports compliance.
We will finish by presenting some possible future directions such as extending the use of CADF beyond audit to facilitate event correlation and federation across multiple tiers. 22 22

23. TOSCA Resources

24. TOSCA Resources – Learn More
TOSCA Technical Committee (TC) Public Page (TC approved updates on plans, documents, resources, and more)
OASIS TOSCA Wiki
OASIS TOSCA LinkedIn Group: (latest news, community and eco-system updates, etc. Join now to stay informed!)
OASIS YouTube Channel, TOSCA Playlist ,
Contact the Technical Committee Co-Chairs
Paul Lipton, Chris Lauwers,
Find out more about TOSCA through these links and contacts.