Are We Making Lambda Too Hard?

Hot take alert! Some of the “best practices” we’re seeing nowadays are taking the simplicity of Lambda and throwing it right out the door.

You may or may not know that I run a weekly serverless newsletter. The newsletter compiles the best serverless content every week and gives a summary with my thoughts.

I love doing it — it’s a great way to stay up to date on all the new feature releases and keep up with trending topics. While I won’t claim I read all content around serverless, I will claim that I read the majority of it. This has given me a pretty good indication of what people are doing at their jobs, how they are set up, and what people are pushing as best practices nowadays.

I’m beginning to see a trend that I’m not sure I like… yet. There have been quite a few posts lately about how people recommend structuring Lambda-heavy projects. They talk about the different layers of code, responsibility separation, and code reusability. While these things might sound like no-brainers, it’s beginning to make Lambda development feel a bit complex and bring in some habits that seem to fight against the modularity and simplicity the service provides.

Thinking Idealistically

When I think of a perfect environment for Lambda, a few key components come to mind:

• Simple
• Modular
• Isolated
• Up-to-date

Simple

Before I open the handler for a Lambda function, I want to know what problem it’s solving. Intuitive file or folder names are a must to quickly identify where code lives if you need to make an enhancement or fix a bug.

When I first started getting into serverless, I had many people ask me “how do you manage all those Lambda functions?” My first answer was that serverless apps are built in code and Infrastructure as Code (IaC), not through clicking around in the AWS console. On top of that, apps are generally composed of many microservices, each with the functions that support that service — meaning all functions aren’t kept in the same location and are easier to manage.