Hacker News Reader

Comment by x86_64Ubuntu | Hacker News Reader

Is anyone else worried about the proliferation of disjoint processes that people can whip up using Serverless? At least with a monolith, you've got a relatively coherent grouped together codebase. But with Serverless, you can have some lambda that is infinitely important, but not documented or well known to anyone else in the org.

View on HN

If you deploy enough Lambdas that depend on each other you effectively end up with a monolith, but the call paths are done through HTTP instead of method dispatch. Arguably this is worse, since discoverability and modification can become extremely difficult.

I think it all depends on how searchable and generally well-maintained the codebase is. Having some obscure critical function hidden in a monolith is totally possible too.

Serverless and microservices aren’t the same thing. You can deploy a monolith to lambda, and make a thousand small services on VMs or orchestration platforms. It’s purely a question of how to organise your code.

I'd say that is misleading at best. Lambdas are inherently unsuited for monoliths due to payload, RAM and execution time limits and cold start times. Lambdas are inherently suited to "real" micro-services, because by nature can only do 1 thing and have strict limits.

Depends entirely on workload - there's 3GB RAM available, which is more than what we use for normal monoliths on Heroku. Payload limits are 6MB or something, which isn't hit for a majority of sites on the internet (each request, not total page size). And there's nothing in the nature of Lambdas that force them to do only one thing. HTTP events can be fed through the normal router (lots of adapters for many web frameworks out there). Non-HTTP events can either go through a switch-case-board. There's no inherent "nature" to lambda, it'll execute whatever code you give it. There are limitations, but those are constantly changing.

Reply on news.ycombinator.com