4 ms·
So the way we're using this is this: * We write our HTTP services and package them in containers. * We add the Lambda Web Adapter into the Dockerfile. * We p
by sudhirj 2y ago
So the way we're using this is this:
* We write our HTTP services and package them in containers.
* We add the Lambda Web Adapter into the Dockerfile.
* We push the image to ECR.
* There's a hook lambda that creates a service on ECS/Fargate (the first-party Kubernetes equivalent on AWS) and a lambda.
* Both are prepped to receive traffic from the ALB, but only one of them is activated.
For services that make sense on lambda, they ALB routes traffic to the lambda, otherwise to the service.
The other comments here have more detailed arguments over which service would do better where, but the decision making tree is a bit like this:
* is this a service with very few invocations? Probably use lambda.
* is there constant load on this service? Probably use the service.
* if load is mixed or if there's are lot of idle time in the request handling flow, figure out the inflection point at which a service would be cheaper. And run that.
While we wish there was a fully automated way to do this, this is working well for us.
- mfreeman451 2y ago[dead]
- wavemode 2y agoI guess the part I don't get is, if your traffic is that low, doesn't that mean you could run the service on a ~$4/month instance anyway? Even if we assume the lambda option is cheaper, it's only cheaper by pennies, basically. In exchange for taking on a bunch of added complexity.
- bubblyworld 2y agoNot the OP, but things can be infrequent and bursty, or infrequent and expensive, or infrequent and memory-intensive. In those cases (and many more I'm sure) lambda can make sense.
- sudhirj 2y agoSort of, but two things add up - lots of little services (I don't like the microservices word), but we do make small services for the workloads that make sense to run and maintain independently. The other is burst, we run a business where customers send us a couple hundred thousand things to do just once a week or once a day. And of course we don't know exactly when the orders will come in. Much easier to let the lambdas run than have large running servers waiting. Autoscaling is possible, of course, but laggy autoscaling won't work, and aggressive autoscaling is basically lambda.
- jbmsf 2y agoI like the idea. The main thing I'd want to adopt this design is a comparable ability to inject environment variable secrets into lambda that ECS offers. It'd also be nice to have a better log aggregation strategy for lambda than scraping cloudwatch, but that feels less important.
- sudhirj 2y agoWe do have environment variable injection, that's mostly what the hook lambda does. Same envvars are injected into both the lambda and the ECS task definition.