Some code is more equal than others

AWSLambdaDaily Email

“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

Originally published .

Other articles you might enjoy:

Free Email Course

How to transition your team to a serverless-first mindset

In this 5-day email course, you’ll learn:

  • Lesson 1: Why serverless is inevitable
  • Lesson 2: How to identify a candidate project for your first serverless application
  • Lesson 3: How to compose the building blocks that AWS provides
  • Lesson 4: Common mistakes to avoid when building your first serverless application
  • Lesson 5: How to break ground on your first serverless project

    ☎️ Serverless AMA

    Need quick guidance on a specific issue on your AWS serverless project? Or just wondering where to start with serverless?

    Book a call and ask me anything.

    Learn more >>

    🛫 Serverless Launchpad

    Ready to start building your new AWS serverless project but need help with getting everything setup?

    The Serverless Launchpad is a done-for-you DevOps service installed in under a week. You get a leading-practice multi-account AWS environment, a scaffolded codebase and architecture including the common AWS serverless services, isolated cloud environments for individual developers, automated delivery pipelines right through to production and much more. Everything is IaC, extensively documented and handed over to your developers.

    Learn more >>