According to the first sentences in the spec, "This core TOSCA specification provides a language to describe service components and their relationships using a service topology, and it provides for describing the management procedures that create or modify services using orchestration processes. The combination of topology and orchestration in a Service Template describes what is needed to be preserved across deployments in different environments to enable interoperable deployment of cloud services and their management throughout the complete lifecycle (e.g. scaling, patching, monitoring, etc.) when the applications are ported over alternative cloud environments."In principle this is a good thing. I believe the future is in Infrastructure-as-Code and although this is typically associated with automation efforts as done with Chef and Puppet, I personally feel it is even better demonstrated by services such as AWS' Cloudformation.
Cloudformation allows you to declare which infrastructural components (server instances, load balancers, storage components, dns registrations etc.) you want to instantiate, including their configurations and inter-relationships. It typically operates on infrastructural level, and although it has some server configuration features (through cfn-init) it typically operates in concert with tools such as the mentioned Chef, Puppet or alternatives.
Cloudformation is great. It is massively frustrating to develop complex systems in, given to the immaturity of the development ecosystem around it (which will be resolved over time), but still I am not aware of an alternative provided by the other cloud providers that comes close.
This TOSCA standard acknowledges the importance of such provisioning tools, and aims at getting a standard in place. With the promise of preserving portability and avoid (cloud vendor) lock in. So that's great isn't it?
Yes, potentially yes. I am very happy with AWS and I really think they are by far the most feature-rich cloud provider out there, but it's always good to preserve portability. For instance, someone could have particular data requirements that simply cannot be met by AWS (e.g. data cannot leave the country), or has some kind of (Microsoft anyone?) enterprise agreement that they want to leverage in the cloud. Having a solid standard in this space could facilitate that, and could also boost the development of development tools.
The reality of course is that cloud landscape is evolving at lightning speed, and that standardisations body typically have no possiblity to keep up with that. Looking at the differences in services portfolio between cloud vendors (with AWS being the undisputed front runner in both current portfolio and development speed) it's a damn hard job to do standardisation there. Standards like this run the risk to only support the lowest common denominator, which is something not a lot of people are waiting for I'm afraid.
So I am bit torn. I must admit that I haven't studied the standard in detail yet, so maybe a lot of my concerns are already addressed, but my gut feeling says it will take a while before the (leading) cloud vendors adopt this.
