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!
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