Build a multi-cloud application with these 4 tips
A multi-cloud architecture is often more aspirational than practical, but it's doable if you plan ahead. Follow these tips to learn when and how to build apps to span multiple public clouds.
Two forces typically drive discussions around multi-cloud: freedom to choose the cloud tools and platforms an organization wants and the complexity that comes with those choices.
It isn't always easy, but organizations have multiple ways to build an IT architecture that provides consistency across environments and staves off vendor lock-in. Follow these tips for advice on how to build a multi-cloud application and to understand when it isn't worth the effort.
Consider these factors before you build a multi-cloud application
Outages happen, prices change and relationships with vendors fall apart. Whatever the reason, sometimes, organizations want to build their apps so they can move code when and where they see fit.
However, writing cloud-agnostic code involves more than just the avoidance of a platform-specific tool. Here are four factors to keep in mind when building an app that can live on multiple clouds:
- Don't include sensitive information, such as passwords and API keys, within source code.
- Provide a single point of entry for applications. To minimize point-of-failure risks, use round-robin domain name system records to distribute load across cloud providers.
- Automate as much as possible to minimize complexity.
- Don't completely rule out native tools. A cloud vendor may have a truly unique, worthwhile service, or the cost to avoid using a particular tool may be greater than the risk of vendor lock-in.
Think about when and how to plan for portability
The more an organization optimizes its workloads for a particular cloud, the harder it is to move those apps later. If IT teams want portability, they need to understand the implications of the services they use and how that may anchor an app to a given platform.
For example, cloud providers push for feature parity with their rivals, but that doesn't necessarily make it easier to migrate workloads between platforms. Even if two providers have comparable services, they're delivered through different APIs. Developers will need to rewrite components to work on other clouds.
Still, portability isn't a cure-all. In fact, it can be more cost-efficient in the long run to find the right platform fit for a workload, even if the base costs are higher. And if an enterprise has deeply interconnected applications, it's probably best to host them within its own data center to limit traffic fees, integrations and security concerns.
Overcome platform differences
Organizations that deploy a multi-cloud strategy need to compensate for the fact that application deployments are executed differently in different clouds. Enterprises can accomplish this by restricting scaling to one cloud, running parallel deployments in different clouds or abstracting certain components.
Organizations take a scale-and-redeploy approach if they homogenize their deployments using software, such as Apache Mesos or Kubernetes, to abstract the application plane or using DevOps tools, such as Ansible, Chef or Puppet.
Running parallel deployments is similar to the scale-and-redeploy method, but transactions and other tasks are shared. This will require a load balancer between duplicate app components, but there's no need for special deployment techniques since only the work is moved between platforms.
When app components need to scale or fail over across clouds, IT teams can use a sort of private middleware based on the adapter design pattern. This will pull the disparate cloud provider APIs into a single API that can then be used by developers. If providers' services differ beyond that, create a higher-level abstraction to map your organization's API to the specific features in each cloud.
Simplify the CI/CD pipeline
A provider-agnostic CI/CD pipeline can ease the deployment process for a multi-cloud application, and IT teams have several options if they choose to go this route.
The Secure File Transfer Protocol is supported by most cloud vendors. Though it's prone to errors, developers can use it to swap, update or remove endpoints while maintaining the nature of the deployment.
IT teams can also use containers to centralize an application build and avoid deploying the entire application code in multiple environments. An application image can be saved to a container repository that's accessible to any cloud, and developers can use a given provider's orchestration tools to launch the app image.
If you still want to use some cloud-native services, there are other tricks to get around dependency distribution, though they may lessen portability and add complexity. For example, if only one of your providers has a tool to upload content delivery network assets, make sure you use that cloud to upload content to that CDN every time, even if the target is another cloud.
Regardless of the approach, you also must identify post-deployment tasks that will run in each environment in order to balance the load across clouds. Again, more clouds add more complexity, so be mindful of which hosted features an application relies on and how that will require additional pipeline customization.
