Some code is more equal than others

“Code is a liability. Keep it to a minimum.”

This is a commandment in the Serverless Manifesto, and one whose underlying spirit I strongly endorse.

Software engineers’ time is expensive. Code takes time to produce in the first place and likely contains bugs. It needs to be understood and maintained by developers who may not even be on the team yet.

The motivation behind this commandment is to minimise the cost of producing and maintaining your software application over the long term.

But there is a problem. I often see this point being missed by developers who limit their definition of “code”.

Code does not just mean runtime Lambda code

Infrastructure-as-Code (CloudFormation, Serverless Framework, SAM, CDK) is still code.

Custom build and deployment scripts are still code.

Any configuration or code you’re adding via a browser console is still (particularly perilous) code.

VTL mapping templates (that allow you to route API Gateway events directly into other AWS services) are still code.

And what’s more, many of the above may be more complex and costly to build and maintain than the code inside a Lambda function.

While there can be good reasons to have less Lambda functions in your application, if that is at the expense of more of the above, is it worth the trade off? There is no general answer to this but there are a few pros and cons to consider for your case.

Against using a Lambda function:

• You pay for its execution
• Can introduce a small latency
• Requires least-privilege IAM permissions to be determined and configured
• More liable to be compromised

In favour of a Lambda function:

• Usually quicker to author
• Easier to understand across development team as it’s in a common language
• Easier to debug as can add your own logs and monitoring

Don’t paint yourself into a corner

Another important consideration is to think about how future changes may affect your architecture:

“I advise caution when choosing to go functionless, Lambda-less, #nocode. Make sure it’s simple to add a function into the mix when requirements change and your cloud building blocks won’t cover those new reqs.” (Brett Andrews)

The only way to achieve no-code…

Build less features.

You may think that as an architect or developer that it’s not your place to decide this and that instead your job is to find the best way of implementing the features the product team comes up with.

I disagree. If a Product Manager comes to you with a feature that is going to introduce a lot of complexity into your system, then it absolutely is your job to push back and ask “do we really need this?”.

It may turn out out that yes, this is really needed and that’s fine too, but at least the decision is made knowingly with an understanding of the liability the team is taking on.

— Paul