3 ms·

If you have a monolithic entrypoint, is it really serverless? You're simply using the Lambda infra as a run-on-demand server, something Heroku has been offering

If you have a monolithic entrypoint, is it really serverless? You're simply using the Lambda infra as a run-on-demand server, something Heroku has been offering for 10+ years. Why would you pay extra when you can deploy to a simple VM or managed platform costing 100x less?

rhodysurf 4y ago
Because it doesn’t actually cost less? You have to have a LOT of invocations to match the cost of the entry level 6 dollar digital ocean box. And with that you have to manage that box vs serverless you don’t have to spend engineering time (which costs an order of magnitude more) on maintenance, a big deal for small shops without dedicated/capable ops teams.
lukevp 4y ago
What you described would be more akin to using ECS Fargate to run the workload. What they described sounds like a single .NET lambda behind API Gateway, so the infrastructure of ingesting requests (and handling TLS termination, DDoS mitigation, WAF, etc.) all happens on the AWS side. All you have to do is handle the routing inside of the lambda using regular ASP.NET Core. It would also scale up infinitely and down to zero with no work on their end. This isn’t similar to running something on Heroku on an allocated server with fixed overhead at all.
- ricardobeat 4y ago
  Indeed it would be more like Fargate in terms of container runtime vs lambda runtime, but the line between those is pretty blurry. Fly.io for example does containers but they spawn faster than some cloud function platforms. It's not really relevant for the discussion. > Heroku on an allocated server with fixed overhead at all I don't think you're familiar with Heroku then? I'm not talking about dedicated or managed servers. That's exactly what their 'dynos' platform has been doing since ~2008, though less granular: https://www.heroku.com/dynos/scaling https://www.heroku.com/dynos/scaling "All you have to do is handle the routing inside of the lambda using regular ASP.NET Core" also applies to both fly.io and Heroku. That's what I'm getting at. If you don't have a collection of independent cloud functions to execute, and you are spinning up a little monolith for every request, the platform seems like overkill.
romanhn 4y ago
What makes it serverless is the ability to spin up instances on demand (including down to zero when not in use), while paying only when the resources are in use. Given Lambda's generous free tier, I'm literally paying nothing for it. That would not be the case for any other platform.

rhodysurf 4y ago

Because it doesn’t actually cost less? You have to have a LOT of invocations to match the cost of the entry level 6 dollar digital ocean box. And with that you have to manage that box vs serverless you don’t have to spend engineering time (which costs an order of magnitude more) on maintenance, a big deal for small shops without dedicated/capable ops teams.

lukevp 4y ago

What you described would be more akin to using ECS Fargate to run the workload. What they described sounds like a single .NET lambda behind API Gateway, so the infrastructure of ingesting requests (and handling TLS termination, DDoS mitigation, WAF, etc.) all happens on the AWS side. All you have to do is handle the routing inside of the lambda using regular ASP.NET Core. It would also scale up infinitely and down to zero with no work on their end. This isn’t similar to running something on Heroku on an allocated server with fixed overhead at all.

ricardobeat 4y ago
Indeed it would be more like Fargate in terms of container runtime vs lambda runtime, but the line between those is pretty blurry. Fly.io for example does containers but they spawn faster than some cloud function platforms. It's not really relevant for the discussion. > Heroku on an allocated server with fixed overhead at all I don't think you're familiar with Heroku then? I'm not talking about dedicated or managed servers. That's exactly what their 'dynos' platform has been doing since ~2008, though less granular: https://www.heroku.com/dynos/scaling https://www.heroku.com/dynos/scaling "All you have to do is handle the routing inside of the lambda using regular ASP.NET Core" also applies to both fly.io and Heroku. That's what I'm getting at. If you don't have a collection of independent cloud functions to execute, and you are spinning up a little monolith for every request, the platform seems like overkill.

romanhn 4y ago

What makes it serverless is the ability to spin up instances on demand (including down to zero when not in use), while paying only when the resources are in use. Given Lambda's generous free tier, I'm literally paying nothing for it. That would not be the case for any other platform.