Serverless rules of thumb

“The English phrase rule of thumb refers to a principle with broad application that is not intended to be strictly accurate or reliable for every situation.” [Wikipedia]

As you gain experience building serverless applications and shipping them to production, you may well find yourself in the role of knowledge benefactor helping out your less experienced team mates.

One way to help with these efforts is to build up a bank of “rules of thumb” within your team. While there are many general software development rules of thumb that they’ll already be aware of, the serverless space is still young and such rules of thumb are far from widespread.

Side note on terminology — I deliberately chose the term “rule of thumb” here rather than “best practice”. To me at least, the latter term carries a negative connotation for folks who deviate from it even when they have good reason to do so, which I don’t think is helpful.

Components of a rule of thumb

The following 4 elements make up a good rule of thumb:

1. Recommendation: the “what” of the rule
2. Context: the “when”
3. Motivation: the “why”
4. Exceptions: the “when not”

Let’s look in more detail at each one…

The Recommendation

This is where you define a specific thing that a developer should do. This can be a way of writing code, a structure to follow or an architectural pattern to use. Basically anything that a developer might need to do as part of building an application.

The rule can also define what a developer should not do. This is similar to a smell:

“…a smell is by definition something that’s quick to spot - or sniffable as I’ve recently put it. A long method is a good example of this - just looking at the code and my nose twitches if I see more than a dozen lines of java.
“The second is that smells don’t always indicate a problem. Some long methods are just fine. You have to look deeper to see if there is an underlying problem there - smells aren’t inherently bad on their own - they are often an indicator of a problem rather than the problem themselves.”

When phrasing your recommendation, prefer using qualified language over absolutes, e.g. “you should” instead of “never” or “you must”.

Context is key

When creating your own rules of thumb, defining the context of a recommendation is crucial so that your colleagues know when to apply it. The more specific the better. Some examples in increasing specificity:

• Lambda functions
• Lambda functions triggered from API Gateway
• Lambda functions triggered from API Gateway using Node.js runtime

Tell me why

Your motivation should describe the benefits of following the recommendation, e.g. better performance, more secure, less code to manage. Again, be specific here.

This is really important and often the part that gets left out. Specifying the “what” without the “why” just turns your developers into order-takers. But if you help them to understand the reasoning behind a recommendation, not only will their knowledge grow but they might even challenge or help improve it. I find that even the process of writing down my “why” helps me to refine the recommendation or the context further as my understanding of it deepens.

Exceptions are to be expected

These are sometimes hard to foresee but if you are aware of valid cases where it’s ok to deviate from a recommendation within the defined context, you should include them in your definition.

A worked example

Here’s an example of a rule of thumb that I use:

Recommendation:

A Lambda function should make at most 1 call to a downstream service (DynamoDB, SNS, SQS, etc) when writing data.

Context:

Main body of a Lambda function triggered from an API Gateway PUT/POST/PATCH/DELETE operation within a user-facing API.

Motivation:

The user gets a response very quickly while the data is still persisted safely. Event-driven triggers such as DynamoDB streams or SNS topics can be used to do any further processing asynchronously.

Exceptions:

• Services that are called only once on cold-start (e.g. SSM Parameter Store)
• Transactional-style use cases where user cannot be given acknowledgement until 2 or more downstream systems have been updated.

Do you have any serverless rules of thumb in your team?

Or even rules of thumb that you subconsciously apply but haven’t yet documented? If so, I’d love to hear them, just hit reply and let me know. Also please mention if you’re happy for me to share them in a future email to this list (either with your name attributed or anonymous).

— Paul