4 ms·

Something I don't really get is that if you're going through the trouble of creating a container, why not just run it on fargate or ec2? Is it literally just t

Something I don't really get is that if you're going through the trouble of creating a container, why not just run it on fargate or ec2? Is it literally just the scaling the 0? And you're willing to give up some number of requests that hit cold-start for that?

SahAssar 2y ago
Scaling to 0 means me being able to deploy each branch/PR to a whole, fully separate environment without it costing too much. As soon as you do that everything from testing migrations (via database branching), running full end-to-end tests (including the full infra, db, backend, etc.), having proper previews for people to view when reviewing the changes (like for example the UX designer seeing the whole feature working including the backend/db changes before it going in) just falls into place. If I don't scale to 0 I'd prefer to work on dedicated hardware, anything in-between just doesn't give me enough benefit.
- jiggawatts 2y ago
  You can get a similar effect with Azure App Service, which is basically a cloud hosted managed IIS web farm. A web app is “just” a folder and takes zero resources when idle.
  - deleted 2y ago
    [deleted]
  - ko_pivot 2y ago
    I wouldn’t recommend Azure App Service. Container Apps / AKS / Container Instances / Static Web Apps are all fine services for different use cases, but with App Service you are buying into a pretty strange infra approach compared to traditional FaaS / PaaS / IaaS distinctions. In the past 100% of the time App Service ended up being too weird to debug and another Azure service was a better compute fit.
    - jiggawatts 2y ago
      I'm very curious to hear any war stories you can share...
- Aeolun 2y ago
  > (paraphrase) you can do many things It just costs you the overall quality of your system to do it.
WhyNotHugo 2y ago
The container is useful for running in locally in development. It ensures that you have the same runtime environment (and dependencies) both locally and on AWS.
- Aeolun 2y ago
  To some extend. Lambda making a completely fresh environment for every invocation means you get away with a lot of bad coding that an ECS instance would never allow.
nijave 2y ago
Lambda scales faster if you really do need that. For instance, imagine bursts of 100k requests. Cold start on Lambda is going to be lower than you can autoscale something else.
- ndriscoll 2y ago
  What actually happens is you hit the concurrency limit and return 99k throttling errors, or your lambdas will try to fire up 100k database connections and will again probably just give you 99k-100k errors. Meanwhile a 1 CPU core container would be done with your burst in a few seconds. What in the world needs to handle random bursts from 0 to 100k requests all at once though? I struggle to imagine anything. Lambda might be a decent fit for bursty CPU-intensive work that doesn't need to do IO and can take advantage of multiple cores for a single request, which is not many web applications.
  - chuckadams 2y ago
    If you go from 0 to 100K legit requests in the same instant, any sane architecture will ramp up autoscaling, but not so instantly that it tries to serve every last one of them in that moment. Most of them get throttled. A well-behaved client will back off and retry, and a badly-behaved client can go pound sand. But reality is, if you crank the max instances knob to 100k and they all open DB connections, your DB had better handle 100k connections.
    - ndriscoll 2y ago
      A sane architecture would be running your application on something that has at least the resources of a phone (e.g. 8+ GB RAM), in which case it should just buffer 100k connections without issue if that's what you need/want it to do. A sane application framework has connection pooling to the database built in, so the 100k requests would share ~16-32 connections and your developers never have to think about such things.
      - chuckadams 2y ago
shepherdjerred 2y ago
Serverless is _very_ nice for pet projects where you don't want to pay for an idle server.

SahAssar 2y ago

Scaling to 0 means me being able to deploy each branch/PR to a whole, fully separate environment without it costing too much. As soon as you do that everything from testing migrations (via database branching), running full end-to-end tests (including the full infra, db, backend, etc.), having proper previews for people to view when reviewing the changes (like for example the UX designer seeing the whole feature working including the backend/db changes before it going in) just falls into place. If I don't scale to 0 I'd prefer to work on dedicated hardware, anything in-between just doesn't give me enough benefit.

jiggawatts 2y ago
You can get a similar effect with Azure App Service, which is basically a cloud hosted managed IIS web farm. A web app is “just” a folder and takes zero resources when idle.
- deleted 2y ago
  [deleted]
- ko_pivot 2y ago
  I wouldn’t recommend Azure App Service. Container Apps / AKS / Container Instances / Static Web Apps are all fine services for different use cases, but with App Service you are buying into a pretty strange infra approach compared to traditional FaaS / PaaS / IaaS distinctions. In the past 100% of the time App Service ended up being too weird to debug and another Azure service was a better compute fit.
  - jiggawatts 2y ago
    I'm very curious to hear any war stories you can share...
Aeolun 2y ago
> (paraphrase) you can do many things It just costs you the overall quality of your system to do it.

WhyNotHugo 2y ago

The container is useful for running in locally in development. It ensures that you have the same runtime environment (and dependencies) both locally and on AWS.

Aeolun 2y ago
To some extend. Lambda making a completely fresh environment for every invocation means you get away with a lot of bad coding that an ECS instance would never allow.

nijave 2y ago

Lambda scales faster if you really do need that. For instance, imagine bursts of 100k requests. Cold start on Lambda is going to be lower than you can autoscale something else.

ndriscoll 2y ago
What actually happens is you hit the concurrency limit and return 99k throttling errors, or your lambdas will try to fire up 100k database connections and will again probably just give you 99k-100k errors. Meanwhile a 1 CPU core container would be done with your burst in a few seconds. What in the world needs to handle random bursts from 0 to 100k requests all at once though? I struggle to imagine anything. Lambda might be a decent fit for bursty CPU-intensive work that doesn't need to do IO and can take advantage of multiple cores for a single request, which is not many web applications.
- chuckadams 2y ago
  If you go from 0 to 100K legit requests in the same instant, any sane architecture will ramp up autoscaling, but not so instantly that it tries to serve every last one of them in that moment. Most of them get throttled. A well-behaved client will back off and retry, and a badly-behaved client can go pound sand. But reality is, if you crank the max instances knob to 100k and they all open DB connections, your DB had better handle 100k connections.
  - ndriscoll 2y ago
    A sane architecture would be running your application on something that has at least the resources of a phone (e.g. 8+ GB RAM), in which case it should just buffer 100k connections without issue if that's what you need/want it to do. A sane application framework has connection pooling to the database built in, so the 100k requests would share ~16-32 connections and your developers never have to think about such things.
    - chuckadams 2y ago

shepherdjerred 2y ago

Serverless is _very_ nice for pet projects where you don't want to pay for an idle server.