AWS Lambda itself isn't vendor lock in.

If you write your Lambda function to put the interaction between the AWS Lambda service at the surface level of your application (i.e. the entry/exit point), and then write your business logic inbetween, you can create a function that is quite easily tranferrable between cloud providers.

The vendor lock in creeps in more around the surrounding services that the cloud provider offers. You can protect yourself from this though by writing good quality hooks that have pluggable backends, e.g. writing/reading to an object store should be abstracted

I just don't get the "lambda locks you in" thing. You write a server the same way you always would, but like an extra 50LOC exists to make it work on lambda. So if I wanted to deploy elsewhere what would the big deal be?

Lambda also provides a lot more than containerized services, as the article mentions - I no longer have to patch my system, which is a huge operational/ security burden that many companies struggle with. The time to configure API Gateway/ Lambda feels trivial compared to the work involved in maintaining a patched FAAS solution.

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.

API Gateway is the literal manifestation of the worst product I have ever had the misfortune of configuring. This is mostly due to AWS's incompetence at delivering any semblance of working documentation around the product. Looking forward to their new "open source" documentation.

Another issue with Lambda is that everything goes off the rails if you need to do something that Amazon hasn’t prioritized yet. Let’s say you want a GRPC endpoint, web sockets, http/2, mutual tls authentication, etc. Lambda won’t help you and you’ll be left building up your own patterns for those. Once you have those patterns, then Lambda’s use cases can be satisfied as well.

Also, Lambda doesn’t provide any sla’s on container reuse. They could restart your container multiple times per second or every few minutes. You are at their mercy to keep your containers warm.

Finally, with the meltdown example, would containers actually need to be patched if the parent OS gets patched since the kernels are shared between host and client containers? With Fargate, amazon would patch the base OS and your containers would be safe as they get rescheduled onto patched nodes.

Serverless is nothing more than PaaS - just at a more granular deployment/operation/billing/analytics scale. PaaS has always had a certain amount of lock-in because it's an abstraction, as any abstraction naturally does.

There are also some abstractions like Kubernetes that are neutral yet also managed with extras by all the providers which is a nice middle ground.

None of this is new or groundbreaking other than the silly hype words like "serverless".

I suggest you take a look at https://www.openfaas.com/

It’s a cycle Depending on where you start your argument, one can be the commodity or meta commodity Your point is sort of moot Cloud for next 10 to 20 years, is still about killing old it vendors and make people not worried to put everything they own on cloud. Container or serve less is but major milestones.

Might as well throw away the automobiles and go back to horses, they're cheaper on gas.

Forget that they take more time to care for, and to learn how to ride, and how to feed properly.

Then what is the point of the open source serverless frameworks our there? Or are you making that argument only within the context of aws lambda?

AWS and other managed FaaS offerings allow you to go from zero to endpoint in minutes.

You can choose to deploy your own open source Faas framework (like openwhisk or open-faas) on one of these clouds, but YOU will have to:

1. Manage scaling of underling EC2s

2. Manage security patching of both the docker and underlying OS

3. Setup whole lot of configs

4 manage optimizations

With a managed FaaS you're trading ops for more dev time, but someone has to be paid for the ops - it isn't free