Hacker News Reader

Comment by reilly3000 | Hacker News Reader

With Fargate Savings Plans and Spot Instances, the cost of running workloads on Fargate is getting substantially cheaper, and with the exception of extremely bursty workloads, much more consistently performant vs Lambda. The cost of provisioning Lambda capacity as well as paying for the compute time on that capacity means Fargate is even more appealing for high volume workloads.

The new pricing page for lambda ("Example 2") shows the cost for a 100M invocation/month workload with provisioned capacity for $542/month. For that same cost you could run ~61 Fargate instances (0.25 CPU, 0.5GB RAM) 24/7 for the same price, or ~160 instances with spot. For context I have ran a simple NodeJS workload on both Lambda and Fargate, and was able to handle 100M events/mo with just 3 instances.

Serverless developers take note: its time to learn Docker and how to write a task-definition.json.

View on HN

Dollar to dollar comparisons are one way to compare these two technologies but it leaves a lot not covered. The application programming model varies greatly (socket/port vs. event). There's also a lot more that Lambda brings to the table in terms of monitoring, logging, etc that you'd need to do work yourself to enable.

Fargate is a great product, but it doesn't completely remove all operational work to the degree that Lambda does.

Agreed. For the vast majority of cases, a Lambda function is easier to ship and maintain, and most likely dramatically cheaper. I really only think the value of using Fargate kicks in compared to Lambda at around 5M+ invocations/month. YMMV based on workflow and workload.

You are comparing only the costs of running them, what about the cost of developers who build/debug/troubleshoot the container. As someone who is running both on Lambda and Fragate it's way harder to make things tick on Fargate

It also depends a lot on the nature of the workload. For IO bound workloads (like most web services), Fargate can easily be an order of magnitude cheaper than Lambda. But if your task is soaking the CPU then you can really get your money's worth out of Lambda.

I agree, but you don’t need to learn how to use a task-definition file. I would actually advise against it. You can create your entire Fargate environment with CloudFormation.

You can also create your entire Fargate environment in a couple lines of TypeScript / Python / Java code using the AWS Cloud Development Kit. The AWS CDK is a declarative SDK that generates and deploys CloudFormation on your behalf, while offering you prebuilt patterns for many common deployment architectures: https://docs.aws.amazon.com/cdk/latest/guide/ecs_example.htm...

That’s cool. I never played with CDK. One issue I had with using CloudFormation was that when I built the Docker file with a tag of :latest and then ran the CF Template, CloudFormation doesn’t perform any updates because the template didn’t change.

Luckily we use CodeBuild and Octopus Deploy. I was able to use the CodeBuild build number environment variable to tag the Docker container, to specify the Octopus build number and use an Octopus Deploy variable in the CF template to force unique and consistent tags.

It was mentioned today in the serverless leadership session that savings plan is coming to Lambda too.

Reply on news.ycombinator.com