Lifecycle Management Automation through TOSCA September 2018

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

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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

TOSCA Resources

TOSCA Resources – Learn More TOSCA Technical Committee (TC) Public Page (TC approved updates on plans, documents, resources, and more) https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca OASIS TOSCA Wiki https://wiki.oasis-open.org/tosca/ OASIS TOSCA LinkedIn Group: (latest news, community and eco-system updates, etc. Join now to stay informed!) https://www.linkedin.com/groups/8505536 OASIS YouTube Channel, TOSCA Playlist https://www.youtube.com/user/OASISopen , http://bit.ly/1BQGGHm Contact the Technical Committee Co-Chairs Paul Lipton, paul.lipton@ca.com; Chris Lauwers, lauwers@ubicity.com Find out more about TOSCA through these links and contacts.