Are TOSCA & Cloud Standardisation Efforts REALLY Stalling?

Alan R. Earls recently wrote an article on TechTarget: TOSCA and other cloud standardization efforts stall where he pointed out the state of TOSCA as well as other cloud standardization efforts:

“TOSCA was originally designed as an open standard for formatting templates so tasks, such as cloud resource deployment and orchestration, could be translated into a generally readable form and become more portable across platforms. Overall, the standard aims to make it easier to update, extend or move cloud-based resources.
Today, Cloudify, an open source orchestration platform, uses TOSCA, and OpenStack has a few projects that use the standard, as well, such as TOSCA Parser, which can read TOSCA templates and create an in-memory graph of its nodes and their relationship. In general, though, TOSCA has been limited by its need for vendor support, said Lauren Nelson, an analyst at Forrester.”

The idea of having one common language or standard to ‘win them all’ was too ambitious. That’s true for TOSCA just as it is for any other standard modeling attempt such as ETSI. We need to accept the fact that the cloud world will be comprised of many domain-specific modeling languages and that lead to even more hybrid environments as we extend the cloud towards the edge.

Rather than trying to abstract all the cloud resources through a common standard language we need to think of how we can glue together cloud resources each with their own native domain specific language and allow more loosely coupled interoperability to enable end-to-end automation. The great power of TOSCA over other standard or modeling languages lies in its ‘extensibility’ power- this makes TOSCA a great language to enable loosely coupled interoperability.

The Cloudify Approach to Achieve Multi-Cloud Interoperability from Core to Edge with TOSCA

The original definition of TOSCA was defined a couple of years ago when cloud was still a relatively new concept. Since then the world of cloud has evolved in many domains along with TOSCA and more specifically, our use of TOSCA within Cloudify.

The direction that we have taken with Cloudify is to build on TOSCA – to use it as a foundation for creating a layer that will allow users to define an end-to-end automation blueprint that can be comprised out of a hybrid stack of domain-specific service-components. Components including configuration playbooks based on Ansible, infrastructure templates based on AWS Cloud Formation or Azure ARM and micro-services based on Helm – as noted in a previous post Driving Open Standards in a Fragmented Networking Landscape.

We refer to this approach as an Automation First approach or ‘integrate vs migrate’ where we can achieve a significantly faster path to automation by allowing users to build on service-components that have already been automated (regardless of the domain-specific language that was used to automate them).

Cloudify E2E Automation Architecture:

The diagram below describes how we can achieve this degree of end-to-end orchestration and interoperability.

Cloudify End to End Automation Architecture

There are three main components in the Cloudify architecture that allows this degree of flexibility and extensibility:

Plugins: to expose any resource as a set of TOSCA nodes. This, in turn, enables us to include this resource as part of an intent-based blueprint. A resource could also refer to external orchestration. TOSCA maps each resource into a node type that exposes that resource through a common interface that will allow another resource to define their relationship or dependency with this resource, as well as pass input/output parameters. The resource orchestrator will execute its operation via its own native format i.e. no translation is needed. The interoperability occurs by exchanging inputs and output parameters with the other TOSCA nodes in the end-to-end service automation blueprint.
Nested blueprints composition: allowing us to create a modular automation system comprised of a set of independent micro-services each described in a separate blueprint. The service orchestration can import these blueprints (compile-time composition) or simply point to an external deployment that is running as an independent service (runtime composition).
Cascading workflow execution: allowing delegation of workflows between nested blueprint as if they were all part of the same service. This will simplify the way we model cascading lifecycle operations between independent services. In addition, we added the distinction between shared and non-shared resources allowing users to control when to invoke cascading workflows such as un-install on a shared resource.

Evolving TOSCA to support Nested Blueprint Composition to Enable Modeling of new generation distributed services

The Evolution of Cloudify EnE Automation from Multi-Cloud to Edge

