3

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?

New contributor
AKT is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
4
  • there are some downvotes which is fine, but can anyone please comment on what is wrong here? I am looking for any input here positive or negative
    – AKT
    2 days ago
  • I think they are downvoting because the answer to this question is a matter of opinion. Perhaps it would help to break down or quantify the problem, if you can. For example, you could estimate the TCO (total cost of ownership) for both scenarios, then choose the cheaper option. If you think lambdas will be more work to maintain, or maintaining a dedicated server will require additional resource, include those costs in the each of the two estimates before you compare them.
    – John Wu
    yesterday
  • @JohnWu Thanks for the comment. I do get that it is an opinion question because there is nothing stopping me to create multiple functions. My main question is whether there is a certain number after which lamdas don't make sense to maintain. Like if you have more than X lambdas in your app, then you should stay away from it. I'll try to reframe the question to make it more focussed
    – AKT
    yesterday
  • 2
    I feel something fundamental is missing either about the CI/CD process or IaC configuration management -- specifically it sounds as if the SAM templates are generated automatically from an EventBridge trigger? If so, something feels awfully wrong about that. Those templates represent the version of your infrastructure so they should be stored in source control (that's typically how the IaC would be tagged/versioned, though personally I'm not a fan of using SAM templates directly, I find Terraform to be a far more more developer-friendly alternative). yesterday

1 Answer 1

2

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.

1
  • +1. I had the same realization with a hobby project a year ago. I started building it on googles lamdas and when I started writing the fourth I asked myself the same question as the OP. Now the whole thing (including DB) is running in one VM at a smaller hoster, for a third of the cost.
    – marstato
    11 hours ago

Your Answer

AKT is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.