I don’t understand why people complain about Serverless vendor lock in. Let’s split lock-in into two categories: 1. Essential complexity DyanmoDB and Firebas

I don’t understand why people complain about Serverless vendor lock in. Let’s split lock-in into two categories: 1. Essential complexity DyanmoDB and Firebase are different products with different features and complexities. There is no “ANSI SQL” here. They are as different as they are similar. Moving from one to the other is a non-zero cost because they have different features your app would have to make up for or adopt. 2. Inessential complexity Serverless functions don’t necessarily need different signatures and it is conceivable that a standard for HTTP evented functions could emerge. Many are working on this. I expect this to be largely resolved over the next few years. Lastly, I’m grateful for ANSI SQL but over the last 20 years I think I’ve seen one or two clients migrate a mature Java app from one database vendor to another (excluding some very recent moves to AWS RDS). Keep in mind that JDBC is about as good an abstraction as we’ve ever had for database agnosticism. When you choose to build a lot of complexity upon an abstraction you have to be honest with yourself: have you ever dealt with a service (storage, queues, naming, auth, etc...) that didn’t have leaky abstractions? Of those with few/zero leaky abstractions how often did you need to migrate to a different vendor? Why do we expect a rapidly evolving set of systems and services to behave like mature commodity software? Fear of vendor lock-in is a premature optimization.