• No products in the cart.


There can be several types of interoperability and portability issues to deal with in cloud

computing. This section introduces and explains such scenarios where interoperability and

portability issues are like the prime concerns. Different recommendations and remedies have

also been discussed to tackle these issues efficiently.

18.4.1 Scenario 1: Customer Switches the Cloud Service Provider

In this scenario (represented in Figure 18.1), consumer of a cloud service wishes to change

the service provider. This turns out to be the most crucial case among all. Depending on the

type of service, such a situation touches several issues associated both with portability and

interoperability. Portability Considerations

Changing SaaS provider means that the switching from one SaaS application to another

equivalent SaaS application. Although at SaaS level no application portability issue arises, but

data associated with those applications bring portability concerns. Data portability arises from

three aspects of data like format, extent and semantic. Ideally the format, extent and semantic

types of data should be the same for both service A and service B as shown in Figure 18.1.

While tools are going to be built or available standard tools are used to make data format

transformations, the data extent and semantic issues may stand as barrier in data portability.

At PaaS level, provider’s database may be sensitive to the format of data. In such cases, data

migration facility has to be examined to check how data is retrieved and loaded. Otherwise,

if PaaS uses any common data formats available (like XML) that can eliminate portability


IaaS, being a low level facility, does not bring any data portability issue since consumer

needs to build everything from the scratch. Data files at IaaS level come in binary or object form

and are generally stored using common formats. Hence, format of the data files is not a concern

for IaaS level porting. But, there may be some concerns regarding the volume of data files.


Switching of SaaS and PaaS providers will bring data portability concerns. Adoption of

services with standard data formats or use of some standard data format can resolve data

portability problems.

For IaaS or PaaS consumers, applications portability is of utmost importance while changing

providers. At IaaS level, the question is whether these two providers support same virtual

machines and if the virtual machine architectures are similar. A portable machine image

format like Open Virtualization Format (OVF) resolves the machine porting problem from

one provider to another.

At PaaS level, concern is about operating system and the application development

environment. The application development environment may consist of a substantial stack of

software with many APIs which are used by the application code. If machine architecture,

operating system and/or the development environment are not similar, then applications have

to be redesigned which is highly undesirable. Compatible platform elements like web server,

database server etc. boost the application portability. Otherwise, if there is any mismatch in OS

version or version of the libraries, then the redesigning is required as well. In such scenarios,

the rebuilding of the whole application code may be the simpler, less costly and rather preferred


While cloud vendors (till now) provide little scope for PaaS level application portability,

consumers’ choice towards application development environment may raise the probability

of porting their application to some other clouds. This is by adopting open technology-based

development environments. Such move certainly raises the number of viable alternatives.

IaaS level application portability is possible when two environments support open standard

machine packaging formats. For PaaS level application, it is open technology-based

development environment. Interoperability Considerations

For SaaS facility, the application used by consumer belongs to or delivered by the service

provider. Hence no question arises for the first provider’s (provider A) SaaS application to

be interoperable with other service provider’s (provider B) platform since switching of SaaS

service provider means switching of the SaaS application itself. The new provider will have

their own version of the SaaS applications.

But the important thing here is that the similarity of the functional interfaces of these two

SaaS applications. The interfaces may not be visually identical but for the end user the functional

familiarity is important. The other issue may arrive when the SaaS application provides

functional APIs to be used by consumer’s application. In such scenario, before switching the

service provider, consumer must check whether their own application is interoperable with

the new set of APIs provided with the new SaaS. Otherwise, if they are not interoperable, then

the implementation of any such application, using SaaS APIs, needs to be changed.

For consumers of PaaS and IaaS facilities, switching providers does not bring functional

interface-related concerns (like SaaS consumers) since consumers in these cases are supposed

to use their own (existing) applications over the new cloud facility. At this level, the main 314

Cloud Computing

concern arises regarding the APIs those are used by consumer’s applications. Provider-supplied

APIs should be interoperable with consumer’s applications. In PaaS level application porting,

adoption of open technology-based application development environment helps to raise the


The interoperability concerns for SaaS, PaaS or IaaS level application porting to other cloud

environment arises due to API interoperability issues.

18.4.2 Scenario 2: Customer Uses Cloud Services from Multiple

Providers Concurrently

Under this scenario (represented in Figure 18.2), there can be two cases. First one, where

consumer uses two services of different providers having equivalent functionalities. This

is done to increase flexibility in case one of the providers would face some kind of service

disruptions. Second one, where two services are to serve different functionalities. This happens

since different providers can have expertise on different functional areas and consumer always

wants the best service for each required functionalities.

Under this circumstance, all of the recommendations made in Scenario 1 above remain

