Live data from Hacker News

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

rehanvdm.com

101–110 of 131 posts

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

#101
post #48

Earlier quoted context omitted.

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? =)

Well, it doesn’t help that AWS counts every part of the path as a resource.

If you start your url like /api/v1/service/endpoint, you immediately have 4 resources.

But yeah, it’s a proper monolith.

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

#102
post #62

Yes, but not only API... We figured out how to get Azure Functions to serve a complete webapp without any extra crap wrapped around it. No gateways/proxies/etc. One function that serves the root URL[0] and has conditionals for GET/POST methods. Beyond this point, anyone with old-school mastery of HTML/CSS/JS can get the rest of the job done with basic-ass SSR and multipart form posts. For data, we just use Azure SQL…

Sounds like a cool hack, but why not just self-host with on-premises hardware, or rent a cloud server from a hosting provider like e.g. Digitalocean? Then you wouldn't have to worry so much about what Microsoft wants, no?

Good old HN, "just self-host with onprem".

Who monitors it 24/7 and checks the alerts? Who drives to the data center to fix broken hardware on Christmas Day? It has to be multiple "whos" or one sick leave will leave you completely vulnerable.

For small-medium companies whose main business isn't hosting software this makes it untenable from a financial point of view. For the monthly salary of a single SRE/devops/admin whatever you can run AWS services for a year at that scale.

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

#103
post #68
post #65

Earlier quoted context omitted.

Do you scale to zero for the resume achievement or to actually save money?

I like to use it for little side projects, then I can leave them alone forever and not have to shut them down.

Yep, I've got a side project running on AWS Lambda + DynamoDB for maybe 5 years now. It's only now getting big enough that I'm no longer on the free tier.

My bills are around $0.02 a month from API Gateway =)

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

#104

The question strikes me as odd. I can't imagine why one would split an API across separate isolated compute nodes. I've used isolated functions in the context of "message orchestration" scenarios, but I'd never do that for an API.

Can't help thinking that a lot of best practice advice from AWS coincidentally maximises your AWS lock-in and billing spend

I've talked to actual AWS representatives face to face. Every time they tell us how we can spend less money.

I've had one tell me that don't try to use this service, it won't work on your use case and if you try to force it, it'll cost you too much to be viable.

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

#105

Earlier quoted context omitted.

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

Just FYI: You can totally scale ECS down to zero. Our ECS bill hovers around $1/mo because we spin it up on demand based on queue size (It takes a painfully long time to spin up, though).

I imagine you can scale literally anything down to zero if availability isn't a concern. ¯\_(ツ)_/¯

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

#106
post #48

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…

Why not 1 ALB in front of a Lambda with a router inside it?

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

#107

Earlier quoted context omitted.

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…

I just can't get my head around this argument of 'scales to zero'. If you have one or more professional developers working on a project how can you be bothered about an extra $20-$200/month when you know you'll also be spending a couple of engineering hours (worth more than $200) on migrating later?

Scales to zero means you can span as many environments as you want and don’t bother. Every dev can have multiple environments to demo features and do experiments.

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

#108
post #91

Earlier quoted context omitted.

How so? Lambdalith means simpler, faster deployments, and easier to run locally.

with lambdalith you miss out on some things like granular IAM roles and granular Memory/Cores config. Also with lambdalith you probably end up needing an application framework as opposed to just using mostly vanilla features of your language of choice. Of course I agree that lambdalith has advantages as well.

I don’t buy this. From the top of my head I can think of many things not handled by the Lambda runtime: session cookies, routes with ids in them like /author/15/posts, having to specify Content-Type for responses, generating error responses properly, etc. Good server framework does this for you transparently.

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

#109
post #7

Earlier quoted context omitted.

And suddenly you have to manage an entire Linux server. (-:

Oh the burden.

SSH keys, security updates, monitoring, access controls just to name a few. How do you stop a former employee from running a bitcoin miner in your servers? How do you detect that hacker has got access to your server?

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

#110

Earlier quoted context omitted.

Sounds like a cool hack, but why not just self-host with on-premises hardware, or rent a cloud server from a hosting provider like e.g. Digitalocean? Then you wouldn't have to worry so much about what Microsoft wants, no?

Good old HN, "just self-host with onprem". Who monitors it 24/7 and checks the alerts? Who drives to the data center to fix broken hardware on Christmas Day? It has to be multiple "whos" or one sick leave will leave you completely vulnerable. For small-medium companies whose main business isn't hosting software this makes it untenable from a financial point of view. For the monthly salary of a single SRE/devops/admin…

Basecamp is a small-medium company and leaving the cloud was a huge win for them: https://world.hey.com/dhh/we-have-left-the-cloud-251760fb
Post reply on HN