Today's email departs from the past few weeks' "hilarious" vein and drifts back towards a general analysis tone. Today's topic: lock-in!

As always, should you wish to link someone else to this post, you can forward it, or else view it on the web.

Sponsorships are fun sometimes.

ParkMyCloud: "Can we have one of our execs do a video chat with you?"

Me: "Better idea, how about I talk to one of your customers instead so we can make fun of you on your dime?"

It turns out I'm SUUUPER convincing, so that's what's happening! Join me and ParkMyCloud's customer Workfront on July 23rd for a no-holds-barred discussion about how they're optimizing AWS costs, and whatever other fights I can pick before ParkMyCloud realizes what's going on and kills the feed!

Register here to catch the fun. Sponsored

The Lock-In You Don’t See

It’s extremely important to avoid vendor lock-in—according to the way the IT industry has always worked, and (by extension) the vendors who dream of one day prying you away from your primary cloud vendor.

This line of argument has been used to justify all kinds of suboptimal positions ranging from “multi-cloud is a good idea” to “let’s build everything in Terraform because migrating it will be super easy” to “the only universal database that doesn’t lock us in remains DNS (specifically its pinnacle of expression in the form of Route 53).”

It’s used as an argument against aggressive spend commitments to unlock discounting against any higher-level differentiated service offering that doesn’t transcend providers.

Raging against this school of thought is left as the subject for another rant. Today, I’m going to instead talk about three insidious forms of lock-in that you’ll never see coming.

The people

If you call an engineering all-hands today and announce that you’re leaving your primary cloud provider in favor of a migration to IBM “Cloud,” one particularly brash engineer will probably declare that if you go ahead with that move, they’re going to quit.

You roll your eyes; that engineer is always making declarations like that.

But that engineer is the only one bold enough to say out loud what at least a third of your engineering department is thinking.

If you’re already on a single cloud provider, you’ve hired staff who know the ins and outs of that platform. They know how it works and, critically, how it breaks.

When they’re told that it’s time to move to another platform—be it a competing top-tier cloud provider, a data center you’ve gotten a killer deal on due to an annoyingly persistent raccoon problem, or virtually any other location—they’re confronted by a choice.

They can either stop honing their current well-compensated skillset and become a neophyte again on a completely new platform, or they can take their ever-more-valuable skills down the street to a company that’s using the provider that they’ve specialized in—and almost certainly get a pay raise along the way.

When clients ask me what the hardest part of moving their AWS environment to a competitor would be, my answer is always “replacing the full third of your engineering staff that resigns within six months.”

If you as an engineer know how AWS is going to hurt you and have plans for how to mitigate it, you don’t want to go through that painful process all over again for GCP or Azure. Once was enough for you.

The access

The second form of lock-in that gets overlooked is whatever your provider is using for Identity and Access Management (IAM).

Look at your security policies. Examine your compliance documents. Look at your Terraform code.

There’s an awful lot of access management logic baked into your assumptions there. Migrating all of that to another provider requires a revisiting of those assumptions—and a thorough dusting off of issues long since put to rest.

Is cross-account role assumption a thing? Are session timeout limits consistent between providers? Does your new provider assume you have an SSO system that will be used but you’re using a bunch of hand-managed IAM users?

If we look at AWS as our example—because, let’s face it, it says AWS at the top of this document—you have IAM credentials. You have root account credentials. You have role assumptions. You have managed policies. You have CloudFormation stacks—even if you’re a Terraform shop (go and check out your CloudFormation console; I’ll wait). You have an entire event model that’s set up to reflect these things, and in turn it drives auditing tooling and frameworks like CloudWatch and GuardDuty—and the attestations you’ve made to your compliance folks about how all of these things work.

In theory it’s easy to shift. In practice, the theory breaks down.

Key management, RBAC, ensuring that only the people who should have access to your data do in fact have that access… It’s an entire department at most large companies. Suddenly, changing the underlying primitives is a herculean effort—and one that’s unlikely to be offset by whatever perceived benefit of a cloud migration is being sold to you.

Data gravity

Does this sound at all familiar to you?

Someone at your company says “we’ll have the main app live in AWS and the data science stuff will be in GCP,” and then everyone puts their fingers in their ears and says LA LA LA very loudly, thinking that “well, where does the data live?” is somehow automatically a non-issue.

Everyone talks about data gravity being a lock-in factor. But rather than taking positions that help mitigate it, they instead…talk about data gravity being a lock-in concern, and then go ahead and accept that.

This, in turn, means that while you may in theory be multi-cloud, your primary cloud vendor emerges (and begins to accrete the rest of your cloud usage) pretty quickly.

The way to predict which vendor becomes your primary is simple: It’s the one that holds your data.

Let’s ignore DynamoDB vs. Aurora vs. Oracle database arguments here; I’m talking about something more fundamental at play. The numbers change slightly at scale, but “sending a given quantity of data from AWS to another cloud provider” results in an AWS data transfer charge just slightly below the cost of storing that same quantity of data in S3’s standard storage tier for four months. Azure and GCP charge similarly for data egress; this isn’t a problem specific to AWS.

Fundamentally, it doesn’t matter that another provider has better APIs for working with data if it costs you a boatload to get it over to their environment for analysis. You become locked in based purely on the economic weight of your own data.

There is no hope

There are a pile of vendors that claim to get around lock-in problems. IInvariably, they do this by introducing such lousy abstractions on top of the cloud providers that working with any of them becomes a similarly awful experience.

Please understand: I’m not saying that all companies in all situations should throw caution to the wind and embrace every last API their chosen cloud provider offers.

What I’m saying is that—despite some explicit conscious choices that you’ve made to the contrary—you’re already locked in.

Disagree with me? Yell at me on Twitter, a platform to which I am hopelessly locked in.

About 80% of software teams that do not yet practice observability plan to reach an advanced level within the next 2 years. Honeycomb asked your peers to tell us how they're doing.

Advanced observability teams are 3X more likely to work in an organization that understands the breadth and impact of their tech debt. A whopping 92% are confident they proactively notice and catch bugs after code is deployed to production.

Most teams have just begun their observability journey. See how you compare and let Honeycomb.io help you advance your practice. Sponsored