Live data from Hacker News

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

rehanvdm.com

61–70 of 131 posts

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

#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 Server. Authentication is like sticking legos together now. 100% managed identities, no magic strings, etc. Our functions get the user's claims principal right in the arg list. We have zero lines of authentication code in our latest products.

This stuff is absolutely the future for a vast majority of boring old business.

One thing to think about: If your FaaS offering is capable of serving content-type of application/json, is it not also capable of serving content-type of text/html? Do your providers go out of their way to prevent you from making a simple solve on 99% of B2B bullshit?

[0]: Note that serving the root URL on an Azure Function is an undocumented hack-around item. Worst case, we would serve the /app route and our users (B2B) wouldn't really care. My suspicion is that Microsoft detected our use case and saw that it stole a LOT of thunder from a wide array of other Azure offerings (API Gateway, Front Door, et. al.), so making it slightly more complicated (at first glance) is likely intentional.

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

#64

Earlier quoted context omitted.

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?

I've experienced ansible for managing a fleet of multiple hundred on-prem servers and now I'm experiencing CDK for managing a large infrastructure.

Both suck real bad.

Infrastrucure is hard, thankless work. Complexity blows up whatever you do.

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

#65

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

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

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

#66
post #64

Earlier quoted context omitted.

Your people may be “smart”. But they aren’t “experienced”. Did they use the CDK or even SAM?

I've experienced ansible for managing a fleet of multiple hundred on-prem servers and now I'm experiencing CDK for managing a large infrastructure. Both suck real bad. Infrastrucure is hard, thankless work. Complexity blows up whatever you do.

You literally can tell ChatGPT to create a CDK typescript app that deploys a lambda + API Gateway where the lambda works with Get request and a dynamodb table. The lambda should have permission to read and write to the Table and it will get you 95% there.

Edit: I just did it with ChatGPT 4 expecting it to just create the CDK app. It actually created inline Node sample code as part of the construct for the actual lambda to read from the database.

The last time I did that as a sample to show other developers I still had a little additional prompting to do

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

#67
post #2

We use Lambda monolith usually with a Lambda containing an entire REST JSON API node.js server. It works very well. I feel one of the reason why Lambda did not gain fast market traction is because all the initial tutorials focused on having an endpoint for each lambda, which is actually a special optmization edge case that can come later. Services like Vercel just wrap the Lambda and indeed deploy an entire server to…

> I feel one of the reason why Lambda did not gain fast market traction is because all the initial tutorials focused on having an endpoint for each lambda

A big reason is that lambdas were half-baked and gradually became better. They are still limited.

Sending a binary blob? You have to convert it to base64.

Streaming a response? You can only do that on the nodejs runtime.

Establishing a short-term ws connection? Hard/impossible.

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

#68
post #65

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

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.

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

#69
post #60

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 building is amazing. As soon as one of our projects is large enough, we move it to a dedicated instance or cluster. This allows us to delay that point until we have enough revenue to justify the costs.

Post reply on HN