[report-to-trees]

I would argue that instead of starting with a Lambda Monolith and splitting routes out when they need to scale separately, you should be starting with an actual monolith and using Lambdas _only_ when a single route needs to scale separately (in a way that fits lambda). The Lambda Monolith is an unnecessary architecture as far as I'm concerned.

[theshrike79]

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".

[report-to-trees]

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.

[theshrike79]

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

[dgroshev]

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.

[theshrike79]

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.