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.
18.4.1.1 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
concerns.
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
approach.
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.
18.4.1.2 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.
18.4.2.1 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.
18.4.2.2 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.
18.4.3.1 Portability Considerations
Under this scenario, portability issue does not arise as no entity is effectively being transferred
from one cloud service to another.
18.4.3.2 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
consumers.
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
applications.
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.
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.
18.4.1.1 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
concerns.
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
approach.
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.
18.4.1.2 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
interoperability.
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.
18.4.2.1 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.
18.4.2.2 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.
18.4.3.1 Portability Considerations
Under this scenario, portability issue does not arise as no entity is effectively being transferred
from one cloud service to another.
18.4.3.2 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
consumers.
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
applications.
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.