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

    ☎️ Serverless Clarity Call

    Need quick guidance on a specific issue on your AWS serverless project? Or just wondering where to start with serverless?

    Book a call and ask me anything.

    Learn more >>

    🛫 Serverless Launchpad

    Ready to start building your new AWS serverless project but need help with getting everything setup?

    The Serverless Launchpad is a done-for-you DevOps service installed in under a week. You get a leading-practice multi-account AWS environment, a scaffolded codebase and architecture including the common AWS serverless services, isolated cloud environments for individual developers, automated delivery pipelines right through to production and much more. Everything is IaC, extensively documented and handed over to your developers.

    Learn more >>