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

51–60 of 131 posts

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

#51

Post by scarface_74 »

andrewstuart wrote: post #24
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…

It’s fiction that configuring the cloud is easier than configuring a computer. I’ve worked at big companies with smart people who burn days and weeks trying to get IAM, gateways, vpcs, firewalls and lambda to play together. Let alone the ongoing nightmare of ops/dev interaction. Complete cloud fiction. The worst problem is the giant pile of cloud spaghetti you end up with and no one has any idea what connects to what…

Your people may be “smart”. But they aren’t “experienced”.

Did they use the CDK or even SAM?

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

#52

Post by scarface_74 »

brap wrote: post #14
Cyriou wrote: post #11

Earlier quoted context omitted.

Say I am building a marketplace which I plan: will get many users. Also, we are only 2 building it. I am pretty sure this is way more expansive to spend engineering time making it possible for server(s) to scale using kubernetes and stuff, than just using serverless. And later with many users, we estimate what better be implemented manually to save money, because at this point it would actually save us money to emplo…

It's not all or nothing, there are in-between approaches. For example you can write your portable app in Node.js (with or without containerization) and push it to a "serverless" PaaS, without running your own linux machine or worrying about k8s. e.g Fly.io, Render, Railway...

Yes I’m going to tell my CTO to use any of those solutions and immediately be laughed out of the room.

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

#53

Post by solatic »

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.

If you want to run node, why a full-blown VM and not a container?

> Learn how to, you know, run software on a Linux computer.

I know how to, I run NixOS at home. If you own the VM, you own the maintenance on the VM. Optimizing for the cost of setup is usually wrong, most people are better off optimizing for running costs and maintenance.

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

#54

Post by brap »

scarface_74 wrote: post #52
brap wrote: post #14

Earlier quoted context omitted.

It's not all or nothing, there are in-between approaches. For example you can write your portable app in Node.js (with or without containerization) and push it to a "serverless" PaaS, without running your own linux machine or worrying about k8s. e.g Fly.io, Render, Railway...

Yes I’m going to tell my CTO to use any of those solutions and immediately be laughed out of the room.

You might not have a good CTO then

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

#55

Post by time0ut »

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.

The way I have done this in the past is to use an adapter library that maps from the incoming lambda event to whatever framework you are using (like fastify or jax-rs for example). Your code looks like the normal http request handler stuff you would normally write, but it isn’t running an http server inside the lambda beyond whatever stuff AWS does under the covers of course. I’ve deployed many Lambda based HTTP APIs in this pattern and its my preferred approach to using Lambda, though I would rather target a standard container orchestrator if available.

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

#56

Post by theshrike79 »

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

Earlier quoted context omitted.

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.

No no, you're doing it wrong if you've got Lambdas calling Lambdas. That's not a monolith, that's a shitty microservice that'll get really expensive real fast :D

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

#57

Post by theshrike79 »

dgroshev wrote: post #44
theshrike79 wrote: post #37

Earlier quoted context omitted.

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.

It depends on your schema, I've worked with systems where we have multiple clients in a single system, the data was separated with per-client views.

And it also depends whether the database is MSSQL ($2k/month on AWS) or something like Aurora.

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

#58

Post by theshrike79 »

Aeolun wrote: post #48
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 reso…

200 endpoints? Sheeesh. I've never seen anything over 50.

That must've been a proper monolith then? =)

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

#59

Post by ezfe »

andrewstuart wrote: post #10
HyprMusic wrote: post #9

Earlier quoted context omitted.

There are plenty of cases where lambda is a better fit than hosting a server. Just like there are plenty of cases where it's not an appropriate fit. By flat out refusing to consider it, you become as much of a "drone" as the people you call out.

>> There are plenty of cases where lambda is a better fit than hosting a server. Such as? If it’s regional latency then run a machine in the region.

Simple endpoints that have extremely low-volume traffic. If I have a project that has low usage and requires basic endpoints to handle server-side logic, lambdas are by far the cheapest way to do it and fully performant.

I use Cloudflare Workers on hobby projects to provide server side work for things that have low volume, because the price is so low per user.

It's true that Lambdas will become pricier with consistent high volume usage, but for extremely variable usage or low usage, lambdas are a great option.

Post reply on HN