Do Lambdas(AWS) stop making sense after a certain number of functions?

Question

I am working on a project and created multiple lambda functions and now I am thinking about whether I made the correct decision to go this route.

Reasons I chose lambda:

• The App will have spiky traffic and almost no traffic at some times, so it is cost-effective
• It seemed like it would be less stressful to update particular functions because I know other functions are not touched and would not break the entire app (creates a setup similar to microservices)
• All APIs on my app are under timeout limits of lambdas so no long-running functions

Reasons I am doubting it now:

• It's difficult to share logic between lambdas like common utility functions and constants, I am using layers but that works fine if I don't have to update the layers too often as I have to upload it manually
• Version control : There is an option to create versions(it's like build tagging) but no easy way to actually create a repository and deploy on changes, this makes it difficult to check what could have gone wrong during a release. I could use AWS CodePipeline, CodeBuild and a trigger using EventBridge that produces SAM template and deploys to lambda using CloudFormation, this solution would work but I don't like how many applications it uses in between to achieve this. And not having version control will make the project unmanageable.

All this has made me think whether lambdas are not great if you have lots of functions and would be better off with a server that always runs and is tempting me to extract all function code and put it on a server. Lambdas are a no-brainer if you have few functions that would rarely run but is it practical to create full applications with multiple APIs?

Answer 1

AWS Lambdas never made any sense.

Or perhaps I should say "serverless applications" never made any sense. Because it seems to me that's what you are doing, moving application code to lambdas for cost reasons.

As you note, actually the lambdas all run on instances that get billed by the hour, so unless you have long periods of nothing running at all you hardly save any money over always having a tiny instance up.

You also have the various complexities you outline, essentially you are forced into a nano-service++ architecture with complex orchestration problems.

Now you can in theory imagine an application where this architecture is ideal, lots of queues, events and mini functions all working together, but in practice its a bit like functional programming. Nice in theory, but difficult to apply to standard "line of business" applications.

In summary, only use Lambdas where you have a specific need for them. Don't use them because the billing model appears different.