carloscastilla - Fotolia
Overcome app deployment challenges in a multi-cloud strategy
Looking to adopt a multi-cloud model? Be sure to address these common app deployment, redeployment and scaling challenges first.
Not all public clouds are created equal in terms of app development and deployment features -- a reality that can create a lot of challenges for those in pursuit of a multi-cloud strategy.
Difficulties especially arise when you scale or redeploy an application component onto a different cloud platform than the one on which it normally runs. This problem breaks out into two categories: deployment/management and execution. The former challenge stems from app deployment differences among the major cloud platforms -- something development teams need to resolve with agile orchestration tools and practices.
The second set of challenges is due to the differences in how cloud providers' web services work; calls to one provider's services generally won't work if the app component runs in another cloud.
There are three strategies development teams can use to accommodate this variability in a multi-cloud strategy:
- Scale and redeploy apps only within the same hosting environment.
- Implement parallel deployments in each of the cloud platforms you use to avoid scaling between them.
- Use abstraction techniques, such as the Adapter Design Pattern, to make application components more portable across hybrid and multi-clouds.
Let's take a look at each approach, along with its pros and cons.
Scale and redeploy on the same platform
In many cases, enterprises choose to host different applications on different cloud platforms because of special pricing or features. If that's the case, then scaling or failover between cloud platforms isn't necessary.
However, the big challenge in this scenario is the different deployment and scaling practices on each cloud platform. If you have a separate set of tools and procedures for each provider, you risk confusion and errors, particularly when you make changes to applications or their scaling and redeployment rules.
To avoid this, build a homogeneous deployment and scaling strategy. Two types of tools can help. First, a tool like Apache Mesos or Mesosphere DC/OS can provide an abstraction layer in a multi-cloud strategy, creating a uniform orchestration process for all platforms in use. Docker and Kubernetes recently introduced an application plane capability that offers this same benefit. Second, an enterprise could use DevOps tools, such as Ansible, Chef or Puppet, with plug-ins for each cloud platform it uses, and then define uniform processes for app deployment and scaling, which might require some additional work.
Parallel deployments
Parallel deployments are similar to the scale-and-redeploy approach above; you deploy the same component of a multi-cloud application in each cloud you use and, rather than scale or redeploy across other platforms, you share work -- such as transactions or user connection support -- between them. In this case, you handle app deployment and scaling as described above, and because nothing except work moves between the cloud platforms, no special development techniques are required to support the movement of application components.
There are some challenges, though. For example, you'll need to load balance between the duplicated application components deployed in each cloud. A VPN load balancer, such as Cloudflare, will work for internal traffic, and something like MODAClouds, a model-driven development approach, will work for general customer/user access.
Abstraction techniques
In the third scenario, application components need to scale or fail over across cloud boundaries. When those components rely on provider-native web services, developers need to align them to those services' specific APIs. To avoid having to maintain multiple versions of components -- one for each cloud you use -- create a kind of private middleware, based on the aforementioned Adapter Design Pattern. This lets you adapt cloud providers' web service APIs into a single API specification of your own design, which developers can then use.
For example, if two cloud platforms display mobile data in a slightly different way, an Adapter Design Pattern can convert a single API call that can work in either cloud, even dynamically at runtime.
However, it is possible that the provider web services you use in a multi-cloud strategy will differ beyond just their APIs. For example, some vendors will approach features like voice recognition or mobile app support in completely different ways, which means API changes may not resolve things. To overcome this, create a higher-level abstraction or a common level where you can map an API you design to a series of features in each cloud you use.
If end users' mobile devices differ in terms of how they exchange data with an application, then it might be necessary to divide your application into a functional component that's independent of providers' web services, as well as a cloud component that has to match the specific cloud in use. The cloud component might use multiple APIs from cloud providers in different ways. This is almost like writing cloud-specific middleware, but the principle of abstraction is the same.
Many developers are familiar with the notions of abstraction and middleware -- but not all. If development teams are uncomfortable with structuring applications to separate the cloud-specific components from general functionality, then it's best not to scale or fail over across cloud providers that offer different implementations of the same feature. Look into alternative approaches instead, and keep abreast of tools, particularly Kubernetes, which continue to advance rapidly.
