Profile picture
🦄 Paul Johnston 🦄 @PaulDJohnston
, 20 tweets, 3 min read Read on Twitter
THREAD: A good practice is for each AWS Lambda function to do one thing rather than bundle all functionality into one function.

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
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to 🦄 Paul Johnston 🦄
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member and get exclusive features!

Premium member ($3.00/month or $30.00/year)

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!