OpenStack Heat and OASIS TOSCA
Open Source and Open Standards working together

Genesis of a partnership…

I recall sitting at a lunch table, over a year ago at the OpenStack Summit in Hong Kong, with many of the Heat core developers discussing their ideas for developing the Heat-native HOT language. They were interested in hearing more about TOSCA since it was an open standard, had an impressive community of support and completed open source implementations; however, to them at that point, it was just a clunky XML standard that did not mesh well with the Heat world.

TOSCA “in YAML” unveiled…

I gladly pulled out my laptop and showed them the very first draft of the TOSCA Simple Profile in YAML specification. Immediately, they seemed impressed that TOSCA had evolved so far, so fast towards something that could work hand-in-hand with the HOT language and be Heat developer-friendly. It was apparent that TOSCA could describe application components and relationships above OpenStack using abstractions of the Cloud IaaS resources that Heat was already focused on orchestrating using OpenStack services. In other words, Heat and HOT would take care of understanding how to best orchestrate the OpenStack IaaS resources and TOSCA could worry about everything else. The pieces fell into place, a partnership begun and a roadmap for a TOSCA Heat-Translator open-source implementation of TOSCA YAML was embarked upon.

That brings us to today…

The OASIS Topology Orchestration for Cloud Applications (TOSCA) TC is poised to release its final Committee Specification Draft (CSD) towards having the TOSCA Simple Profile in YAML v1.0 specification become an official OASIS standard. It now seems a good time to share how far we have come, share some of the YAML innovations and hint at where TOSCA is going soon. To that end, this blog entry officially “kicks off” what will be the first in a series that TOSCA articles that explore modeling different areas and features of the TOSCA and shows how different types of applications (IaaS, PaaS, etc.) can be easily modeled using other open source technologies.

Some TOSCA topic areas in this series will cover in future blog articles:

  • The basics of modeling declarative IaaS applications in TOSCA including normative types, lifecycle and policies.
  • How TOSCA’s expression of Requirements and Capabilities allows decoupling of application from platform.
  • Modeling and composing PaaS Containers with Docker examples including repository integration.
  • Describing logical public and private network models in TOSCA using OpenStack Neutron
  • How (Open) Network Functions Virtualization (NFV) can map and use TOSCA models.
  • Integrating TOSCA with Service catalogs to dynamically compose and orchestrate on-demand.
  • Associating Performance, Placement and Scaling policies to TOSCA models and monitoring them.
  • and more!
Let’s start by describing some of TOSCA Simple Profile’s essential tenants and goals…

Keep it simple for application developers…

  • Provides a simplified, developer-friendly representation of TOSCA in YAML and introduces normative node definitions for most well-established software components (e.g., Web Servers, Databases, etc.), as well as definitions for modeling Cloud infrastructure components (e.g., Compute, Networking and Storage). It also provides a normative way to relate these components using the concepts of Containment (i.e., HostedOn), Connectivity (i.e., ConnectsTo) and general Dependencies (i.e., DependsOn). This new version will assure Cloud application portability on any TOSCA-enabled IaaS or PaaS platforms.

Only what the developer needs to model…

  • Reduce the TOSCA grammar and semantics so developers quickly become able to hand code application templates. Do NOT require application developers to have to model any part of their infrastructure or platform (abstract IaaS and PaaS for them) and force TOSCA orchestrators to “do the heavy lifting” of mapping these abstractions to their specific platform or API. However, for some developers, still provide the ability to model the actual IaaS and PaaS platform itself, perhaps to try out, stand up and manage different platform implementations. TOSCA even can be used to model and orchestrate underlying logical and physical networks and storage for those extreme developers if really needed. More on that later… The beauty of it all is that TOSCA can be used at any layer without any dependencies from one layer to another.

Composability and reuse…

  • Enables the interoperable modeling/description of applications as patterns comprised of composable software components, called “nodes”, along with their “relationships”, dependencies, requirements, capabilities, policies and artifacts. These are wired together to form reusable topologies of services, subsystems and entire
    applications each of which can be packaged inside TOSCA Service Templates for cataloging and reuse.

