81–90 of 131 posts
I create separate lambdas only when I have some large dependency that can be easily be separated from the rest of the application.
No. It's a gross misuse and misunderstanding of serverless and lambda functionality.
Why lambda? Just run nodejs. The cloud has made otherwise smart people into unthinking drones. You don’t need any of the cloud stuff , except a Linux virtual machine. Stop drinking the cloud kool ade, it’s making things much more complex and expensive for questionable gain. Learn how to, you know, run software on a Linux computer.
Main benefit I see to Linux machine is not having to deal with deprecated run times. With lambda every few years, I have to redeploy my Lambdas when their runtime gets deprecated.
I worked on a small SaaS that deployed in this way. The AWS bill was about 10x what it would have been if they had just deployed nodejs on an EC2 instance.
There's obviously a static load level where it makes more sense to have an always-on server vs. a FaaS and you need to monitor that boundary point. The point of doing something like this "Lambda Monolith" is that transitioning to an always-on server is trivial. I've been doing this exact setup for a while and our static costs basically evaporated. Seeing your costs drop below a dollar/month on a project you are build…
> Seeing your costs drop below a dollar/month on a project you are building is amazing.
Honestly, this just means you don't have any users
Another couple of years and they will reinvent microservices on top of that monolith thingy.
This worked for us because it mitigated the shortcomings of the other two approaches for example:
- lambdalith: very long build times and long deploy times (due to the high number of lambdas)
- one lambda per route: lack of permission granularity (as opposed to creating different IAM roles for different lambdas); lack of granularity for memory/cores configuration means you are missing out on cost optimisation; also, as the API grows, it soon becomes necessary to adopt some framework like Express or Fastify to keep things tidy.
EDIT: reworded last paragraph for clarity.
A few that come to mind:
1) AWS services are not easy to develop with locally. This incentivizes a lot of testing in production, which in turn can slow down development speed and increase defects. Yes there are some wrapper libraries and helpers, but it's not 1:1. (This same thing applies to Cloudflare workers as well).
2) Lambdas have constraints such as execution time limits, and a lack of fine grained control over resource usage. This makes it hard to use things like long lived requests and web sockets. But it can also mean you could end up paying a lot more compared to a fixed price setup, such as an instance in EC2. The flip side is also true: it can be an incredibly good deal as well.
3) There's a lot of tooling and knowledge around Lambda which takes some time to learn. You have to be quite careful around things like DB connections, logging, concurrency, and so on. This overhead might ultimately make things more complicated than a more traditional setup.
4) There is a maximum package size for a lambda. When you include all your dependencies in NodeJS and so on, it can become very tricky to keep things under this size in even a medium sized code base. A larger size also effects your cold start time. There isn't a lot you can do to change this.
5) Lambda's easy integration with other AWS services is both a blessing and a curse. AWS is not cheap, and given how trivial it can be to add on services, it can require a considerable amount of time to reduce spend. Lambda's integration with non-AWS services is very hit or miss (e.g. Kafka). You only find this out by getting very burned.
6) If you require anything like C libraries, be prepared to spend a lot of time working on builds and deployment - or sometimes it just magically works. You are operating inside a somewhat opaque environment, and it can require a lot of fiddling. Additionally, using tools like CloudFormation do not scale very far, and can sometimes result in quite bad outcomes. This stuff can steal a lot of time.
7) There are hidden costs everywhere. For example: Are you being a good engineer and adding a lot of visibility by logging and using tools such as CloudWatch? Be prepared to pay an extraordinary amount relative to the value you get.
8) Using lambda as a processing pipeline? Easy to get started, hard to get reliable. AWS does not have good inexpensive tools to manage these well, and you can end up with a very leaky and expensive system.
9) You would be surprised at how many bugs and weird behaviors exist when these AWS systems play together. In some cases, the only recourse was to delete the entire stack and redeploy because something got stuck. That could be quite bad depending on the use case.
10) Using lambdas over data engineering tools (e.g. Kinesis Data Streams vs Spark) might actually be more complicated. You should hopefully be familiar with and have some experience in this these tools before making a decision when its time to build.
There's nothing stopping someone from taking what we have and porting to an EC2, but for most use cases, this pattern seems to work best.
We break our Lambdas up by how they are used, to keep sizes down, with the option to break up further if we need to.
If you're going to put everything in a single lambda function that's continually serving HTTP requests, you might as well look at ECS.
ECS doesn't a) scale to zero b) scale up to infinity near-instantly. Source: I've rand both a Lambda Monolith and ECS on production and would pick Lambda any day
yes we have some very spiky workloads and we got bitten by that, subsequently we moved away from ECS for this exact reason