Serverless applications' reliance on other proprietary services like Cognito, DynamoDB etc is another thing however...

I feel like even this lock-in is overstated. Those other services are billed based on usage and are completely separate from each other. Your migration path away would be one service at a time.

That's in no way comparable to traditional lock-in, which is like a decades-old Oracle database with high licensing fees paid annually and depended upon by dozens of complex business processes interacting directly and indirectly with each other. You don't really have a migration path in that case because there's not enough time / resources to decouple everything and migrate to something else, so you're stuck.

And that doesn't touch on the reality that if you're not relying on AWS for Lambda, DynamoDB, Kinesis, etc., then you're maintaining something yourself, which itself is not free from lock-in. Building a system that heavily utilizes Cassandra or Kafka may not have an annual licensing cost, but absolutely imposes a cost in terms of maintenance, team expertise, and (of course) makes moving away from them look not much different than moving from DynamoDB or Kinesis.

There's also the fact that most of the code isn't really gone, it's just transformed from web server logic to lambda deployment/configuration logic.

The biggest win all told seems to be security - at least with Lambda you don't need to worry about staying on top of OS updates and the likes. I'm not at all convinced that we gained much of anything else.

Oh, and one thing that's rarely discussed is how much development&qa costs skyrocket when you have a larger team developing a fully serverless application, each with their own setup and running a few performance tests every few months...

It is a drop in replacement for dozens of other authentication providers.

If you are storing the passwords in Cognito and not using federated login, you should be able to insert a lambda trigger that captures the user’s password then authenticates the user with Cognito via code. Once the user is authenticated, store the password in your new store.

Yes that would be a slow process but it isn’t like you couldn’t move everything else off of AWS first and let that be a slow migration over time.

  exports.handler = (event) => ({
    statusCode: 200,
    body: "Hello world: " + event.body
  })

What code gets eliminated in serverless? I have historically done most of my http backends using things like Flask or Sinatra or Elixir or Go (with net/http), and I’ve never felt like there’s a whole lot of code to begin with. What am I missing (if you don’t mind elaborating)?

Compare this to a large application where you are marshalling objects from the HTTP POST request into temp objects inside your application language. Making that work with all clients, within all server contexts, is a lot of code which I hated to write.

With serverless, I'm never connecting my clients or backends directly. I'm thinking in terms of moving high level objects (JSON, files, events) between systems, and Google provides the glue to wire those together. It takes a mind shift, but when you realize how much glue code you are writing and that you can forget, it makes your application layer really simple.

The downside is that you then need to call them via Lambda instead of using some kind of REST API -- however at least in my case, this turns out to be the much lesser evil as I'm only using them internally, and have my own code that makes the calls. My "lock in" is that I would have to change that code, but it's trivial.

You’re always for all practical purposes locked into your infrastructure once your business grows.

With no code changes, you can deploy a standard Node/Express app as either a lambda service or a standard Express app.

There are a frameworks like this from AWS for all supported languages. It’s well documented how to use the API Gateway lambda proxy feature.

For non API lambdas. The only thing you have to do is add an entry point method that takes has two arguments - a JSON event object and a lambda context.

I have another app that can be deployed as a Windows .Net Core service or lambda based on the CI/CD pipeline.

Also, no licence stops you from migrating from Lambda at any moment. Other Companies have you to pay enormous licencing fees and lock you for a one year contract or even longer.