Understanding the lock-in objections to adopting serverless

One of the most common objections I hear to adopting a serverless-first approach to application development in an organisation is that of lock-in — be it vendor/cloud provider lock-in, cloud service lock-in or some other form.

If serverless is truly to become the mainstream de facto approach to building software applications in the near future, then I believe we as the serverless community need to have a stronger counter to this objection (that isn’t dripping with snark!).

I’m starting some research in this area with the goal of getting a deeper understanding of the perceived risks and producing a resource to help folks make a more informed decision.

I’m hoping some of you can help me with this, and I do have a favour to ask.

But first, I want to share some of the open questions I currently have in my notes that I plan to explore further:

• What are the different forms of lock-in in the context of building serverless applications? Cloud provider, cloud provider service, deployment framework, runtime/language, etc.
• How do these forms of lock-in apply to other system architectures (e.g. container-based)?
• What are the potential events that would crystallise lock-in concerns and what is the chance of these being realised? (e.g. provider raising their prices, service degradation, moral objections)
• Terminology — Is there a distinction to be made between “lock in” and “coupling”? i.e. you’re only locked in if you can’t leave, but you’re coupled if you can leave but there is a somewhat significant cost in doing so. Is this a meaningful or merely pedantic distinction?
• What are the different switching costs involved and are there any frameworks for estimating these?
• What are the costs of avoiding these lock-in concerns in the first place and are there any frameworks for estimating these?
• Are some voiced reasons a mask for a different underlying concern?
• In what cases is lock-in always a valid reason for not choosing serverless? e.g. when regulations enforce certain architectural choices

And now to that favour…

Can you help me with any of the following?

• Do you personally have any misgivings (no matter how small) for taking a serverless-first approach to building new applications in your organisation on the basis of lock-in? Can you elaborate on these concerns?
• Do you have stories from colleagues or clients where they raised lock-in as a genuine concern that you could share?
• Do you have any links to online resources (blog articles, Twitter threads, etc) where you saw a good case being made for/against serverless on the basis of lock-in?

If you could help me with any of the above, I would really appreciate it! Just hit reply and tell me a bit about it. I won’t publish anything you share with me without your explicit permission.

Thank you kindly!

— Paul