How to Fix Serverless Vendor Lock-In
How to Fix Serverless Vendor Lock-In
Overcoming the #1 reason preventing serverless adoption
I've long advocated that you need to embrace vendor lock-in to make the most of the cloud.
I'm changing my mind slightly.
Cloud providers can choose to provide a common interface to their services. When they don't provide such an interface, they're creating vendor lock-in. When they do, they're making it easier for customers to switch should they ever need to. It's a choice, whether intentional or not.
Don't believe me?
Take a look at CosmosDB from Azure. It provides, according to some benchmarks, performance comparable to our beloved DynamoDB. And yet, by design, it supports SQL as a query language. It gets better: if you want to, you can even use MongoDB’s syntax!
It's easy to see the implication of this choice: if you have an existing app built on top of a standard relational database, you can point it to CosmosDB instead. You get Dynamo-like performance and scalability, while barely rewriting any code. And, of course, you can ditch CosmosDB as soon as it no longer makes sense to you, and just move over to any PostgreSQL-compatible database.
"Oh", I hear you saying, "but AWS has Aurora/RDS for that!". I know that, but it's not the point. The point is that if you choose to build something on top of DynamoDB, you're never getting out of it (not without massive effort, that is). This simple idea acts as a blocker towards greater adoption not just of DynamoDB, but also of Lambda, EventBridge, you name it.
Serverless as a whole is badly penalised and, arguably, under-adopted because of the lack of common interfaces.
The services mentioned above are, incidentally, my favourite ones. I've spent years advocating for them and the #1 pushback I get ALL THE TIME is that folks don't like getting vendor locked-in.
So here's a simple idea for AWS.
Build interfaces on top of these serverless, cloud-native products that make it easier for people to switch to and from them.
They may never need to leave. But if that's all that's stopping them from adopting these beautiful services and, more broadly, serverless, why not address those concerns? These are potential customers whom AWS claims to be obsessed about.
I like the Amazon way, how they listen to customers and learn from them. I'm not a fan of companies that think they know best, whose mission is chiefly to “educate” their customers.
We’ve been trying to educate people about the value of vendor lock-in for too long.
It's time to embrace a more open approach and to welcome a new cohort of amazing teams that should really be building their products with serverless, but whose leaders are too worried about vendor lock-in to make the leap.