Sergey Nivens - Fotolia
Design a cloud application with portability in mind
Writing apps for easier portability between clouds takes some work and comes with tradeoffs. Yet, the effort required to design a portable app can pay off in the long run.
Organizations that prioritize a multi-cloud strategy want the ability to lift and shift an app from one cloud to another, or even run that app on multiple clouds at the same time. But this is difficult to achieve if application portability isn't a priority from the start.
Organizations adopt a multi-cloud strategy for several reasons, including concerns about vendor lock-in or data residency requirements. It's not for everyone, since it requires IT teams to take extra steps to abstract workloads. They also must forgo many of the native tools that simplify cloud deployments.
Still, enterprises are increasingly pursuing multi-cloud strategies, despite the challenges. If your company is in that camp, explore the following techniques so you can design your cloud application with portability in mind.
Choose the right programming language
For starters, make sure all your hosting environments support the language you plan to use for your application. Most of the time, the language it's written in won't matter in terms of application portability. For example, if your app is deployed using self-provisioned, cloud-based VMs, you have the freedom to configure the VMs to support any language you want.
However, other deployment strategies may limit your choice of programming languages. For instance, serverless platforms like AWS Lambda or Microsoft Azure Functions don't let users make significant changes to the host environment. These services only support apps that are written in certain languages, and not all clouds support the same ones.
Thus, if you use serverless functions or think you might in the future, it would be better to select a language that is supported on all major serverless platforms -- such as Python, C# or Java.
Containerize your app
Developers can also use containers to help optimize application portability in the cloud. Software container frameworks, such as Docker, don't totally abstract apps away from host environments. The major limitation, in this respect, is that a Linux container can only run on a Linux host and a Windows container only runs on Windows.
Nonetheless, containers make many of the other variables in the application hosting environment irrelevant. The particular Linux distribution or Windows version used doesn't matter, as long as it supports your container framework.
Containers don't bother with variables like where data is stored, as long as they have a way to access it. Consequently, it's relatively easy to lift and shift a containerized app from one cloud to another or to an on-premises environment.
When it comes to running containers in the cloud, you don't have to worry too much about the specifics of the environments you're dealing with. As long as they support whichever container framework you choose, you're good to go.
Use a unified cloud API
Another common conundrum that arises when you design a cloud app for portability is whether to use a particular cloud's native APIs. Usually, the native APIs are the easiest way to add functionality to your app. However, the downside is that when you write an app in this way, that portion of your app needs to be rewritten before it can move to a different cloud.
One way to circumvent this is to avoid using APIs altogether. However, that's not practical or desirable for most enterprises. A better approach is to use a unified cloud API, such as Apache Libcloud or Kloudless.
These tools essentially serve as abstraction layers. Your applications issue requests and the unified API forwards the requests to whichever cloud you're using. This way, you only write API calls once.
Unfortunately, unified APIs have limited functionality. They only support certain languages and there is no guarantee they will always work seamlessly. If a cloud provider changes its native API without warning, a unified API may no longer be able to support it.
Therefore, it may not be the best idea to make your entire app dependent on a unified API. Instead, take advantage of unified cloud APIs for the parts of your app where you can tolerate some risk of disruption. This won't solve everything, but it will reduce the effort required to port the app to a different cloud.
Use infrastructure as code for cloud app deployment
Infrastructure as code refers to the practice of writing files to define how a software environment or application should be deployed or configured. Those tools are then used to automatically create the specified configurations.
When it comes to deploying apps to the cloud, many third-party infrastructure-as-code tools, such as Terraform, Chef or Puppet, are relatively cloud-agnostic. In other words, they can take one configuration and use it -- with some minor tweaks -- on any major public cloud.
Thus, by adopting infrastructure-as-code tools to automate application deployment, you simplify the process of moving your app from one cloud to another. Infrastructure as code won't make your application more portable by itself, but it will make the deployment process more portable, which adds up to greater portability overall.
Of course, migrating an application from one cloud to another will almost always require some reconfiguration and tweaking. There is no such thing as a completely cloud-agnostic, 100% portable app.
It's easier to put in extra work upfront to guarantee application portability than it is to rewrite large portions of the app down the line. And the mere knowledge that you can move easily to a different cloud lends a degree of agility to your business that is highly valuable -- especially when cloud vendor's offerings constantly evolve.
