Cloud computing is a major development in information technology, comparable in importance with the mainframe, the minicomputer, the microprocessor, and the Internet. It has the potential to make an increasingly significant contribution to economic activity throughout the world. This potential will only be realized if cloud computing products and services are portable and interoperable.
The Internet is one of the foundations of cloud computing, and is an excellent example of how portability and interoperability can deliver massive benefits. But cloud computing is more than the Internet. The additional cloud components that store and process information, unlike the Internet and web components that they use to communicate and display it, are generally not portable and interoperable today.
The key cloud computing portability and interoperability categories to consider are identified in the discussion of Cloud Portability and Interoperability. They are:
The Distributed Computing Reference Model identifies the components of cloud-based systems that should be portable and interoperable. The interfaces between these components are discussed in Portability and Interoperability Interfaces. Standardization of these interfaces is the first thing to consider as a means of achieving portability and interoperability. It is appropriate for some but not all of the key categories. For one category, it is appropriate for the future but not yet.
Application portability, platform interoperability, and management interoperability can, as in traditional systems, be achieved by conformance of products to software interface and protocol standards.
The platform capabilities required by modern cloud solutions are much greater than those of a traditional operating system, and the existing, well-supported operating system portability and interoperability standards are no longer sufficient. The web service protocol interface standards may be applicable, but are not necessarily appropriate. There are no standards for cloud software interfaces. A major effort is needed to define and popularize standards for cloud application portability and platform interoperability.
There are a number of initiatives to define cloud management interoperability standards. Work is needed to complete them, but what is most needed is to ensure that cloud products and services conform to them.
Data portability and application interoperability cannot generally be achieved by conformance to interface standards, because each application is different, and uses different data. Integration of applications, and porting of data between them, can, however, be more, or less, expensive, depending on how the applications are designed. Generic data model and semantic standards can also help reduce costs by enabling the use of powerful data management and semantic processing components.
There are some principles for the arrangement of application components whose adoption can improve data portability and application interoperability.
There are excellent data model standards, but new storage paradigms, requiring new standards, are emerging for cloud.
Improved understanding of semantic processing is needed for its benefits to be realized.
Publication and acquisition of products and services through marketplaces is a new aspect of interoperability that is becoming increasingly important because of cloud computing. It is too early to define effective standards for them. It is important to develop and document good practices on which future standards can be based.
This section lists recommendations in the following areas:
These recommendations will:
Platform-platform interfaces are the Internet, HTTP, and message envelope layers of web service APIs, which is the interface style of application-application interfaces, application management interfaces, platform management interfaces, infrastructure management interfaces, publication interfaces, and acquisition interfaces. A universally used standard for platform-platform interfaces would provide a major part of the basis for real cloud interoperability.
As described in Web Service Interfaces, there are two styles of web service interface handled by platforms: WS-I and raw HTTP.
Each approach has strengths for specific applications. The choice between them also depends on factors such as the integration architecture and the capabilities of the implementation team. Many small-scale integrations that originally used WS-I with SOAP and XML, because JSON was not mature enough at the time, are now moving towards raw HTTP and JSON because it is better suited to their needs. However, for enterprise-level integrations, SOAP is still king. This is illustrated in Example Use-Cases for WS-I and Raw HTTP.
|CP1||Enterprises that are architecting sets of interoperating cloud services should use WS-I as the service platform interoperability interface between those services.|
|CP2||Enterprises that are developing cloud services that will be accessed by user devices should use direct HTTP with JSON as the service platform interoperability interface.|
|SD1||The industry should identify best practice in use of direct HTTP and JSON, including means of authentication and access control (such as OAUTH), and develop standard profiles for interoperability between service platforms using this approach.|
Application-platform interfaces are programmatic interfaces exposed by platforms. Their standardization would enable portability of applications across platforms. It could also enable applications to use WS-I and direct HTTP interchangeably as platform interoperability interfaces, thus simplifying the process of application development.
There are, however, products, both commercial and open source, that implement parts of the functionality, such as Enterprise Service Buses (ESBs), and some vendor-independent interface standards for part of the functionality, such as the Java Message Service (JMS).
|CP3||Enterprises should seek to use cloud platforms with vendor-independent programming interfaces.|
|CP4||PaaS vendors stating that they support .NET or J2EE should say which versions they support.|
|SD2||A language-independent specification of a standard cloud application-platform interface should be defined. Instantiations of this should then be developed for the most widely-used programming languages.|
Human-readable service descriptions form part of publication interfaces and acquisition interfaces. Machine-readable service descriptions support dynamic service discovery and composition, and form part of platform-platform interfaces and application-platform interfaces.
There is an accepted standard for service descriptions, the Web Service Description Language (WSDL). This, however, has limitations.
There are bodies working to develop standards for service descriptions that address some of these limitations. They include the companies that support the Web Application Description Language (WADL), the Open Data Center Alliance (ODCA), the SLA@SOI Consortium, and the OASIS TOSCA Technical Committee.
|CP5||Enterprises developing services should produce clear human-readable descriptions of them, covering functional and non-functional characteristics.|
|CP6||Enterprises developing services using the WS-I approach should also produce WSDL descriptions of them.|
|CP7||Enterprises procuring services should insist on the availability of clear and stable human-readable descriptions and, for services using the WS-I approach, of WSDL descriptions.|
|SD3||The industry should work to establish best practice for human-readable service descriptions covering all service characteristics, building on the work of bodies currently active in this area.|
|SD4||The industry should work to establish standards for machine-readable service descriptions, including templates and component schemas. These standards should cover all service characteristics and parallel the human-readable descriptions. They should include or be linked to descriptions of service data models, and be applicable to services that use the direct HTTP approach as well as to those that use the WS-I approach. WSDL forms a good starting point for such standards.|
Service management interfaces enable management systems to manage cloud services. Standardization of these interfaces will enable the development of cloud management systems as commercial off-the-shelf products.
This is an active area of standardization. Initiatives include the DMTF Cloud Infrastructure Management Interface (CIMI) and Virtualization Management (VMAN) standards, the OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA), the Open Grid Forum Open Cloud Computing Interface (OCCI), and the SNIA Cloud Data Management Interface (CDMI). The Openstack APIs may also provide de facto standards.
|CP8||Enterprises developing cloud services should ensure that their management interfaces follow emerging standards where possible.|
|CP9||Enterprises procuring cloud services should look for services whose management interfaces follow emerging standards.|
|SD5||The industry should support the ongoing cloud management standardization work, including the work in the DMTF, OASIS, OGF, and SNIA, and the Openstack open source initiative.|
Standardization of data models is important for data portability and for interoperability between applications and software services.
There are schema standards for particular storage paradigms, notably for RDBMS. These do not, however, cover the new “NoSQL” paradigms that are increasingly being used in cloud computing.
Also, the schema standards do not enable correspondences between different data models to be established, and this is crucial for interoperability. The semantic web standards and the UDEF can be used to define correspondence between data models, but their application is not widely understood, and they are little used.
|CP10||Enterprises developing cloud services should describe their data models clearly, using text and applicable schema standards. The descriptions should be computer-readable and have good human-readable documentation. A well documented XML schema would achieve this, for example, but just using XML probably would not.|
|CP11||Enterprises procuring cloud services should look for clear data model descriptions.|
|SD6||The industry should establish best practice to describe correspondences between data models, should ensure that the standards in this area are fit for purpose, and should work to improve understanding of them.|
Machine image formats are an important component of download interfaces and service management interfaces. The ability to load a machine image containing an application together with its application platform onto different cloud infrastructure services is a new form of portability that is made possible by cloud computing. A standard machine image format makes portability possible across different infrastructure service providers, as well as across infrastructure services of a single provider.
The DMTF OVF standard is designed to meet the need for a machine image format standard.
|CP12||Enterprises developing cloud infrastructure services should evaluate the OVF standard and support it if feasible.|
|CP13||Enterprises developing cloud management systems should evaluate the OVF standard and support it if feasible.|
|CP14||Enterprises procuring cloud infrastructure services or cloud management systems should evaluate the OVF standard and look for support for it as appropriate.|
|SD7||The industry should work to ensure that the OVF standard is and remains fit for purpose, and to encourage its use.|
Tightly-coupled components are difficult and expensive to integrate, particularly over the lifetime of a system that undergoes change (as most do).
|CP15||Cloud application components should be loosely coupled with the application components that interact with them.|
Interoperability requires that applications are easily integrated with each other, and that information can flow freely between them, to enable Boundaryless Information Flow within and between enterprises.
Service-orientation is a simple, business-focused principle that facilitates application integration and enables Boundaryless Information Flow. Cloud offerings are packaged as services (IaaS, PaaS, SaaS). Cloud platform-platform interfaces, whether in the WS-I or raw HTTP style, assume client-server interaction. Service-orientation encompasses and reinforces other principles – loose coupling, service descriptions, and described interfaces – that are recommended in this Guide.
|CP16||Cloud applications should be service-oriented.|
The cost of integration of a component, considered over its whole lifetime, will be high if the component interfaces change frequently.
|CP17||Cloud application components should have interfaces that do not change over time, or are such that any changes are backwards-compatible.|
Components that do not have clear human-readable descriptions are hard to acquire and integrate. Components that do not have clear machine-readable descriptions are not suitable for dynamic discovery and composition.
|CP18||The interfaces to cloud application components should be clearly described. The descriptions should be human-readable and should also be machine-readable if dynamic discovery and composition is intended.|
Use of marketplaces and app stores is growing, but there are as yet no standards or established good practice for their operation. This means that product vendors must cater for the different requirements and practices of all the marketplaces in which their products appear, that customers must understand the different features of all the marketplaces that they use, and that marketplace operators are spending effort on unnecessary differentiation.
As this is a relatively new concept, standardization may be premature, but development of good practice should be encouraged.
|SD8||Industry bodies should seek to identify the best practices for marketplace operation, with a view to defining standards and working with governments on any legislation that may be needed to underpin them.|
There is a need for robust and scalable services that are loosely-coupled and have stable interfaces that are easy to describe.
|CP19||Applications should be designed using the Representational State Transfer (REST) style, though without insisting on its full rigor.|
Traditional ACID transactionality cannot be achieved at the same time as availability and fault tolerance in a partitioned system. In distributed computing systems incorporating cloud-based components, partitioning, availability, and fault tolerance are of more importance than ACID transactionality in most cases.
|CP20||Cloud applications should be designed as far as possible to perform transactions with the so-called BASE properties: Basically Available, Soft State, and Eventual Consistency.|