Karen,
Thank you for the comments from ODCA. I acknowledge receipt of the below as TOSCA TC Co-Chair. Please be assured that the TC will carefully consider these comments.
Regards,
Paul Lipton
From: tosca-comment@lists.oasis-open.org [mailto:tosca-comment@lists.oasis-open.org]
On Behalf Of Keehan, Karen A
Sent: Friday, January 11, 2013 7:17 PM
To: tosca-comment@lists.oasis-open.org
Cc: Giri, Ravi A; Chet Ensign; Ryan Skipp; Spence, Catherine
Subject: [tosca-comment] ODCA feedback on TOSCA TC
The following is feedback from ODCA based on ODCA Usage Models (UMs). The comparison(s) are against the ODCA requirements in ‘Interop Across Clouds’, ‘Service Orchestration’ and ‘VM Interoperability’ documents
which can be accessed
here along with the rest of our UMs.
|
|
ODCA [Manageability | CIaaS | Services] WG
|
OASIS TOSCA
|
|
Audience
|
Cloud Consumers
|
Cloud Service Providers
|
|
Focus
|
Logical Cloud 'layers' - IaaS, PaaS, SaaS
|
Agnostic to Cloud Layers, applies to generic 'services'
|
|
Inter-operability
|
Portability & Interconnect-ability are the 2 two elements that define interoperability. Considerations for both of these as they apply to IaaS, PaaS and SaaS is explicitly called out in the usage models. Portability is understood to be
event driven.
|
A service defined using the templates can be hosted with any service provider that is TOSCA compliant or even across service providers. i.e., Vendor Agnostic definition, deployment, migration and management of services.
Due to the cloud provider focus, PaaS and SaaS considerations - application portability, inter-connectability between environments are not addressed
|
|
Security
|
Security WG has extensive and comprehensive details
on requirements to cover possible use cases across tiers
|
Security is no explicitly called out or indicated as a mandatory requirement.
The TOSCA template language is extensible enough to potentially allow security requirements to be defined (e.g.: using custom name/value pair attributes) but
The lack of explicit security focus is a gap.
|
|
Tiers
|
There are specific service tiers defined - Bronze, Silver, Gold
and Platinum
|
There are no tier definitions, but requirements (and capabilities) that align to the ODCA service tiers can technically be captured in the template that is used to define the service and it's components.
It would be useful to consider Bronze / Silver / Gold / Platinum impacts here
– there isn’t a
“One size fits all in this space”, especially when, public, private and hybrid models are in context of the rest of the interoperability
|
|
Service Catalog
|
ODCA has the definition of a service catalog which can be used to 'discover' services and their capabilities and serve as a broker across cloud service providers
The model seems to have a direct Cloud to Cloud relationship, whereas ODCA see the need for an intermediate Service Catalogue
– very seldom will 2 Cloud Providers directly expose their direct Cloud environments
– they would have API’s but these would use a Service Catalogue for brokering between Cloud, and this seems to be missing from the concept
It would appear a catalogue would have to be created per node, with commercial, service and technical capabilities described
– a more effective way is a central catalogue mapping all the node capabilities and topologies and dependencies, making maintenance and control of publishing easier
|
The concept of a service catalog is not called out explicitly but the service template itself can be part of the catalog and the standardization allows easier discovery of the service and it's capabilities as well as automated mapping to
expected requirements.
But, very few organization would be amenable to allowing full XML service template definitions to be available for 'discovery' - so this is limited due to security concerns
The language constructs do allow inheritance of requirements, capabilities, states and interfaces using the DerivedFrom attribute, so needing to specify a service catalog per node can be avoided
|
|
Use Cases
|
There is extensive documentation of a broad range of use cases from a cloud consumer point of view and the requirements for each of them is also captured
|
The major use cases (cloud provider specific) for TOSCA are:
1. Services as marketable entities - standardized service templates as a means of creating a 'marketplace' for 'interoperable' IT services
2.
Portability of Service Templates - Portability of a 'service' means that the service definition can be understood across vendors. i.e., service templates defining the structure and orchestration created by one vendor (service provider)
can be parsed/understood by any other vendor that is 'TOSCA compliant'.
3.
Service Composition - allows vendor agnostic composition of service. i.e., components for a service could be from any vendor and are replaceable using the service template as a layer of abstraction for vendor selection flexibility
4.
Relation to Virtual Images -the service templates allow composition of service from various virtualization technologies, or a combination of them.
|
|
Language Considerations
|
ODCA prefers RESTful interfaces / web services
|
|
Kind Regards,
Karen Keehan
Intel Corporation
| Director, Industry Collaborations, Open Data Center Alliance
(ODCA)
| 303-513-1703 mobile
| 303-993-4740 office
|