Torbz - Fotolia
Application portability between platforms is one of the primary goals of a multi-cloud strategy. And while this is fairly straightforward to achieve when you only use IaaS providers' basic compute capabilities, it becomes much more difficult as you layer more provider-native services on top of that deployment.
To maintain a competitive edge, all major public cloud providers augment their basic IaaS offerings with something else -- an inventory of web services, such as those for data analytics, event processing and relational databases. Developers can write these additional services into their cloud applications to achieve a variety of tasks, including reduced development time and cost, as well as the ability to offer more specialized features.
But, although beneficial, these web services pose a risk. Cloud providers have unique implementations of these services and, even when they are similar across providers, it's difficult to take an application component that uses one implementation of a web service and insert it in another. The web service itself is not portable across different cloud platforms, which means you might lose information and create data and feature incompatibilities.
On a per-component basis, you must assume that if you use such a service, your applications will not be portable. And this limitation would apply not only across providers in a multi-cloud strategy, but also across the cloud and your own data center. You couldn't, for example, failover or scale across a hosting boundary.
Overcome incompatibility challenges
There are two kinds of web service incompatibility. The first, and least problematic, is where providers offer essentially the same service, but with different APIs. This is inconvenient, but it's not difficult to work around because it won't affect your overall application architecture.
The second, and more sinister, type of web service incompatibility is where cloud providers structure their actual service differently. Then, it's not simply a matter of making changes to the API calls -- as is the case in the first issue above -- but could require you to change your whole application design.
App design considerations for multi-cloud
Before deployment, it's important to consider how developers design their hybrid and multi-cloud applications. Most of these apps have a front end, such as GUI, and back end that consists of elements specific to a business process. In some cases, particularly those that involve microservices, it's helpful to create a boundary -- such as a message bus or message queue -- that serves as the processing point between front- and back-end components. Developers will typically use public cloud services for their front end, and perhaps do some limited failover and scaling of these boundary elements between cloud and the data center. Use this model as the basis for rethinking your multi-cloud deployments.
So, how do you work around this incompatibility issue? There are three possible solutions:
Separate app components for cloud bursting, failover
Separate any application components that you expect to cloud burst or failover to multiple clouds, and don't integrate web services with those specific components. This can be problematic, as it's common to use web services for the front-end components of applications. However, you can't make any segments of your application that rely on these web services portable or scalable across your multi-cloud deployment.
Avoid provider-specific web services
The second option is to forego cloud providers' web services entirely, in favor of generalized industry middleware that can run anywhere. For virtually every public cloud web service, there's a comparable third-party or open source product that users can host on multiple platforms. The problem, however, is that these products don't always integrate tightly with the cloud infrastructure you use, so you might have to develop your own architectural model for things like scalable web front-ends and scalable databases.
If you choose this route, look carefully at open source cloud and container technology to see if you could use a packaged implementation of OpenStack, Kubernetes or Mesos/Marathon to build your open web services toolkit. Even if the package doesn't include everything you need, it can still serve as a universal hosting framework for a multi-cloud strategy.
Use an adapter
The final option is to develop an adapter around the web services you use to make each compatible with your application. If you use a number of public cloud providers that offer a similar web service, but through a different API, you can use an Adapter Design Pattern to convert the various APIs to a single and common API that your application can then use.
This is fairly easy if the only difference in the providers' web services is in the API and data model. But if the web services have architectural differences, you might have to elevate your abstraction of them to the point where they are fully represented with a common adapter API. Be sure to explore the details of all the web service APIs associated with a given feature before you start your design.
These three strategies to minimize incompatibility issues in a multi-cloud strategy all have their place; in some cases, enterprises might want to adopt pieces of all three. In the long run, though, it's the third model of "adapting" that is likely to be your best approach. Increased competition among cloud providers, and the differences in how these providers see the future, will widen the gap between their respective web services moving forward. The most standard way to cross that gap will then prevail in the market.