Thread by @PaulDJohnston

THREAD: A good practice is for each AWS Lambda function to do one thing rather than bundle all functionality into one function.

Why?

A quick answer is that the smaller the Lambda function, the faster it will load and the quicker it should run (depending on libraries etc), but that's very simplistic

Let's take a slightly more businesslike view of #serverless

A better answer is that making each Lambda function do only one thing improves both your feature velocity and your ability to apportion development resource

Say you have 10 Lambda functions. One function runs on average for 10 seconds and has 1GB of memory.

Say another of those 10 Lambda functions runs on average for 500ms and has 512MB of memory.

Which do you optimise first? Actually, you don't have enough information to answer that.

Let's say that the 10s/1GB function is equivalent to 1% of the monthly cost of the 500ms/512MB function.

Which do you optimise now?

The 500ms/512MB function of course. The one that looks least optimised *from a code point of view* is actually almost an irrelevance in your business model.

If you bundle all your functionality into one function, you lose the ability to optimise like this as easily because you can't simply equate development effort to business value

I mean, you could split out via metrics, but it wouldn't be anywhere near as clear or straight forward

This is what it means when the #serverless model should impact on your development practices and behaviours

There is almost zero business impact and value in optimising code that is doing it's job and not impacting the bottom line

How often does a developer refactor code? Can you point to whether that refactoring is actually of value to the business or not?

It's perfectly reasonable to have ugly code in a Lambda function, that runs infrequently as part of your stack for a long period of time. If it isn't broken, then don't fix it.

Another aspect to consider is that if your Lambda code is ugly, but is only doing one thing, then it stands to reason that it'll be easier to fix, or rewrite at a later date, even if it's a new developer doing it - it's not impacting elsewhere

Ugly code in a monolithic/larger code base can cause major issues. This is how technical debt can become accumulated over time.

This is why you should separate out your #serverless functionality into multiple functions.

This is why CIOs/CTOs/CFOs should be really excited by #serverless because it can allow you to focus your development effort on areas that can immediately impact a bottom line /THREAD