Cloudify 4.4 – 4.5 was a major milestone for supporting multi-cloud and hybrid stack deployment. In this update, we released a reference architecture that demonstrates many of the capabilities mentioned above. In this reference architecture we demonstrate how we can put together services running as cloud-native service,  connecting them to other services that run on top of traditional virtual machines as described in the diagram below:

Example 1: Using the enhanced TOSCA modeling to model a hybrid cloud / stack use case

We also created a live demonstration that walks through the details of how all this works. This demo shows many of the core capabilities that need to take part in this sort of multi-cloud orchestration which includes network orchestration, security, configuration and scaling. Here is the full list:

• Multiple management networks (Multi-cloud)
• Traditional VMs, containers, and Kubernetes orchestration (Hybrid-cloud & stack)
• Multi-tenancy
• Deployment proxy (Deployments as a Service)
• Global and tenant secrets
• Scaling
• Coordinated multi-cloud deployment
• Coordinated hybrid cloud deployment
• Multi-blueprint composition
• Kubernetes cluster deployment
• Templatized Kubernetes resource deployment
• Openstack compute and network orchestration
• AWS compute and network orchestration
• Cross-template/cross-cloud scaling
• MariaDB, HAProxy, Drupal, and WordPress orchestration
• Service Chaining

Cloudify 4.6 (our latest instalment) adds a significant enhancement to our nested blueprint architecture as well as adding support for Ansible and Kubespray as described in our recent 4.6 post.

Example 2: Using the enhanced TOSCA modeling to model end to end automation from core comprised out of hybrid cloud-native and non cloud-native edge services

Our partner Amartus recently demonstrated in the Cloudify 4.6 release webinar how this can be used to deliver an open cloud native SD-WAN use case as part of a use case with MEF.

Cloudify Spire (a.k.a Cloudify 5.0) will take a big step in using those concepts to build fully federated orchestration at global scale as described in this Next Generation Orchestration: Multi Domain, Sites, Clouds, Hyper Scale post. In this case, we can leverage the modularity of nested blueprints to describe a complex network of distributed services and allow a common method of controlling them from a single point of access.

In Summary:

Hybrid cloud and stack are clearly becoming the norm these days, however, the attempt to normalize the complexity of hybrid cloud through a common language was too ambitious and that’s just as true for TOSCA as it is for any other standard or framework. Instead, we need to accept the fact that the world will be comprised out of multi-domain resources of different kinds that are mapped into different languages that are more specific to the domain in which they are operating. This becomes more apparent as we move closer to the edge.

The move to cloud native and Kubernetes as the de-facto multi-cloud application platform greatly simplifies the complexity of building a hybrid cloud deployment; but as we move toward a more distributed architecture from core to edge, we basically move to a more hybrid stack environment – namely a hybrid stack comprised of many Kubernetes clusters as well as other external resources that live outside of our own Kubernetes clusters. These resources could be serverless, legacy systems and devices, or other third party systems that we need to interface with but don’t have full control over.
To achieve end-to-end automation in such a hybrid environment we need to think of interoperability at a higher layer of the stack in which Kubernetes becomes one of the main endpoints but not the only one.
The extensibility of TOSCA as a language makes it a good foundation for this sort of interoperability.

Cloudify has evolved its original TOSCA support through a rich set of plugins that allows us to integrate and glue together cloud-native services based on Kubernetes with non-Kubernetes services. This allows us to define an end-to-end automation scheme that works across the entire stack. In addition, we added more modularity to the way we can describe and segment complex systems both during the design and runtime phase. All this serves as a key foundation that allows us to take the next jump towards simplifying the modeling of highly distributed network systems such as vCPE and SD-WAN using intent-based modeling abstraction.

TOSCA as a ‘standard’ (in the sense that SQL is a standard ) is misguided. TOSCA is a meta-language for defining declarative ‘DSLs’. It has some shortcomings that Cloudify is addressing outside of the standard, but it’s the best current path towards a future of true intent based automation/orchestration. So while the standard activity under OASIS has been slow, TOSCA based DSL continues to evolve under the open source community.