The whole stack of waiterio.com runs on AWS Lambda.
We do use several Monolith lambdas and it works well.
I believe the reason why Lambda has seen so little adoption is because cloud architects suggest to break existing services into a Lambda function for each endpoint.
This causes an explosion of complexity and code that runs in the cloud in one way but it can't be reproduced locally on developer machine easily.
My advice is the opposite:
DO USE MONOLOTHIC LAMBDAS.
CDK(and infra as code in general) is amazing, especially for use cases like this where one would be responsible for deploying and creating resources around 10s of lambdas for one 'service'.
I'm eager to chat with you about CDK since it's kind of new and I don't know anyone else using it.
Feel free to write me at giorgio DOT zamparelli AT gmail DOT com to chat about CDK, Lambda, serverless, Infrastructure as Code.
You might want to edit that comment and speak towards cold start times, dependency management, your deployment strategy (e.g. are you using a docker image lambda or zip, etc) and what you're paying for provisioned concurrency to keep those big lambdas warm and available. That's all nuance you're missing from promoting monolith lambdas, and those kinds of things will get the non-architect-minded in hot water.
We use node.js and the cold start times are negligible.
Java, C# and docker based lambdas have problems with cold start times but we do not suffer from them.
We also use JAMstack and our html pages are statically generated in advance with Cloudfront CDN in front.
We use Lambda for the backend REST JSON APIs.
I believe the reason why Lambda has seen so little adoption is because cloud architects suggest to break existing services into a Lambda function for each endpoint. This causes an explosion of complexity and code that runs in the cloud in one way but it can't be reproduced locally on developer machine easily.
My advice is the opposite: DO USE MONOLOTHIC LAMBDAS.