The article has some good points, but just one thing about monolith lambdas. I'm sure this is not an unpopular opinion anymore (not sure if it ever was) but:

The article has some good points, but just one thing about monolith lambdas. I'm sure this is not an unpopular opinion anymore (not sure if it ever was) but: 1. if you build something new, starting with a monolith lambda is OK. Your customers care about a secure, user friendly, performant product, if a monolith lambda gets it, great! 2. your code can be in a monorepo but you can still have have multiple lambdas (running the same code but each with it's own least privilege IAM policy, it's own SLA / reserved concurrency / memory settings) 3. As soon as you have something that is indeed used by more than one service / team, that it can have it's own persistence / authentication / authorization, e.g. something if there was an API/SaaS out there you would "delegate" it to it, this is when you extract a microservice. If you start with designing your microservice architecture for your side project / MVP or even seed stage startup, I applaud you, as you are succeeding in places many failed. You grow into complexity, not start with it on day one. I'm sure many agree with this sentiment but I keep seeing people getting an allergic reaction seeing any hint of mono* in any project.