If you've spent any time researching serverless infrastructure like AWS Lambda and Azure Functions, you've probably heard about serverless lock in. The argument goes something like this: because your code is tied to infrastructure, and even to a specific datacenter, on hardware that you don't control and can't access, you operate at the mercy of the cloud provider and are thus completely locked in.

This is, in a word, nonsense.

Technology Lock In

Fundamentally all technology choices are a tradeoff between perceived risks and benefits. When you're responsible for steering an organization's technology choices it's critial to consider risks, like being locked into a declining technology, open source community, or vendor. These are balanced against benefits a technology offers, such as development speed, cost to scale, and ease of operations. This is why lock in is an important consideration even when evaluating open source solutions. Before deciding to build on top of an open source project any experienced technical leader will ask how actively maintained and supported that project is. Nobody wants to get led into a technological dead end.

The risk of lock in exists when you build against any standard. For example, Terraform's proprietary syntax is a form of lock in. Building GPU applications on CUDA is too. So is relying on third-party APIs like Auth0, or standardizing on a CI/CD tool like Jenkins for your team.

So does using serverless technologies create forms of lock in? Yeah, just like every other tech. ¯\_(ツ)_/¯

It's true that some of the ways that you write and architect your application will be Lambda-specific. Of course, the same would be the case when using Kubernetes, or ec2, or VMWare, or Heroku, or whatever else you could pick to run your application on. This is the nature of making choices.

On the other hand, the most significant forms of lock in aren't related to serverless (or any stateless compute component). It's primarily data that locks you in. If you have significant data gravity in AWS, you'll choose Lambda, not because Lambda has any significant benefits over Azure Functions or any other FaaS option, but because Lambda is a stateless compute component, and it's an order of magnitude easier to move your compute component to your data than to move your data to your compute component.

FaaS offerings abstract away the underlying infrastructure to such a level as to make the compute environment almost generic. As a result, Lambda's APIs don't create significant lock in; this is one of the easiest parts of your infrastructure to change. In counterpoint to the claim that your code is tied to infrastructure, I might point out that the infrastructure is completely invisible to you and that's not an accident. Can you change it? No. Do you have control? No. Are you better at infrastructure management than AWS? No. Giving up "control" to an expert service provider isn't new, and it isn't a drawback, and in comparison to migrating data and event sources between cloud providers, moving stateless functions is a minor concern.

Avoiding Lock In

So let's get honest here. The alarmist arguments about serverless lock in come from vendors that want you locked in to their specific technology. If your product is a container-specific varient of Linux, then of course you'll say technologies that abstract away that detail of your runtime environment are a "bad" form of lock in. But that's just marketing smoke and mirrors.

The right way to evaluate lock in is to look hardest at the parts of your system that are hardest to move. In most cases you'll want focus on using the cloud your data is in, and where your event sources are. Evaluate which cloud provider you're most comfortable deploying into and managing systems within. If you're just moving into the cloud focus lock in decisions on data gravity, event sources, operational integrations.

Oh, and guess what? If you eschew AWS Lambda or serverless in general, you'll still be locked in to whatever you settle on. And in the meantime, you'll miss out on the benefits that have driven hundreds of thousands of customers to Lambda over the last couple of years.