No Fear of Cloud Lock-In?

TechTarget recently ran an article titled “Cloud vendor lock-in fears dwindle for enterprises.”
Really? That runs completely counter to what we hear from our customers and from partners like Packet.

The article claims vendor lock-in is not a major concern for decision makers formulating cloud migration strategies.  Let’s take a closer look.

Should You Be Concerned About Cloud Lock-In?

In short, absolutely.

Please, DO NOT IGNORE the lessons learned over the years about the dangers of vendor dependence.  Since the early days of the mainframe computer, proprietary vendors have hindered the pace of innovation and impaired business results.

The cloud is no different—don’t believe the smoke and mirrors.  First-generation cloud vendors are trying to lock you in as well.

It is all too tempting to take the path of least resistance and place all your bets on one of the major public cloud providers. They have so many services to offer! (BTW—it’s a psychological trap, see our post “Just What the World Needs: Two More Tiers of Storage”)

As we’ve written in other posts, cloud lock-in is just as real as traditional software or hardware vendor lock-in, although you often don’t feel the full costs until months after deployment.

All of the hidden expenses (API calls, egress fees, etc.) imposed by first-generation cloud providers—expenses you never had to pay with on-prem implementations—quickly add up as you scale your deployment. And by then, it’s too late. You’re committed to a certain path, with certain budget expectations, and it may be too difficult and cost-prohibitive to change course.

The main reason? Near total lack of interoperable standards between public cloud providers. Carl Brooks, analyst at 451 Research, sums it up well in the TechTarget article, saying “The fact is that all the major cloud platforms operate differently, so when you pick one, you're basically picking a team.”

And a team that is incompatible with every other team out there, playing a different sport with different rules.

In the public-cloud world, the lack of industry standards makes choosing different cloud providers for different capabilities a challenge.  This often leads to extreme options—

go all in with a single vendor or build out a completely redundant implementation with a second vendor for failover or as an escape hatch should a relationship go sour.

But as the meme goes…

Both best-of-breed AND cost savings, that is.

Do You Have One Strategy for All Situations?

If your strategy is to use best-of-breed technology to assemble the right infrastructure for a specific workload, it’s perfectly valid to hunt for capabilities that may be difficult to replace/duplicate, in the interest of gaining a competitive edge, accelerating time to market, etc.

This is true whether your implementation is on-prem, cloud-based, outsourced, SaaS, etc. On the other hand, there are plenty of business requirements that do NOT warrant using highly specialized or cutting-edge solutions that are only available from one provider.

Should you really embrace the entire stack from a single vendor just to take advantage of their speciality services? While it’s convenient, what are the risks? It’s not as though the cloud has eliminated all technology risks. So what risks remain, and how are you going to address them?

Whether you’re worried about it or not, if you go with a single cloud provider you are in fact tying yourself to that vendor, with all that entails.  From the transfer fees to get your data back out (for any reason, including no longer being a customer of the vendor, extended downtime of the provider, etc.), to the closed APIs that your solution is built on that would require varying levels of refactoring (at the least), to blowing it up and trying again in order to deploy on another cloud.

Today, you can easily swap out compute, storage and networking components in your data center.  Why should the cloud be any different? Shouldn’t you be able to decouple cloud compute, storage and networking services?

While true multi-vendor industry standards are rare in the public cloud world, one AWS API has emerged as a de facto standard that can help you improve choice.  The AWS S3 storage API is supported by a wide variety of providers, including Wasabi.

This de facto standard API lays the foundation for best-of-breed, multi-cloud implementations that can help you avoid lock-in and reduce risk.  With a multi-cloud architecture you can pick the best cloud provider for a particular function (compute, storage, networking, etc.) based on price, performance, features or whatever attributes are most important to you.

For example, you can use Wasabi as economical, simple and reliable active data storage for your AWS Elastic Compute Cloud (EC2) workloads.  Wasabi offers direct, high-speed connectivity to AWS and other popular IaaS and PaaS solutions through partnerships with leading colocation, carrier hotel and exchange providers like Equinix, Flexential, Limelight Networks and Megaport. These private network connections avoid internet latency and bottlenecks, providing fast and predictable performance.  And unlike with first-generation cloud providers, we have no charges for egress or API requests.

Moving to the cloud? Don’t repeat past mistakes. Avoid vendor lock-in and build it your way with a best-of-breed, multi-cloud strategy.

Learn more in our Wasabi for Multi-Cloud Compute Environments blog.