When and why to use AWS Lambda function. Really confused

Viewed 57

I have gone through this article: When and when not to use aws lambda functions

But still need some clarifications.

What I want to understand is, Can we use AWS Lambda functions for everything, for every backend task? Because Lambda function execution time is 15 minutes and I think that's enough for any task processing.

Lambda can work with AWS services which sends events like AWS Api Gateway, S3, SNS and many more. Even, I have checked that, when web client calls any REST API written using API gateway, we can directly invoke Lambda function without raising any event.

Also, nobody wants idle servers. Everybody wants to pay as per as you go model.

So means, for every backend task, I can use Lambda function? Means, on the backend side, I can have only REST APIs, then lambda function and then Database services.

Is my understanding correct? Or there is any gap?

1 Answers

Picking when to you use Lambda can be confusing, but it really does depend on your use case. Technically you can use Lambda for almost anything. For example you can use recursion to invoke the same Lambda directly or via SQS or any other method to overcome the Lambda timeout. However, this should never be done. You run the risk of not meeting the end condition and running the Lambda for a long time and getting landed with a very costly bill! And it's bad design. Just because you can do it, it doesn't mean you should.

Lambda supports custom images as well, so you can ship the environment you want. Of course, there are limitations, but this feature made Lambda much less restrictive than it was before.

If you are building REST API powered backend services that perform simple CRUD operations, then Lambda is a very attractive technology to work with. However, if you have long running tasks, batch processes or a very active app with almost no idle time, Lambda might not be the right choice. If your application has short, infrequent tasks then Lambda might be a good bet.

You also need to consider pricing. Since Lambda as well as its complementary technologies are charged on usage, the more you use them the more expensive it becomes. At some point an EC2 instance and its complementary technologies would end up being cheaper than using Lambda as these are usually charged by uptime. However, the comparison can usually be done for mature applications which have historical usage data so the figures can be calculated.

The cost and maintenance overhead are quite low for simple CRUD application that use Lambda. However, developing in Lambda is developing in a serverless environment, so you would need to utilize the tech stack you mentioned i.e. EventBridge, SQS, etc. to get the benefits of serverless. And use a framework like serverless or SAM or maybe even a library like AWS CDK for a better developer experience. One major downside of Lambda is that serverless development tools are not as mature as non-serverless development tools. You should consider this too when deciding on your tech stack. However, the tools have come a long way and they are getting better.

I tried to keep this short and hope it helps. Good luck.

Related