Understanding the lock-in objections to adopting serverless

StrategyDaily Email

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

Originally published .

Other articles you might enjoy:

Free Email Course

How to transition your team to a serverless-first mindset

In this 5-day email course, you’ll learn:

  • Lesson 1: Why serverless is inevitable
  • Lesson 2: How to identify a candidate project for your first serverless application
  • Lesson 3: How to compose the building blocks that AWS provides
  • Lesson 4: Common mistakes to avoid when building your first serverless application
  • Lesson 5: How to break ground on your first serverless project

    Architecture & Process Review

    Built a serverless app on AWS, but struggling with performance, maintainability, scalability or DevOps practices?

    I can help by reviewing your codebase, architecture and delivery processes to identify risk areas and their causes. I will then recommend solutions and help you with their implementation.

    Learn more >>

    🪲 Testing Audit

    Are bugs in production slowing you down and killing confidence in your product?

    Get a tailored plan of action for overhauling your AWS serverless app’s tests and empower your team to ship faster with confidence.

    Learn more >>