valid. The additional issues are discussed in the following section. Portability Considerations

Data portability in case of equivalent SaaS facilities can be a critical issue since these two

services may have to work on same set of data by maintaining duplicate copies through import/

export. Even in cases where two SaaS services are not equivalent in functionality, there may

arise the need of extracting data from one service to be used by the other service. In such

cases, if two providers do not maintain data in same format, extent and semantics, the cloud

consumers are left with one option only. Data transformation is the only solution in order to

use both cloud services successfully.

SaaS offering with standard APIs and data formats can resolve portability and interoperability

issues in cloud computing.

Data portability in IaaS level is of least concern as IaaS service consumers have full control over

their data format and use of common data format can resolve the issue there. At PaaS level,

data portability depends on the database technologies used by two service providers. In case of

different database technologies, data transformation tools may come handy


Application portability concern appears at PaaS level when same application is to be run

on both of the platforms. Consumer then would like to deploy same application codes on

both platforms. In that case, both service platforms should have support for the technology by

which the application is made of. However, PaaS level application portability concern may also

arise even in case of different applications are to run on the platforms but customer wants to

maintain those using same technology.

At IaaS level, the application portability concerns are less, since customer gets full freedom

(in terms of choice of technology) for building applications over it. Only thing is both of the

service providers must provide similar virtual machines. Interoperability Considerations

When both of the services deal with equivalent functionalities, it is likely that same customer

components will interact with those services. In that case, both services must have same or

interoperable interfaces. Otherwise, customer components will have to be modified to operate

with both of the services which is not an ideal situation. But, when two services deal with

different functionalities, need of interoperable interfaces decreases depending on their degree

of dissimilarity.

18.4.3 Scenario 3: Customer Links One Cloud Service to Another Cloud Service

It is also possible to directly link one cloud service with another. In such scenario, one service

uses the other service. Such combination is very effective as different vendors may not provide

equivalent capabilities on all of the levels of services. Then, the combination of capable services

from different providers delivers more effectiveness.

The scenario can be illustrated using a simple example (represented in Figure 18.3). Let a

customer is familiar to work under PaaS facility of provider B. But provider A offers a SaaS facility

that fulfills maximum of the customers’ business needs. Only few advance functionalities for

analyzing data are required. Then the customer has the option of separately developing those

remaining necessary functionalities and integrating them with the SaaS. The customer develop


the additional capabilities by using PaaS service of provider B whereas the newly-developed

components can consume data from the SaaS application of A, analyze the data to produce

additional statistics and return the result to the SaaS. After integrating these components into

the SaaS, the end product is a customized SaaS application running on cloud service A that gets

additional statistics from the developed solution over the services of provider B. Portability Considerations

Under this scenario, portability issue does not arise as no entity is effectively being transferred

from one cloud service to another. Interoperability Considerations

If first cloud service (service A) is either an IaaS or a PaaS, and the application is developed by

the consumer then it is likely that the user has had the full control over the application codes.

Thus it becomes easier to utilize the APIs of the second cloud service.

The situation becomes complex when the first cloud service (service A) is a SaaS offering.

Then the application is not developed by the customer and to use the APIs of the second cloud

service (Service B) the SaaS application must be properly structured. This implementation is

generally possible when standardized APIs are used in the applications of both providers and


Same can be said about the second cloud service. If it is IaaS or PaaS, user will have full

control on the APIs to use. If it is SaaS, APIs are directed by the service provider and uses of

standardized APIs are essential for interoperability. The use of service-oriented architectural

approach in cloud service development eases interoperability issue while integrating services

of different cloud vendors.

Services developed following SOA paradigm enables interoperability.

18.4.4 Scenario 4: Customer Links In-house Capabilities with Cloud Services

Capacity of in-house computing facilities can be enhanced by linking it with some cloud service.

In such scenario, interoperability is the concern as the important thing here is to establish the

connections between existing on-premises applications and new cloud deployments. Like any

other computing integration (as discussed in previous scenarios), other two aspects as data

integration and functionality/process integration are also necessary to deal with in this case.

In the integration process, at first, on-premises functionalities and data will have to be

clearly identified. Then same has to be done for the cloud end. For each of these functions and

data sources, there must be a well-defined API in place that can be utilized remotely. For SaaS

facilities, the API descriptions are most important since cloud part is fully controlled by the

provider. The integration effort reduces significantly when both of the on-premises applications

and cloud services leverage SOA techniques. Otherwise, integration requires redesigning of


In case of PaaS, the integration effort reduces since the customers tend to control most of

the integration requirements. In IaaS, the effort is least as platform services and applications

which will run in the cloud service are controlled by the customer.

Template Design © VibeThemes. All rights reserved.