How public clouds actually lock you in and what to do about it

Public clouds make it so fast and easy to get the resources you need to build and deploy apps. But before you get too deep with AWS, Azure or Google Cloud, it’s important to understand one of their biggest risks: vendor lock-in. At a time when software success determines so much of a business’ success, provider lock-in poses profound risks including exorbitant costs, unpredictable downtime, and reliance on proprietary tools that might be changed, discontinued, or priced out of usability at any point.

In this blog, we will detail how AWS, Azure, and Google Cloud lock in their customers. They discourage clients from moving workloads to other cloud providers through both technical constraints and restrictive business tactics. We’ll also discuss some ways that businesses can stop public cloud providers from locking them in.

Public cloud providers don’t want customers to take their business to competitors for obvious reasons. They’ve all set up roadblocks to discourage workload mobility using very similar tactics.

All three hyperscalers offer a range of proprietary services and features that will run only on their own infrastructure. For example, if you build a GKE cluster, there are many customization options you can choose from, but they’re not interoperable with other vendors. To really get any benefit out of public clouds, you need to use the features native to your cloud, which can lock you in. Many custom public cloud services are unique to their providers and have no equivalents on other platforms. Ultimately, what this boils down to is — if you use any proprietary networking, storage or other custom options and later switch to another provider, you may need to rebuild your complete infrastructure. 

Some examples of proprietary services from public cloud providers include:

• AWS: Amazon RDS, Amazon ECS, Amazon Aurora, Amazon CloudFormation, Amazon Kinesis, Amazon DynamoDB, Amazon Key Management Service

• Azure: Azure Virtual Machines, Azure Functions, Azure Cosmos DB, Azure DevOps Pipelines

• Google Cloud: Google Compute Engine, Google Cloud Storage, Google Cloud Spanner

AWS, Azure and Google Cloud each use their own proprietary APIs to interact with cloud resources, but these aren’t interoperable. All of this makes it extremely difficult to move your systems to another provider — the more you’ve used a given cloud’s APIs, the more you’ll need to rewrite. With the high expense and disruption of rewriting software, few businesses are willing to devote precious engineering time to migrate to another provider.

Containers are designed for portability, and open source Kubernetes enables you to move workloads anywhere. However, public cloud vendors typically use proprietary APIs to integrate their container and Kubernetes offerings with special tooling or capabilities, such as CI/CD platforms, databases, or vendor-specific plug-ins for sophisticated networking capabilities. The result is vendor lock-in.

Even though AWS, Azure and Google Cloud follow pay-as-you-go models, they still have complicated pricing structures that can be difficult to understand, and typically try to incentivize businesses into long-term contracts. Microsoft especially has complex licensing and contracting that confuses many customers. All of this makes it challenging for businesses to accurately compare services between different public cloud providers to determine which offers the best value. As a result, many businesses stick with their incumbent provider by default, not because they give the best value.

Microsoft and Google have large portfolios of business solutions, which are tightly integrated with their own cloud products and services. This makes switching to another provider difficult because you’ll need to find alternatives for some of these business solutions too.

It’s true that AWS offers some data migration tools and services, but they also charge fees for data egress to other cloud providers. If you have a lot of data living in Amazon RDS, Amazon DynamoDB, Amazon Redshift or other AWS database services, getting it out of AWS can be technically and financially challenging. Azure and Google Cloud also charge similar fees for outbound data transfers. 

AWS, Azure and Google Cloud have all created their own APIs, CLI utilities, and other tools for Kubernetes and cloud operations. Businesses that use a public cloud provider need to hire specialists who know the ins and outs of the provider’s proprietary interfaces and tools. This makes migrating to another cloud provider difficult, because it might require additional training or hiring new infrastructure operators with a different skill set.

FINANCIAL SERVICES

Cloud expertise for financial services.

Run business-critical applications on a cloud designed for financial services—backed by cloud experts with over a decade of experience.

LEARN MORE

Here are some ways that companies can get away from vendor lock-in from public clouds, whether you want to extend your deployments to additional public cloud providers or forgo public clouds entirely.

Write your applications to be cloud-agnostic as much as possible. Be smart about where you put your data, which services you use, and don’t make your applications depend on anything proprietary. Use open standards and technologies like containers and Kubernetes, which enables you to run applications on any provider.

Many vendors preach hybrid cloud and multi-cloud, but the only practical way to implement these architectures is with a unified platform that can seamlessly manage clouds from different providers with a single pane of glass. For example, Mirantis Container Cloud provides a single console that simplifies management of clouds running on AWS, Azure, VMware or OpenStack. How well an application performs can really vary between different cloud providers, and this provides developers self-service flexibility to provision the best infrastructure for their applications.

Over the past decade, Docker, Kubernetes, and OpenStack have evolved from upstart open source projects into mature technologies deployed by thousands of organizations worldwide. One of the main reasons for their rapid growth is the simple fact that businesses don’t want vendor lock-in from public cloud providers.

Many businesses won’t consider running open source private clouds based on technologies like Kubernetes and OpenStack because operations can be a nightmare. But just as many businesses choose public clouds to let someone else take care of their infrastructure management, you can also let someone else build and run your open source private cloud for you. With a ZeroOps cloud on-prem solution, you can get a public cloud-like experiences in your own data center or colo facility, delivered through a combination of intelligent automations, a hardened cloud platform built from best-of-breed open source technologies, and 24/7 managed services from a global team of cloud experts.

Migration is no easy task, and fortunately, you don’t need to do it yourself. From refactoring applications to rebuilding infrastructure, there are many services available to help you. For example, Mirantis Application Migration and Modernization can help you quickly prepare and migrate your entire application estate, using an automated platform and a proven framework. 

AWS, Azure and Google Cloud all benefit from vendor lock-in at the expense of customers. It has emboldened some of them to adopt aggressive sales tactics, including problematic renewal practices, where customers are pressured to increase spend in order to renew contracts. If you currently have workloads running on public clouds, and don’t want to be vulnerable to lock-in, multi-cloud or private cloud architectures can give you more flexibility and control, along with the latest open source innovations. Whichever option you choose, keep in mind that there’s plenty of help available, so you can hand off the challenges of migration and operations, and focus on developing the technology that differentiates you.

Read blog: 7 Reasons to Switch to Managed On-Prem Kubernetes