Build a multi-cloud app with these four factors in mind
A multi-cloud strategy reduces vendor lock-in and outage risks. But to realize those benefits, development teams must first design apps to successfully run on various platforms.
In software development today, the cloud is a fact of life. And, increasingly, enterprises plan their application architectures around multiple public cloud providers, rather than just one.
A key driver behind multi-cloud adoption is increased reliability. In 2017, Amazon's Simple Storage Service went down due to a typo in a command executed during routine maintenance. In the pre-cloud era, the consequences of an error like that would be relatively negligible. But, due to the growing dependence on public cloud infrastructure, that one typo reportedly cost upwards of $150 million in losses across many companies.
A multi-cloud app -- or an app designed to run on various cloud-based infrastructures -- helps mitigate these risks; if one platform goes down, another steps in to take its place.
Multi-cloud app development
Infrastructure changes should take days, not months. Regardless of the reason -- to save money, to prevent vendor lock-in or simply to run your app in a development environment without design compromises -- writing code without a specific cloud platform in mind ensures it will run on any server. This enables dev teams to move an application to a different cloud provider or even bring it back on premises with minimal effort.
Enterprises continue to adopt multi-cloud.
However, to design a multi-cloud app, you need to do more than simply avoid vendor-specific tools. In fact, there are a handful of factors to consider to ensure an application can run in any production environment. Start with these four.
1. Private information
Never include passwords, API keys, encryption keys or other types of sensitive information within the source code of an application. Many cloud providers have tools that let you define these values in a secure fashion and access them only when needed. But, unfortunately, if you want to avoid vendor lock-in and move toward a multi-cloud model, this approach won't work.
While there are a handful of ways to work around this, two of the more popular options are to encrypt these variables directly within the code base or use a third-party secrets management tool, such as HashiCorp Vault. Vault is specifically designed to store private information, enabling you to ensure the safety of your data without the fear of vendor lock-in.
2. A single point of entry
Providing access to a multi-cloud app can get complicated, as it is hosted on multiple infrastructures. Be sure your application has a single point of entry -- such as a domain name or IP address, in the case of web apps -- through which users can access it.
While this might sound like a potential point of failure, there are ways to minimize that risk. For example, you can use round-robin domain name system records that point to each individual cloud provider. This lets you distribute the load equally across each cloud platform, without having to relying on any specific one.
3. Automation
To sanely manage multi-cloud infrastructure, invest time and effort into effective automation.
Multiple cloud platforms mean multiple deployments. However, just because there is more than one destination for your code doesn't mean you need more than one delivery method. To sanely manage multi-cloud infrastructure, invest time and effort into effective automation.
You can configure CI/CD pipelines to deliver code to multiple destinations with minimal overhead. Also, use orchestration technologies, like Puppet, Chef and Terraform, to handle tasks such as server management and scaling. The major advantage of automation in cloud-agnostic application design is that, when you want to rely more or less on a particular cloud platform, it's generally as straightforward as updating some configuration files.
4. Native vs. non-native tooling
In general, you should avoid native tools from any one cloud provider in multi-cloud infrastructure, but there are some exceptions for unique feature sets.
A good example of this is Microsoft's Azure Blockchain Service. This particular feature is singularly unique, which means that you might need to bend the rules a bit and integrate it to build a more robust multi-cloud app.
Additionally, if developing for multi-cloud ever becomes more cost-prohibitive than the risk of vendor lock-in, it might be worth it to use a cloud provider's native tool over an agnostic one.
