Application and Network
Orchestration Using
TOSCA
DeWayne Filppi
What It Really Takes to Deploy and
Manage Apps
Provision
Install
Configure
Deploy
Monitor
Scale
Large Parts Are Mostly Manual
Real
Time
Analyti
cs
Correlate with
Historical Events
Feedb
ack
Execute
Policy
Send
Metrics
Setup Monitoring and
Alerts
Deploy and
Configure
Applications
Setup Machine,
Network, Storage
Push updates
Collect and Analyze
Logs
Troubleshoot
Measure
performance against
expected SLA’s
Set and tune Alerts
thresholds
Match Policy to
Incident
The Impact of Human Errors
80%of
outages impacting mission-critical
services will be caused by people and
process issues
50% of those outages
will be caused by
change/configuration/release
integration and hand-off issues
The Cost of Downtime Up by 60%
61%ARE HERE
83%WANT TO BE HERE
TIME
EFFECTIVE
NESS
The Current Reality..
Challenges
•80%of outages impacting
mission-critical services will be caused by
people and process
•83%are facing
significant roadblock keeping them from
moving to the next phase (Politics, Budget,
Time, Stuff)
Solution: Automation & Orchestration
•Remove Manual
Intervention out of the
application deployment process
•Reduce
Complexity and
Dynamically align to the business needs
The Solution
Automating The Application Deployment
Deploy
Fail-
over
Scale
Cloud Infrastructure
Intelligent OrchestrationHistorical data
Real Time Analytics Real Time
Analytics
Correlate
with
Historical
Events
Feedback
Execute
Policy
Send
Metrics
TOSCA –
The Glue for Putting all This Together
TOSCA
What is TOSCA?
TOSCA defines the
interoperable
description of
applications; including
their components,
relationships,
dependencies,
requirements, and
capabilities….
TOSCA in a Nutshell
Mapping of application logic
through plans (workflows),
policies, relationships,
actions
TOSCA State of the Union
 Top four cloud open standard (Forrester)
 5000+ participants
 65+ countries
