Skip the navigation

Cloud interoperability: Problems and best practices

By Bill Claybrook
June 1, 2011 06:00 AM ET

Lock-in is the worst at the platform level, Pemmaraju says. "We are already seeing different vertical platform-as-a-service stacks that are popping up all over the place and each is incompatible with the other."

Operating system versions and hypervisor versions that do not match can produce conflicts that may not be easy to resolve. Cloud providers define the relationships between servers and storage, imposing constraints on each that perhaps did not exist with the original application. The application may have been architected to utilize certain storage technologies to achieve performance goals --- storage technologies that the target cloud does not employ.

Almost every cloud has a unique infrastructure for providing network services between servers and applications and servers and storage. Differences are likely in network addressing, directory services, firewalls, routers, switches, identity services, naming services and other resources. Target cloud providers are almost certainly going to have a network architecture that differs from the source cloud network architecture. One reason for this is their desire to support multi-tenant environments.

Cloud providers make their own choices about security policies: who has access to what resources, rules for updating software, policies for using data and disks, and so on. Application users and owners usually have little choice in cloud security matters. Applications need to operate within certain security zones, and cloud providers may not support the same security zones, or they may make changes that disrupt the security requirements of the application.

Familiar management tools found in the source cloud are often unavailable in the target cloud or only work in a limited fashion. Differences in drivers, tools, operating system configuration or version all play a role here. Software update tools used in the source cloud will have to be adapted to the target cloud. Encryption key management must be part of the bridge between the source cloud and the target cloud, and care must be taken in managing the encryption keys in the target cloud.

Gartner's Skorupa explains that even if cloud interoperability issues get resolved over time, moving large data sets between clouds will still be an issue because of latency problems and because of the time required to move the data. When you move an application, you usually have to move the storage along with it.

Products such as Xsigo's I/O Director go a long way toward facilitating the movement of data and applications from host to host within a single cloud, but there's nothing like it yet for resolving the storage movement problem for applications across clouds.

Tony Iams, an analyst at Ideas International Ltd., an IT research firm, says that when a lot of people investigate the costs of sending data back and forth between clouds, they often don't like the answer.

Migrating an application from cloud to cloud means separating it from the ecosystem that it had originally. You have to figure out if this is okay. You may have to re-engineer the application based on the components/parts that the target cloud provides. Are you willing to rebuild the application for the target cloud so that its works as well as it did in its original form?

Rebuilding means using services that may not have been used originally or that were not available in the source application. Differences between the source and the target cloud trigger a sequence of integration issues.



Our Commenting Policies