Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

rehanvdm.com

Post reply on HN
Print view View original

41–50 of 131 posts

Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

#41

Post by theshrike79 »

Yes, you should. Especially if you want to scale up without tons of extra work.

The model of "every function should be a separate Lambda" is just moronic - I've seen people run into hard limits on AWS going all-in on this model.

Instead Build a single executable/library and deploy it as a Lambda function.

Now you have automatic versioning, just push and it's a new version. You can label versions and call them based on labels.

Deploying to prod is just swapping the prod label to a new function. Want to roll back? Swap it back.

Credentials: ran a top10 mobile game backend on AWS Lambda with zero issues using a C# monolith.

Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

#42

Post by theamk »

withinboredom wrote: post #29
diesal11 wrote: post #23

Earlier quoted context omitted.

My company doesn't make more $$$ because i decided to spend a day setting up an EC2 over Lambda or a similar PaaS solution. If anything i've lost valuable time that could be spent elsewhere. Especially when stuff starts going wrong or i have to schedule time to manually apply OS/Runtime security updates. > The cloud has made otherwise smart people into unthinking drones. The cloud has allowed smart people to focus th…

They probably do make more money… actually. At least in net profit. Cost in time to setup a bare metal, production quality k8s cluster with all the bells and whistles from the cloud: 2 weeks and a skill I will have forever. In fact, the second cluster took 4 hours. Monthly cost: $240 per month. Time to spin up a new worker, using cloud compute for elastic load beyond base load: 5 minutes. Base load capabilities: 120i…

We are talking lambdas here, not 1TB ram workers.

I had to run a authenticated webhook forwarder outside of the out firewall. Yes, I could have made a real machine, but I've made a lambda instead. It's costing us less than $2/month and I spend zero energy on maintenance, security checks, etc. And all config is in a single git repo that anyone can read and understand - there is zero chance of someone ssh'ing into server for a quick fix, then forgetting to record what they did.

Real machines are great for heavy loads, but you just cannot beat lambdas for the lightweight stuff.

Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

#44

Post by dgroshev »

theshrike79 wrote: post #37
report-to-trees wrote: post #26

I would argue that instead of starting with a Lambda Monolith and splitting routes out when they need to scale separately, you should be starting with an actual monolith and using Lambdas _only_ when a single route needs to scale separately (in a way that fits lambda). The Lambda Monolith is an unnecessary architecture as far as I'm concerned.

So a separate server running a monolith is not "unnecessary architecture", but a simple Lambda function is? With a Lambda function you can have a dozen different versions of the same code running simultaneously with zero extra cost and none of them will affect each other's performance. Every one of them will be versioned and you can instantly roll back to any version or pick any version to be "production".

You can't if you have even moderately complex storage (like an SQL database). There is only one version of that, and while you can make sure that you can run one other version in parallel, it's just one version and a lot of extra complexity.

Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

#45

Post by [deleted] »

theshrike79 wrote: post #37
report-to-trees wrote: post #26

I would argue that instead of starting with a Lambda Monolith and splitting routes out when they need to scale separately, you should be starting with an actual monolith and using Lambdas _only_ when a single route needs to scale separately (in a way that fits lambda). The Lambda Monolith is an unnecessary architecture as far as I'm concerned.

So a separate server running a monolith is not "unnecessary architecture", but a simple Lambda function is? With a Lambda function you can have a dozen different versions of the same code running simultaneously with zero extra cost and none of them will affect each other's performance. Every one of them will be versioned and you can instantly roll back to any version or pick any version to be "production".

[deleted]

Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

#46

Post by report-to-trees »

theshrike79 wrote: post #37
report-to-trees wrote: post #26

I would argue that instead of starting with a Lambda Monolith and splitting routes out when they need to scale separately, you should be starting with an actual monolith and using Lambdas _only_ when a single route needs to scale separately (in a way that fits lambda). The Lambda Monolith is an unnecessary architecture as far as I'm concerned.

So a separate server running a monolith is not "unnecessary architecture", but a simple Lambda function is? With a Lambda function you can have a dozen different versions of the same code running simultaneously with zero extra cost and none of them will affect each other's performance. Every one of them will be versioned and you can instantly roll back to any version or pick any version to be "production".

If you need multiple versions of something running simultaneously then ya lambda might be simpler.

In my experience, running a single monolith server will be much simpler than 20+ lambda "monoliths" that call each other. I think the simplicity of lambdas vs a persistent server looks good on paper but falls apart when you have multiple times more deployments to manage.

Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

#47

Post by Aeolun »

contravariant wrote: post #28

Surely if you're reimplementing an HTTP server inside a function running on an HTTP server then something somewhere has gone horribly wrong.

Maybe when you decided to use lambda in the first place, for sure. But when you are stuck with lambda consolidation is best.

Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

#48

Post by Aeolun »

theshrike79 wrote: post #41

Yes, you should. Especially if you want to scale up without tons of extra work. The model of "every function should be a separate Lambda" is just moronic - I've seen people run into hard limits on AWS going all-in on this model. Instead Build a single executable/library and deploy it as a Lambda function. Now you have automatic versioning, just push and it's a new version. You can label versions and call them based o…

AWS limits are there to be worked around! Have too many lambdas to fit them in a single cloudformation stack? Just split it up into ‘per family’ stacks. Enjoy your nested cloudformation stacks.

Oh, you say you have more than 200 endpoints in your REST API gateway, and suddenly your CloudFormation stop working? Yes, unfortunately CF only load 8 pages of resources in alphabetical order when starting, and your root resource starts with a ‘Y’.

No problem, implement a new custom resource that just creates and discards API gateways until you have one with your desired root resource starting with ‘A-F’. Did I mention the ‘delete a rest api’ API is limited to a single call per minute? The fun doesn’t end. Now you may be able to grow until 600 resources before you’ll have to tighten the limits once again.

You say you think this is bollocks? Of course, just switch to an Application Load Balancer. Just 100 rules max means you’ll only need to nest about 4 of them to fit all your API endpoints.

And people wonder why some give up on the cloud. Any $5 VPS has higher limits than any of these AWS services…

Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

#49

Post by scarface_74 »

contravariant wrote: post #28

Surely if you're reimplementing an HTTP server inside a function running on an HTTP server then something somewhere has gone horribly wrong.

I can tell you a good reason for it. At one company I was working for we had an API that we sold external access to as the back end for large health care providers websites and mobile apps.

But we also used it internally for batch processes.

In one case latency was important so we hosted the app in an auto scaling ECS Fargate cluster behind Nginx and in the other case throughput was important so we could just deploy the same API to Lambda.

Yes I know about reserved concurrency.

Re: Should you use a Lambda Monolith, a.k.a. Lambdalith, for your API?

#50

Post by scarface_74 »

andrewstuart wrote: post #6

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.

How does your proposal add business value - ie “how does it make the beer taste better?”
Post reply on HN