Hacker News Reader

Comment by gazzini | Hacker News Reader

I loved reading serverless-stack a couple of years ago; it was really helpful & convinced me to use serverless for a side-project that’s still going (with almost no expenses!).

I’m surprised to hear how many separate lambda functions each service in your example had. I understand the need to deploy each service independently... but to have +10 deployments within each service seems crazy to me. Is there a reason each service needs so many lambdas (vs deploying the service code as a single lambda function with different branches)?

Fwiw, I found it possible to get quite far with a single monolithic lambda function that defined multiple “routes” within it, similar to how an Express server would define routes & middleware.

Anyways, thanks for writing that PDF, and good luck with Seed!

View on HN

One problem with monolithic functions is that you must grant them a union of all the rights required by every code branch in the monolith.

Obviously this can expand the blast radius of any vulnerability and tends to encourage rougher grained privilege grants.

This is getting out of hand. Are there "monolithic" and "micro" functions now?

That made me chuckle. But to be fair, in this case "monolithic" function is just a way to describe this pattern of moving your entire app (express in this case), inside a Lambda function. When Lambda started to become popular, this was the most common way to migrate to it. Just move your monolithic app to a function, hence "monolithic" functions.

Exactly, this is as opposed to processing the narrowly defined event with a minimally purposed function with least privilege.

"microlithic" a micro service which bundles multiple responsibilites.

That's brilliant!

Thank you for the kind words about Serverless Stack. Frank and I poured ourselves into creating it. So it makes me really happy when I hear that it ended up being helpful.

On the Lambdas per service front, the express server inside a Lambda function does work. A lot of our customers (and Seed itself) have APIs that need to have lower response times. And individually packaging them using Webpack or esbuild ends being the best way to do it. So you'll split each endpoint into a Lambda.

I just think the build systems shouldn't limit the architectural choices.

Frank here from Seed. Just wanted to add that when you have a monolithic Lambda, multiple routes would share a CloudWatch log group, metric, and share a common node in x-ray. On the flip side, the advantage of having separate Lambda functions handling each route lets you leverage other AWS services better.

Reply on news.ycombinator.com