Portability and interoperability relate to the ability to build systems from re-usable components that will work together “out of the box”.
A particular concern for cloud computing is cloud on-boarding – the deployment or migration of systems to a cloud service or set of cloud services. A common scenario is that some components cannot be moved to the cloud; for example, because of requirements for the enterprise to have complete control over personal data. On-boarding requires portability of those components that can be moved to the cloud, and interoperability with them of components that remain on in-house systems.
A system that involves cloud computing typically includes data, application, platform, and infrastructure components, where:
The application, platform, and infrastructure components can be as in traditional enterprise computing, or they can be cloud resources that are (respectively) software application programs (SaaS), software application platforms (PaaS), and virtual processors and data stores (IaaS).
Data, Applications, Platforms, and Infrastructure
Non-cloud systems include mainframes, minicomputers, personal computers, and mobile devices owned and used by enterprises and individuals.
Data components interoperate via application components rather than directly. There are no “data interoperability” interfaces.
Portability and interoperability of infrastructure components are achieved by hardware and virtualization architectures. The interfaces are mostly internal to the IaaS and infrastructure components shown in Data, Applications, Platforms, and Infrastructure. The interfaces exposed by these components are physical communications interfaces: these are important, but are the same as for traditional computing. For these reasons, infrastructure portability and interoperability are not discussed further in this Guide.
The main kinds of cloud computing portability to consider are data portability, application portability, and platform portability. These are the portability respectively of data, application, and platform components.
Application interoperability between SaaS services and applications, and platform interoperability between PaaS services and platforms are important kinds of cloud computing interoperability to consider.
Applications can include programs concerned with the deployment, configuration, provisioning, and operation of cloud resources. Interoperability between these programs and the cloud resource environments is important. This is management interoperability.
Applications can also include programs such as app stores (for applications), data markets (for, e.g., openly available data) and cloud catalogues (e.g., reserved capacity exchanges, cloud service catalogs) from which users can acquire software products, data and cloud services, and to which developers can publish applications, data, and cloud services. In this Guide, all such programs are referred to as marketplaces. Publication and acquisition of products is performed by platforms, including PaaS services, that interface to the marketplaces. This is the final important cloud interoperability interface.
The cloud computing portability and interoperability categories to consider are thus:
Data portability enables re-use of data components across different applications.
Suppose that an enterprise uses a SaaS product for Customer Relations Management (CRM), for example, and the commercial terms for use of that product become unattractive compared with other SaaS products or with use of an in-house CRM solution. The customer data held by the SaaS product may be crucial to the enterprise's operation. How easy will it be to move that data to another CRM solution?
In many cases, it will be very difficult. The structure of the data is often designed to fit a particular form of application processing, and a significant transformation is needed to produce data that can be handled by a different product.
This is no different from the difficulty of moving data between different products in a traditional environment. But, in a traditional environment, the customer is more often able to do nothing; to stay with an old version of a product, for example, rather than upgrading to a newer, more expensive one. With SaaS, the vendor can more easily force the customer to pay more or lose the service altogether.
Cloud introduces no new technical problems, but its different commercial arrangements can make the old technical problems much more serious.
Application portability enables the re-use of application components across cloud PaaS services and traditional computing platforms.
Suppose that an enterprise has an application built on a particular cloud PaaS service and, for cost, performance, or other reasons, wishes to move it to another PaaS service or to in-house systems. How easy will this be?
If the application uses features that are specific to the platform, or if the platform interface is non-standard, then it will not be easy.
Application portability requires a standard interface exposed by the supporting platform. As discussed under Application Interoperability, this must enable the application to use the service discovery and information communication protocols implemented by the platform, as well as providing access to the platform capabilities that support the application directly. On a cloud PaaS platform, or a platform running on a cloud IaaS service, it may also enable applications to manage the underlying resources.
A particular application portability issue that arises with cloud computing is portability between development and operational environments. Cloud PaaS is particularly attractive for development environments from a financial perspective, because it avoids the need for investment in expensive systems that will be unused once the development is complete. But, where a different environment is to be used at run time – either on in-house systems or on different cloud services – it is essential that the applications can be moved unchanged between the two environments. Cloud computing is bringing development and operations closer together, and indeed increasingly leading to the two being integrated as devops. This can only work if the same environment is used for development and operation, or if there is application portability between development and operation environments.
There are two kinds of platform portability:
The UNIX operating system provides an example of platform source portability. It is mostly written in the C programming language, and can be implemented on different hardware by re-compiling it and re-writing a few small hardware-dependent sections that are not coded in C. Some other operating systems can be ported in a similar way. This is the traditional approach to platform portability. It enables applications portability because applications that use the standard operating system interface can similarly be re-compiled and run on systems that have different hardware. It is illustrated in Platform Source Portability.
Platform Source Portability
Machine image portability gives enterprises and application vendors a new way of achieving applications portability, by bundling the application with its platform and porting the resulting bundle, as illustrated in Machine Image Portability. It requires a standard program representation that can be deployed in different IaaS use environments.
Machine Image Portability
Application interoperability is interoperability between application components deployed as SaaS, as applications using PaaS, as applications on platforms using IaaS, in a traditional enterprise IT environment, or on client devices. An application component may be a complete monolithic application, or a part of a distributed application.
Interoperability is required, not just between different components, but between identical components running in different clouds. For example, in a hybrid cloud solution, an application component may be deployed in a private cloud, with provision for a copy to be run in a public cloud to handle traffic peaks. The two components must work together.
Data synchronization is a particular issue when components in different clouds or internal resources work together, whether or not they are identical. Such components often keep copies of the same data, and these copies must be maintained in a consistent state. Communication between clouds typically has a high latency, which makes synchronization difficult. Also, the two clouds may have different access control regimes, complicating the task of moving data between them. The design approach must address:
Full interoperability includes dynamic discovery and composition: the ability to discover instances of application components, and combine them with other application component instances, at run time.
Cloud SaaS gives enterprises the possibility of acquiring new application capabilities quickly and easily, but much of the benefit of this is lost if costly integration work is needed to make the SaaS service interoperate with other applications and services that the enterprise uses.
Application components typically intercommunicate by invoking their respective platforms, which implement the necessary communications protocols. Protocol standards enable platform interoperability directly and are discussed under that heading. They are indirect enablers of application interoperability.
Application interoperability requires more than communications protocols. It requires that the interoperating applications share common process and data models. These are not appropriate subjects for generic standards, although there are specific standards for some particular applications and business areas.
There are, however, some design principles that improve application interoperability. Integration of applications designed following these principles still requires some effort, but is much less difficult and expensive than integration of applications that do not follow them.
Platform interoperability is interoperability between platform components, which may be deployed as PaaS, as platforms on IaaS, in a traditional enterprise IT environment, or on client devices.
Platform interoperability requires standard protocols for service discovery and information exchange. As discussed above, these indirectly enable interoperability of the applications that use the platforms. Application interoperability cannot be achieved without platform interoperability.
Service discovery is currently used by a minority of applications, but is essential to achieve the highest levels of service integration maturity [OSIMM]. Standard service discovery protocols should be supported by platforms used by service registries and other applications.
Protocols for information exchange between platforms should support the establishment of sessions and transfer of session information, as well as information transport. (In the case of IaaS, the platform in question is not part of the infrastructure service but implemented on top of it.) Session information might, for example, include the user’s identity, the authorization level established by the user for access control purposes, the user’s time-zone, the user’s language, and the user’s preferred cultural environment.
Management interoperability is interoperability between cloud services (SaaS, PaaS, or IaaS) and programs concerned with the implementation of on-demand self-service.
As cloud computing grows, enterprises will want to manage cloud services together with their in-house systems, using generic off-the-shelf systems management products. This can only be achieved if cloud services have standard interfaces.
These interoperability interfaces may provide the same functionality as the management interfaces mentioned under Application Portability.
Publication and acquisition interoperability is interoperability between platforms, including cloud PaaS services, and marketplaces (including app stores).
Cloud service providers often maintain marketplaces from which their cloud services can be obtained. Some also make associated components available. For example, an IaaS supplier may make available machine images that run on its infrastructure services. Some large user organizations, including governments, maintain app stores to which approved suppliers can publish programs, which can then be downloaded by the organization’s departments. Some mobile device suppliers maintain app stores from which users can obtain apps to run on their devices.
Standard interfaces to these stores would lower the cost of cloud computing for software providers and users.