ra2 studio - Fotolia
Build a CI/CD pipeline to simplify multi-cloud deployment
While some cloud providers support simple app deployment processes and tools, they could hinder a multi-cloud model. Fortunately, there are some workarounds.
To establish a stable and sustainable CI/CD pipeline for multi-cloud deployment, teams must carefully identify the deployment path they intend to take as well as understand the challenges they might face along the way.
The integration of cloud deployment into a standard CI/CD pipeline can go a long way toward eliminating overall app deployment burdens. Many CI/CD tools -- commercial and open source alike -- offer direct integrations with multiple cloud service providers that enable a seamless deployment experience with minimal overhead.
While support for individual cloud providers varies from one CI service to the next, a provider-agnostic approach to deployment is a great path toward a multi-cloud CI/CD pipeline. If you design a deployment process with no provider in mind, you can be as flexible as possible in your infrastructure requirements.
Here's a look at some common ways to achieve that goal, along with the challenges they could bring in a multi-cloud strategy.
Atomic file deployments
The most straight-forward app deployment method is to use a reliable file-transfer service, like Secure Socket Shell (SSH) File Transfer Protocol, or SFTP, to deliver files. While this method is the least error-proof, it is most likely supported by any cloud provider that offers remote server access via SSH, which is most of them. When you configure deployments, you can swap, update or remove SFTP endpoints without changing the nature of the deployment.
Container-based deployments
A more stable and popular way to handle a multi-cloud deployment is to use a container-based architecture. In this model, you build and deliver an image of your application to a container repository that any cloud provider can access, rather than deploy your application code in its entirety to your chosen cloud provider. This enables you to centralize the build process and use the built-in container orchestration services that many cloud providers offer to actually launch the generated image.
Hybrid deployments
A provider-agnostic approach to multi-cloud deployment might prevent you from properly using the individual tools that make cloud hosting stand out from traditional application hosting. If you identify the unique features of one -- or many -- of your chosen cloud providers, you can get creative with dependency distribution at the expense of portability.
For example, if your secondary cloud provider offers a mechanism to upload content delivery network assets but your primary provider does not, then deploying to one or both clouds should always include the steps required to upload the necessary assets to the CDN, regardless of the deployment target. While complex, this method enables you to be provider-agnostic and still use a wide range of tools. On the flip side, it can lock you into multiple providers, which increases the complexity of your application architecture and makes it less likely you will be able to make any infrastructure changes in the future.
General challenges
Beyond simply delivering code, it is important to identify the post-deployment tasks that must run in each cloud environment. It can be difficult to prepare a CI/CD pipeline to run automated tasks across providers, but it's a necessary evil for cross-platform load balancing.
Additionally, vendor lock-in is a serious threat to any cloud-based service. It might be easier to manage your pipeline when you use the bare minimum hosting features of multiple cloud providers, but you'll likely want to use more. From managing pre- and post-deployment tasks to setting configuration variables, the more cloud providers you deploy to, the more customization you will have to introduce to the CI/CD pipeline.