TOSCA application templates are Portable…
  • Most importantly, TOSCA patterns and normative types enable portability and automated management across cloud providers regardless of the underlying cloud platform or infrastructure. This way TOSCA expands customer choice, improves reliability, and reduces cost and time-to-value. TOSCA accomplishes this by describing application components declaratively meaning that they describe the desired state of the application at deployment time and over its lifecycle. TOSCA orchestrators are expected to maintain the declared state while adhering to any security, placement and scaling policies that are associated with the application pattern. With TOSCA, there is no longer need for messy over-management of complex webs of software that are interdependent and fragile to updates.

Simple transparent packaging…
  • Any application or system level software pattern can be represented as TOSCA models, codified into composable TOSCA Service Templates and shared in a TOSCA defined package called a Cloud Service ARchive (or CSAR) file. CSAR files can contain all elements needed to install, deploy and manage an application over its complete lifecycle including application binaries and operational scripts.

Work with DevOps…
  • TOSCA templates and archives can be used to capture the expert knowledge of IT architects, designers, developers and testers as they contribute to an application’s configurations, policies, scripts and settings as part of its dynamic DevOps lifecycle. Companies can then choose to distribute their TOSCA application or services in these forms to their customers for direct use or for reuse in other projects. Reusable TOSCA Service Templates can quickly change from a Developer to Test to Production using different parameterized inputs or allow developers and testers to try or switch out parts of an application with different implementations or versions to see which works best.

Agnostic of scripting languages…

  • Support TOSCA applications are compatible with various scripting languages such as BASH, Chef, Puppet and others which can be referenced by the TOSCA Service Templates as TOSCA artifacts and packaged with them in TOSCA CSAR files for distribution along with any other artifacts needed for deployment or orchestration. In addition, TOSCA is being enabled to support workflows and standardized plan languages that wish to interact with the application to perform orchestration tasks that may be complex.

Capture the expert knowledge of architects, developers and testers
  • Expert knowledge at all stages of DevOps can be encapsulated in TOSCA Service Templates and within its reusable Node, Relationship and Capability Type definitions and used directly by Cloud consumers or reused as part of larger service offerings and engagements. Essentially, customers leverage settings, configurations, scripts and policies that have already been tested and optimized for services on different Clouds or platforms an included in TOSCA templates and definitions. These same configurations and policies can be further customized for any customer-specific requirements assuring full control of the TOSCA applications server placement, scaling, performance, security and monitoring when being orchestrated within TOSCA-enabled Cloud offerings. This is especially true when Clouds that leverage OpenStack and the TOSCA support in the Heat orchestration service.

Still working hard…

I can vouch, first-hand that the TOSCA membership and the Heat-Translator team are really trying to deliver a well-designed yet simple modeling and orchestration standard that developers and companies can rely upon. One that will support them when creating applications for any delivery model (IaaS, PaaS, SaaS), for any provider while supporting the complete choice to usee whatever implementations or languages you want to use or try out (e.g., frameworks, runtimes, scripting, tooling). I hope that by reading upcoming blogs on various aspects of TOSCA, your appreciation for the hard work of its working groups and the TOSCA open source development communities will grow.

Here are some other helpful resources you can use to learn more about TOSCA


A round of thanks…

This open-open collaboration would not be possible without the support and review of Heat cores including: Steve Baker, Zane Bitter, Steve Hardy, Angus Salkeld and Thomas Spatzier along with the growing Heat-Translator developer community; most notably Sahdev Zala, Ton Ngo, Simeon Monov, Vahid Hashemian, Idan Moyal, Victor Hu, Xie Junan, Feihu Jiang and Srinivas Tadepalli.

1 comment on"TOSCA’s Simple Profile poised to take Cloud Orchestration to the next level"

  1. David M. Karr February 05, 2016

    (look up the definition of “tenet” vs. “tenant”.)

Join The Discussion

Your email address will not be published. Required fields are marked *