Public Cloud Vendor Lock-In

As large companies consider how to integrate the public cloud into their technical and operational capabilities, many end up debating the same question: “Should we aim to be vendor agnostic?”

Many Chief Information Officers want to avoid getting locked into one cloud vendor as their team starts to migrate applications from dedicated, on-premise data centers to the public cloud. Often this can be fairly easily accomplished, as long as the company is not developing new applications that are fully cloud-enabled from the beginning. Yet, once they progress past migration and start designing and deploying applications that are cloud native, it’s questionable if trying to be vendor agnostic with respect to public cloud can actually be supported by a solid business case.

In fact, vendor lock-in can actually drive value. Below, we debunk the arguments in favor of remaining vendor agnostic — and then explore how companies can develop a competitive advantage by choosing a single public cloud services provider.

Arguments in favor of vendor agnosticism (debunked)

One argument for remaining vendor agnostic is that vendors don’t always consider customers’ needs when changing products, so avoiding vendor lock-in protects you over the longer term. It's true that vendors can make decisions that are inconsistent with the goals of their customers, especially those that are small or use their products in ways that others do not. But large, public cloud vendors (Amazon, Microsoft, and Google) are so massive and their customer bases so large, that they are unlikely to make decisions that negatively affect a large number of users. The fact that all three vendors have mass-market customers, including individuals and small businesses, is also a mitigating factor, as any change in capability will potentially affect thousands or tens of thousands of customers.

Another argument is that a vendor that captures your business will eventually start to turn the screws on fees to drive up margins. But the reality is that, with greater IT scale than most any other company, public cloud providers can build, deploy, and scale server and network infrastructure more cost effectively. Given this scale and the intense competition in the space, cloud providers are incented to drive down the average cost of compute power and storage year over year, even taking into consideration their margins. Only the very largest companies can achieve similar scale and efficiency in their infrastructure.

Finally, some might think that features and capabilities from a given vendor might be eclipsed by other vendors in the future, so you’ll fall behind competitors using those services. This risk may actually be worth considering, but perhaps not in the way it would apply for other types of software vendors. Each of the big-three public cloud providers is investing billions of dollars in research and development every year. For very advanced needs in specific areas (such as machine learning), one vendor may be a better fit for a company’s specific requirements. A vendor’s ability to meet specific regulatory requirements is a related consideration, although it does seem like all three are aiming to support the major global regulatory requirements that would apply to most companies. In short, vendor-capability imbalances are important to consider, but mostly at the extremes.

The value of vendor lock-in

The basis for determining whether to avoid or embrace lock-in can be based on a fairly straight-forward continuum of public cloud adoption. The further along the curve you move, the move value you gain by sticking with one provider. In many cases it is not that onerous to jump from one provider to another, but the reality is that you will likely leave benefits on the table. Consider these four steps of public cloud adoption, and why value accelerates with each one.

Step 1: Server-to-server migration

The typical first step of any company’s cloud migration is porting a set of existing applications from on-premises data centers to a mainstream public cloud. As discussed above, since one vendor’s virtualized Linux or Windows servers are much like another’s, the level of lock-in is pretty modest. Of course, you still need to sort out the implications of file storage, encryption and key management, disaster recovery, and so on, but the major cloud vendors are similar in their basic offerings.

If you remain at step one, you can, with modest expense, move applications from one public cloud vendor to another if you want or need to. There are even software vendors who sell tools to further abstract virtual machines from the public cloud vendor’s configuration and, as such, increase the portability of applications.

Step 2: Adoption of native-cloud infrastructure

Each of the public cloud vendors has taken a step up the value chain and offered more sophisticated capabilities beyond storage. A key function is databases, often based on open-source technologies, but heavily modified for the specific-vendor environment. Other capabilities include specialized storage capability, load balancing, backup and recovery, multi-region support, and other core architectural capabilities that are required for any enterprise application.

These offerings are often pre-configured and optimized for a single public cloud vendor. The advantages are numerous, and include lower operational costs, simplified procurement, and often more sophisticated capabilities than those offered by “independent” software vendors. As these capabilities are different across public cloud vendors, it makes changing horses mid-stream more difficult and costly.

Step 3: Adoption of higher order cloud-vendor analytical capabilities

More recently, the major public cloud vendors have been building sophisticated analytical capabilities on top of their cloud infrastructure. Examples include extract, transform, and load (ETL) platforms, data analytics and visualization platforms, machine-learning engines, call-center capabilities, mobile-application testing and deployment, and more. All these capabilities are nearly instantaneously available, and can be rented and scaled as necessary. Public cloud vendors are also enabling other software companies to package applications and make them available on “app stores,” easily deployable in pay-as-you-go models.

Again, all these capabilities can accelerate projects and turn ideas into revenue faster, but they more tightly couple a company to a single cloud vendor and essentially eliminate any concept of being vendor “agnostic.”

Step 4: Server-less transactions

This is the final step, at least for the moment. In the first three phases of cloud adoption, your applications either run in a defined cloud region that you control, or you leverage managed services provided by the cloud provider (similar to how you might use Salesforce to provide CRM capabilities). The last adoption step on the public cloud continuum requires a wholesale change in thinking that can be difficult for many companies to embrace.

Server-less technology runs business logic you define and executes that logic as a series of discrete events, but no virtual “server” that you own and manage is performing the work. An example to illustrate the concept could be the online purchase of a book. When the buyer pushes “buy,” a transaction is handed off to a logic set that knows how to charge a credit card. Upon completion, it starts a transaction on another set of logic that knows how to decrement inventory, which then starts a transaction that knows how to pick the book and set up the shipping order, and so on. Each transaction relies on a discrete set of logic that knows how to do what it needs to do and nothing more. As such, the entire book purchase is completed by a series of discrete, abstracted events.

The reason it is called “server-less” is that each of these discrete logic blocks is executed on demand by the cloud vendor’s central transaction-processing capability, using the custom logic that you define for your business. You have no dedicated server and no dedicated capacity, and are charged a very small amount for the discrete transaction based on how much compute capacity is consumed. The service scales automatically, based on how much you need to use it.

In theory, these blocks of logic could be ported from one public cloud provider to another, but it would be a tricky task. By adopting server-less applications, you end up further embedding your business into a single public cloud provider’s infrastructure and severely limit your ability to switch vendors.

Embrace your vendor’s capabilities

If your goal is to be vendor agnostic in your approach to the public cloud, you likely have to accept that your ability to leverage the more advanced capabilities of the public cloud vendor will be limited. That isn’t to say that you cannot leverage multiple public cloud providers, but that for a single application, there are some significant advantages to committing. Trying to be agnostic may severely limit the benefits you receive, as well as the overall public cloud business case.

When you assess that the risks inherent in vendor lock-in as it relates to public cloud are fairly minor, and the benefits of fully embracing a vendor’s offerings can be significant, both financially and from a software-development perspective, it is rather hard to argue for vendor neutrality. Utilized correctly, the public cloud can drive impacts to both the top and bottom line—especially if you embrace the full array of a single vendor’s capabilities.