The focus
of this session
What is TOSCA?
•Goal: cross cloud,
cross tools
orchestration of
applications on the
Cloud
•Status:
–Version 1 approved (XML )
–Version 2 (YAML!) in design
Why TOSCA?
•Standard
•Can Describe
–Any Topology
–Any Automation Process
•Portable between Clouds and
Tools
The TOSCA Building Blocks
Application
Topologies
Workflows
Policies
What’s in a TOSCA Topology?
•component in the topology
are called Nodes
•Each Node has a Type (e.g.
Host, BD, Web server).
–The Type is abstract and hence
portable
–The Type defines Properties
and Interfaces
•An Interface is a set of hooks
(named Operations)
•Nodes are connected to
one another using
Relationships
Topology
Infrastructure
Middleware
Application
Host Host Network
Apache Tomcat MySQL
Mod_proxy WAR Schema
Types and Nodes
Node in Topology
Abstract Type
Instance of
Portable Blueprint Concrete Types
Concrete Type
Implements
Concrete Plugin
Uses
Lifecycle Interface
defines
Implements
Lifecycle:
create:
start:
stop:
delete:
Node
Implementation
Instance of
Types and Nodes
Frontend_host
Host
Instance of
Portable Blueprint
OpenStack Host
Implementing
Nova Plugin
Uses
Lifecycle Interface
defines
Implementing
Lifecycle:
create: nova_provisioner.create
start: nova_provisioner.start
stop: nova_provisioner.stop
delete: nova_provisioner.delete
Lifecycle:
create:
start:
stop:
delete:
Concrete Types
My_OpenStack_Ho
st
Instance of
Relationships
Node in Topology Node in Topology
Node in Topology
Connnected_to
Hosted_on Relationship
Interface
defines
source_interfaces:
cloudify.interfaces.relationship_lifecycle:
- preconfigure
- postconfigure
- establish
- unlink
target_interfaces:
cloudify.interfaces.relationship_lifecycle:
- preconfigure
- postconfigure
Relationships
Host Network
Tomcat
Connnected_to
Hosted_on Relationship
Interface
defines
source_interfaces:
cloudify.interfaces.relationship_lifecycle:
- preconfigure
- postconfigure
- establish
- unlink
target_interfaces:
cloudify.interfaces.relationship_lifecycle:
- preconfigure
- postconfigure
Translated to TOSCA
Node
Node
Node
Connected_to
relationship
Hosted_on
relationship
Properties
Frontend_host
Host
Instance of
Portable Blueprint
OpenStack Host
Implementing
Concrete Types
My_OpenStack_Ho
st
Instance of
Memory Size
Memory size = 2GB
Image_Id=1235
Properties
schema
Property values
Generic Properties
Schema
Image Id
Policies TOSCA 1.0 didn’t
elaborate much on
policies
TOSCA 2.0 (draft)
discusses specific DSL
for specific policies
such as SLA of a Node
Out take:
Policies are imperative
Workflows TOSCA 1.0 – Workflows
(Plans) are in any WF
language.
Strong preference for BPMN 2.0
TOSCA 2.0 – No change
Cloudify 3.0 take –
Workflows are also tool
specific, currently we use
Radial (Ruby based DSL)
but seeking an alternative
for future versions
Putting It All TogetherTOSCA Template
(Blueprint in Cloudify)
contains:
Application Topology
Nodes
Interfaces
Properties
Artifacts (Plugins in Cloudify)
Relationships
Interfaces
Workflows
Policies
Portable Blueprint
Openstack_host type
Type implementation
Proxy
REST
+ File
Server
GUI
Workflow
Engine
Task
Manager
Blueprint + Runtime
Data
Policy
Engine
Agent
Monitoring
Data
Agent
Monitoring
Agent
Application
Stack
Cloudify Manager
App VM
Invokes
Reports
Creates
Metrics VM
Logs +
Events
Remote Agents
Agent
Agent
Agent
Architecture
Apache Server DB Server
NodeJS
NodeCeller
MongoDB
TOSCA (Like) Example
• App Network
• App Subnet
• App Port
• Security Group
• Apache Floating IP
• Router Gateway
• Data Network
• Data Subnet
• Data Port
• Security Group
Router
Monitoring, Logging CI
Network View
Topology View
TOSCA (Like) Blueprint
References
Node Cellar example
https://github.com/cloudify-cosmo/cloudify-nodecellar-
openstack
Cloudify 3
http://getcloudify.org
TOSCA Overview
http://www.slideshare.net/opendatacenter/forecast14-poc3-
final100

