Once you’ve decided that cloud computing will be a part of your business strategy, you’ll need to answer the question, “Which cloud vendor should I choose?” You may already have a vendor in mind, or you might start with an internet search such as “Azure vs AWS vs Google.” It’s not uncommon during this search to also ponder, “How can I avoid vendor lock-in?”
Getting tied to a single cloud vendor is a pretty typical fear. If this fear isn’t alleviated, it could quickly become a barrier. Most cloud vendors realize this, and to help with knocking down the vendor lock-in barrier, many are offering new ideas in order to shape the cloud adoption landscape. Let's say you use Aurora DB at AWS. Google and Azure made sure they have a competitive product or capability through ClearDB. Image Machine Learning? Google has been developing one for years, so AWS launched one. This year Google announced video machine learning, and I suspect AWS will be announcing that this year. Beyond products and services, vendors are finding other ways to alleviate the fear of vendor lock-in and these manifest in industry buzzwords like private cloud, hybrid cloud – and one of the newest on the scene – multi-cloud.
Multi-cloud is the idea of using more than one vendor, so that if an outage occurs with one cloud vendor, you won’t have a complete failure (because all your cloud eggs won’t be in the same vendor basket). Although the concept seems sound, a lot of the multi-cloud advice I see circulating is pretty bad.
For example, one multi-cloud configuration: Hosting your DNS service (DNS is critical to connect all internet traffic) on Amazon Route 53 while hosting your actual website on Azure App Service. This strategy is pretty useless, because if either of those services fails, then your website will also fail. Although the strategy is technically “multi-cloud,” it certainly doesn’t solve the specific problem (and fear) of cloud outages.
That said, there are multi-cloud techniques that do provide benefits. Backup or redundant hosting of a warm replica is a multi-cloud technique that can be used well. For example, AWS can be your primary application host while you keep a warm replica of it running on Google Cloud. Should something happen to your primary host, you can redirect traffic to your quickly scaled standby (with your DNS provider hosted in yet a third cloud location). You’ve also reduced vendor lock-in by being completely free to switch the location of your primary cloud host at any time. You’ve probably noticed by now that this example may seem overly complicated, as we’ve replaced the vendor lock-in barrier with infrastructure complexity. You’re right: Multi-cloud infrastructure is going to be more complex if you choose to go that route.
For cloud applications, there are also multi-cloud techniques that are not related to the cloud infrastructure. Your application developers can help to future-proof your cloud solutions. Developers love to create patterns and abstractions.
RESTful APIs hosted in any cloud configuration are a multi-cloud technique. It doesn’t matter if your API is hosted on-premises, with AWS, Azure or Google Cloud. As long as your application can talk to your API, the hosting environment doesn’t matter. Challenge your application architects further by asking them to use vendor-agnostic techniques and cloud best practices.
For instance, suppose your API is the public-facing aspect of an Oracle database. This is an Oracle database vendor lock-in for your API. You have options to host Oracle with different vendors; but consider a cloud-forward strategy. A cloud native strategy will take advantage of the frequent new announcements with databases from various cloud vendors. Your development staff can help you with scoping a strategic migration to a database platform that isn’t vendor specific. An example of this is migrating to a MySQL-compatible database from your Oracle database. If this is justified, you’ll have an incredible variety of cloud vendor database options to choose from.
This often-overlooked use of application architecture, rather than infrastructure, is a viable multi-cloud technique to avoid the dreaded vendor lock-in. Make use of the talent in your software development team! You might think this will slow your developers down, but it’s likely the opposite will be true – and with improved developer efficiency to be gained as a result.
Improved efficiency is a natural outcome of developers working in their element; and abstraction and pattern development is bread and butter for good coders. When developers are free to configure their infrastructure as code they will gain even higher efficiency because they won’t have to wait for provisioning or authorization for new on-premises hardware or software.
If you would like to explore how nearly 20 years of custom software development experience applied to the cloud can help you avoid cloud vendor-lock in, don’t hesitate to connect.