AWS Lambda: monolithic vs single-purpose functions 

An important caveat to add is what Heitor said about "meeting people where they are". For me, starting with single-purpose functions and getting it to work is not hard. In fact, I find it easier to get things to work when I'm starting with just a single function, doing a single thing. Get it to work, then the next thing. But I take Heitor's point that many of his customers are not seasoned AWS user and many are probably working with Lambda for the first time. And getting what they have already to work in Lambda is a good first step, or doing something they're familiar with (ie. building a flask app) in a different environment (ie. in a Lambda function) is a great way to minimize risk and reduce the no. of challenges you take on in one go. That's also the advice I usually give clients who are new to AWS and serverless, to get them to change one thing they do at once, so they don't get overwhelmed by all these changes in one go. For things that I develop myself, then it's a totally different ball game!

@@theburningmonk agree! I've probably made a mistake in what I wanted to say. When clients come with developed on-premise or other server(full) solution - that is easier to move them to serverless starting with fat functions as it usually allows them to move whole modules. But of course, if our client is a relatively young startup - then I'd proceed with a more granular approach, where functions have much much less responsibilities and permissions.

you might not be given time and resources to refactor it later.

While I agree with the evidence-backed argument, I don't see anything wrong with expressing one's personal opinion on something, so long you can back it up with a sound argument and/or evidence. Was there anything that Heitor said in particular that you feel he didn't back up with a good reasoning?

@@theburningmonk I think the reasons for going monolith are too personal and not backed up strong enough (maybe I just failed to understand it). Normally monolith is a pile of spaghetti or (as majority monolith advocates say) "good modular" monolith. As nobody wants a pile of spaghetti lets pick second route and we will end up with "good modular" monolith which already can be deployed as set of lambdas with granular permissions and what is not less important - reasonable resources setup (maybe after power-tuning to find the best one). So what's the point in going fat lambdas then?

@@ValeriyLysencoah I see. Maybe it wasn't called out explicitly, but it was (from my recollection) that, fat lambda meets people where they are in their knowledge level. The other reason that was called out explicitly is that some vendor charge by resource, ie. datadog. So it forces you to consolidate into small no. of functions to save on cost. The other reason he mentioned was specific to Python and packaging. That one, you can definitely solve without resolving to fat functions - both Serverless framework and CDK has solution for this. But maybe it's another argument based on "meeting people where they are"

@@theburningmonk Good point. To me datadog billing issue is a matter of solution design, logs can be published by dedicated logging lambda or logging service, but I do agree here also, this solution needs to be built and it's time and money, and knowledge, so fat lambda will be really effort free solution for any team.

@@ValeriyLysencoI think the specific billing issue is not with Lambda logs, but for their APM solution (basically gives you tracing and cold start analysis, etc.). But that billing model is maddening, I wish they'd change it... Unfortunately, the developers making the system design might not have the final say on the observability provider, so you have to make compromises in your design so not run up a huge bill with datadog.

lol there’s nothing more permanent than a temporary solution