TOSCA and Cloudify

  • 1.
    Application and Network OrchestrationUsing TOSCA DeWayne Filppi
  • 2.
    What It ReallyTakes to Deploy and Manage Apps Provision Install Configure Deploy Monitor Scale
  • 3.
    Large Parts AreMostly Manual Real Time Analyti cs Correlate with Historical Events Feedb ack Execute Policy Send Metrics Setup Monitoring and Alerts Deploy and Configure Applications Setup Machine, Network, Storage Push updates Collect and Analyze Logs Troubleshoot Measure performance against expected SLA’s Set and tune Alerts thresholds Match Policy to Incident
  • 4.
    The Impact ofHuman Errors 80%of outages impacting mission-critical services will be caused by people and process issues 50% of those outages will be caused by change/configuration/release integration and hand-off issues
  • 5.
    The Cost ofDowntime Up by 60%
  • 6.
    61%ARE HERE 83%WANT TOBE HERE TIME EFFECTIVE NESS The Current Reality..
  • 7.
    Challenges •80%of outages impacting mission-criticalservices will be caused by people and process •83%are facing significant roadblock keeping them from moving to the next phase (Politics, Budget, Time, Stuff) Solution: Automation & Orchestration •Remove Manual Intervention out of the application deployment process •Reduce Complexity and Dynamically align to the business needs The Solution
  • 8.
    Automating The ApplicationDeployment Deploy Fail- over Scale Cloud Infrastructure Intelligent OrchestrationHistorical data Real Time Analytics Real Time Analytics Correlate with Historical Events Feedback Execute Policy Send Metrics
  • 9.
    TOSCA – The Gluefor Putting all This Together TOSCA
  • 10.
    What is TOSCA? TOSCAdefines the interoperable description of applications; including their components, relationships, dependencies, requirements, and capabilities….
  • 11.
    TOSCA in aNutshell Mapping of application logic through plans (workflows), policies, relationships, actions
  • 12.
    TOSCA State ofthe Union  Top four cloud open standard (Forrester)  5000+ participants  65+ countries The focus of this session
  • 13.
    What is TOSCA? •Goal:cross cloud, cross tools orchestration of applications on the Cloud •Status: –Version 1 approved (XML ) –Version 2 (YAML!) in design
  • 14.
    Why TOSCA? •Standard •Can Describe –AnyTopology –Any Automation Process •Portable between Clouds and Tools
  • 15.
    The TOSCA BuildingBlocks Application Topologies Workflows Policies
  • 16.
    What’s in aTOSCA Topology? •component in the topology are called Nodes •Each Node has a Type (e.g. Host, BD, Web server). –The Type is abstract and hence portable –The Type defines Properties and Interfaces •An Interface is a set of hooks (named Operations) •Nodes are connected to one another using Relationships
  • 17.
  • 18.
    Types and Nodes Nodein Topology Abstract Type Instance of Portable Blueprint Concrete Types Concrete Type Implements Concrete Plugin Uses Lifecycle Interface defines Implements Lifecycle: create: start: stop: delete: Node Implementation Instance of
  • 19.
    Types and Nodes Frontend_host Host Instanceof Portable Blueprint OpenStack Host Implementing Nova Plugin Uses Lifecycle Interface defines Implementing Lifecycle: create: nova_provisioner.create start: nova_provisioner.start stop: nova_provisioner.stop delete: nova_provisioner.delete Lifecycle: create: start: stop: delete: Concrete Types My_OpenStack_Ho st Instance of
  • 20.
    Relationships Node in TopologyNode in Topology Node in Topology Connnected_to Hosted_on Relationship Interface defines source_interfaces: cloudify.interfaces.relationship_lifecycle: - preconfigure - postconfigure - establish - unlink target_interfaces: cloudify.interfaces.relationship_lifecycle: - preconfigure - postconfigure
  • 21.
    Relationships Host Network Tomcat Connnected_to Hosted_on Relationship Interface defines source_interfaces: cloudify.interfaces.relationship_lifecycle: -preconfigure - postconfigure - establish - unlink target_interfaces: cloudify.interfaces.relationship_lifecycle: - preconfigure - postconfigure
  • 22.
  • 23.
    Properties Frontend_host Host Instance of Portable Blueprint OpenStackHost Implementing Concrete Types My_OpenStack_Ho st Instance of Memory Size Memory size = 2GB Image_Id=1235 Properties schema Property values Generic Properties Schema Image Id
  • 24.
    Policies TOSCA 1.0didn’t elaborate much on policies TOSCA 2.0 (draft) discusses specific DSL for specific policies such as SLA of a Node Out take: Policies are imperative
  • 25.
    Workflows TOSCA 1.0– Workflows (Plans) are in any WF language. Strong preference for BPMN 2.0 TOSCA 2.0 – No change Cloudify 3.0 take – Workflows are also tool specific, currently we use Radial (Ruby based DSL) but seeking an alternative for future versions
  • 26.
    Putting It AllTogetherTOSCA Template (Blueprint in Cloudify) contains: Application Topology Nodes Interfaces Properties Artifacts (Plugins in Cloudify) Relationships Interfaces Workflows Policies
  • 27.
  • 28.
  • 29.
  • 30.
    Proxy REST + File Server GUI Workflow Engine Task Manager Blueprint +Runtime Data Policy Engine Agent Monitoring Data Agent Monitoring Agent Application Stack Cloudify Manager App VM Invokes Reports Creates Metrics VM Logs + Events Remote Agents Agent Agent Agent Architecture
  • 31.
    Apache Server DBServer NodeJS NodeCeller MongoDB TOSCA (Like) Example • App Network • App Subnet • App Port • Security Group • Apache Floating IP • Router Gateway • Data Network • Data Subnet • Data Port • Security Group Router Monitoring, Logging CI
  • 32.
  • 33.
  • 34.
  • 35.
    References Node Cellar example https://github.com/cloudify-cosmo/cloudify-nodecellar- openstack Cloudify3 http://getcloudify.org TOSCA Overview http://www.slideshare.net/opendatacenter/forecast14-poc3- final100