TOSCA (Topology and Orchestration Specification for Cloud Applications) is an emerging standard for modeling complete application stacks and automating their deployment and management. It’s been discussed in the context of OpenStack for quite some time, mostly around Heat. In this session we’ll discuss what TOSCA is all about, why it makes sense in the context of OpenStack, and how we can take it farther up the stack to handle complete applications, both during and after deployment, on top of OpenStack.
3. Large Parts Are Mostly Manual
Measure performance
against expected SLA’s
Set and tune Alerts
thresholds
Match Policy to
Incident
Real Time
Analytics
Send
Metrics
Correlate
with
Historical
Events
Collect and Analyze
Logs
Troubleshoot
Execute
Policy
Feedback
Setup Monitoring and
Alerts
Deploy and Configure
Applications
Setup
Machine, Network, Sto
rage
Push updates
4. 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
7. The Solution
Challenges
Solution: Automation &
Orchestration
• 80%
• Remove Manual
Intervention out of
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)
the application deployment
process
• Reduce
Complexity and
Dynamically align to the
business needs
8. Automating The Application Deployment
Real Time Analytics
Real Time
Analytics
Cloud Infrastructure
Send
Metrics
Correlate
with
Historical
Events
Execute
Policy
Scale
Feedback
Failover
Deploy
Historical data
Intelligent Orchestration
10. What is
TOSCA?
• Topology &
Orchestration
Specification of
Cloud Application
• By OASIS –
Sponsored by IBM,
CA, Rackspace,
RedHat, Huawei and
others
11. What is
TOSCA?
• Goal: cross
cloud, cross tools
orchestration of
applications on the
Cloud
• Status:
– Version 1 approved (XML )
– Version 2 (YAML!) in design
12. • Standard
• Can Describe
Why TOSCA?
– Any Topology
– Any Automation
Process
• Portable between
Clouds and Tools
16. • An application topology
• 3 layers
What
We’ve
Seen
– Infrastructure (Cloud or DC objects)
– Platform or Middleware (App
containers)
– Application modules, schemas and
configurations
• Relationships between
components:
– What’s hosted on what or installed
on what
– What’s connected to what
17. 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
25. 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
– Policies are NOT in YAML and are
tool dependent (we’re using
Riemann.io)
26. • TOSCA 1.0 – Workflows
(Plans) are in any WF
language.
– Strong preference for BPMN 2.0
Workflows
• 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
27. • TOSCA Template
(Blueprint in Cloudify)
contains:
Putting It All
Together
– Application Topology
• Nodes
– Interfaces
– Properties
– Artifacts (Plugins in Cloudify)
• Relationships
– Interfaces
– Workflows
– Policies
35. References
• OASIS TOSCA
https://www.oasis-open.org/committees/tosca/
• TOSCA Session from the HK Summit
https://wiki.openstack.org/w/images/a/a1/TOSCA_in_Heat_-_20130415.pdf
• Cloudify 3.0 (AKA Cosmo) on github
https://github.com/cloudifysource/cosmo-manager
https://github.com/cloudifysource/cosmo-cli
Notes de l'éditeur
Goals:Why Workflows are critical part of automation of applications on the cloudClarify the need for something like OpsWorksWhy do we think this OpsWorks is needed in addition to other projects
A recent Gartner study projected that through 2015, “80 percent of outages impacting mission-critical services will be caused by people and process issues, and more than 50 percent of those outages will be caused by change, configuration, release integration, and handoff issues.[2].”(Ronni J. Colville and George Spafford, “Configuration Management for Virtual and Cloud Infrastructures”)
According to the AppsDynamics blog “How much does downtime cost,” the downtime expenses increased by an average of 65 percent from 2010-2012, even though the number of downtime hours per organization decreased (Figure 1) [1]. One possible explanation for this trend is that larger portions of business are being done online, making the overall impact of downtime bigger on an organization’s bottom line. With the move to cloud and Software-as-a-Servcice-based (SaaS-based) delivery models where not only customer-facing applications are exposed to online service but entire IT infrastructures, the impact of downtime could easily shut down an entire organization.
http://www.cloudcomputing-news.net/blog-hub/2013/sep/10/the-challenge-of-predicting-enterprise-cloud-computing-growth/83% of enterprises face significant roadblocks that hold them back from moving beyond cost reduction to faster time-to-market and better orchestration of their businesses. Respondents mentioned that politics, budget, time and staff are the main sources of roadblocks to getting more value out of their cloud computing investments. The majority of these roadblocks are not related to IT. They include lack of clarity regarding organization and budget (37%), resistance to change (16%) and lack of trust (visibility and reliability) (15%). The following graphic illustrates the enterprise cloud journey as defined in TheInfoPro Wave 5 Cloud Computing Study.