Seriously, the reason you use lambdas is that they're small self-contained chunks of functionality that you need to scale out.
Let's take an easy example: you want to ingest tracking metrics.
You can write this as a server or as a lambda. For a server you'd listen on port 80 for POST or GET requests, then take that and write it to your data store. You can do this pretty easily in express/node.
Now the question is, how do you scale that up to a few hundred requests per second? How concurrent is your express app? Are you going to run out of memory on your server because you didn't set the TCP buffer sizes for server sized usage? How do you take your service offline for upgrades/updates? Are you going to crush your database/datastore with hundreds of writes a second? If your ISP barfs are you OK with losing data for that time period? What happens when all of your clients try to connect at once because of a regional power failure?
From a code point of view, what if some random change in your code somewhere causes your ingestion stuff to fail?
Seriously, you don't have to deal with any of this crap if you don't want to. For 1 request every few seconds who cares what you use. But once you start scaling your problems with a server side solution become more and more work to handle.
Again, if you don't need scale don't use AWS. You can always do it cheaper with a server from lowendbox.com.
As for vendor lock-in, well, it's trivial to design your lambdas so you can drop them into a server-side solution (or vice versa). And when you think of vendor lock-in you have to consider also that a bespoke solution is locking in you as the vendor.
I've inherited an high rps API built with api gateway + lambda + dynamodb and I've found easier and way cheaper to move the thing on ec2. Less headaches too.
Resources can be managed more efficiently, cold starts are not a thing, you have predictable latencies, it does serve way more concurrent requests at a fraction of the cost.
I go for lambda when i need a service that can scale down, but not when i need to scale up efficiently.
Debugging is easier, connection pooling is not an accident, processes' limits and isolation can be managed anyway.
Seriously, the reason you use lambdas is that they're small self-contained chunks of functionality that you need to scale out.
Let's take an easy example: you want to ingest tracking metrics.
You can write this as a server or as a lambda. For a server you'd listen on port 80 for POST or GET requests, then take that and write it to your data store. You can do this pretty easily in express/node.
Now the question is, how do you scale that up to a few hundred requests per second? How concurrent is your express app? Are you going to run out of memory on your server because you didn't set the TCP buffer sizes for server sized usage? How do you take your service offline for upgrades/updates? Are you going to crush your database/datastore with hundreds of writes a second? If your ISP barfs are you OK with losing data for that time period? What happens when all of your clients try to connect at once because of a regional power failure?
From a code point of view, what if some random change in your code somewhere causes your ingestion stuff to fail?
Seriously, you don't have to deal with any of this crap if you don't want to. For 1 request every few seconds who cares what you use. But once you start scaling your problems with a server side solution become more and more work to handle.
Again, if you don't need scale don't use AWS. You can always do it cheaper with a server from lowendbox.com.
As for vendor lock-in, well, it's trivial to design your lambdas so you can drop them into a server-side solution (or vice versa). And when you think of vendor lock-in you have to consider also that a bespoke solution is locking in you as the vendor.