Over a million developers have joined DZone.

On the Topology and Orchestration Specification for Cloud Applications

DZone's Guide to

On the Topology and Orchestration Specification for Cloud Applications

· Cloud Zone ·
Free Resource

Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.

Recently OASIS standards body started work on the proposed Topology and Orchestration Specification for Cloud Applications (or TOSCA) for short, standards specification. The standard aims to deliver on the long-heralded, but much disputed concept of cloud bursting – the ability to move workloads between public and private infrastructure in a transparent way.

I posted about the initiative on the CloudU LinkedIn group and had a smattering of comments – many of which identified the lack of what insiders would call genuine Cloud vendors. The other common theme from people was the concern that there was more marketing hype in the announcement than any substantive depth.

According to the TOSCA site it works to;

…enhance the portability of cloud applications and services. TOSCA will enable the interoperable description of application and infrastructure cloud services, the relationships between parts of the service, and the operational behavior of these services (e.g., deploy, patch, shutdown)–independent of the supplier creating the service, and any particular cloud provider or hosting technology. TOSCA will also make it possible for higher-level operational behavior to be associated with cloud infrastructure management.

It’s a heady concept, if it actually works, TOSCA could deliver a number of benefits including;

  • Smoother migration of existing applications to the cloud
  • Flexible bursting (consumer choice)
  • Dynamic, multi-cloud provider applications

Many people have noticed the lack of large IaaS vendors on the TOSCA steering group, in a GigaOm post about the initiative, one commenter sagely points out that;

Until customers demand it, why should they [the big vendors be involved]? And they can’t demand it until we show feasibility … Thus, a standards project. This worked the same way with databases and XML export formats. It took a while for the biggest incumbents to admit that standardized export might be OK.


I like standards, and I like the idea that customers are able to shift workload between different cloud providers and between public and private. That said, it looks unlikely that any initiative will truly be able to deliver upon a hypervisor agnostic portability mechanism for a number of reasons. Firstly it’s not in the large vendor’s interests to allow for this portability and second because the technologies being utilized are sufficiently ingrained as to make the creation and adoption of a standard problematic.

In back channel discussions others mentioned the fact that TOSCA has some incumbents around the table who have a vested interest in increasing rather than reducing the complexity to ensure lock-in is enhanced and monopolies are secured. That doesn’t bode well for TOSCA to really deliver upon its goals.

TOSCA also enters the market at a time that OpenStack (see disclosure) is gaining momentum among vendors as the open source infrastructure model of choice. While many question the motives and chance for success of OpenStack, there are enough deployments from different vendors already in the wild for me to feel comfortable with it as a true initiative beyond simple marketing.

I’m prepared to cut TOSCA some slack, but would need to see some significant progress before I was happy to say that it is actually more than a loose marketing venture. I’d also want to see some reference implementations of TOSCA to assess how real this really is. Watch this space.


Source: http://www.diversity.net.nz/on-tosca-and-cloud-standards-mypov/2012/01/20/

Join us in exploring application and infrastructure changes required for running scalable, observable, and portable apps on Kubernetes.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}