With pay per use, AWS lambda got a lot of attraction in market. It provides lots of benefits but there are things which need to be consider before opting for it. Here we will highlight it’s features, advantage but in same time will provide issues with it.
Some of the benefits include Auto scale, no maintenance of hardware/software and pay for use.
With feature of pay only for execution time it saves lot of cost because you don’t have to keep machines up and running when they are idle. Also, AWS keeps software updated and you don’t need to maintain that, and on top of it lambda automatically scales up to load/requests.
But some of benefits creates problem. Lets see some of issues –
It does work of scaling number of containers as load increase. It does create new container on new request or uses previously created container. In both cases it can be problematic:
- If it creates a new containers it adds latency, clearly not suitable for application which requires immediate response.
- In case where it uses previously created container, you need to be take care code you did, when it reuses it does not reinitialize, initialization remains in the state where it was at the end of previous execution on that container. It can cause issues which are difficult to identify. It is recommended to verify initialized variables/connections to DB etc before using it. But, why someone has to bother about these things, when lambda is just a computing service?
It would had been better if it uses some sort of pool with fresh containers, even allowing user to specify pool sizing/resizing policies.
It automatically manages system resources for you. It provides option to provide memory required for the function and it automatically allocate CPU proportionate to memory. Most of time, you will end up providing higher memory just to get better CPU power, and that adds to billing cost.
Lambda Gateway API
Most of the time you will need to use Gateway API to initiate lambda execution. For example – calling lambda in response to user’s action on your website.
Only way to perform such action is using AWS Gateway API to execute Lambda function. For most of cases it is good enough but for error specific to lambda like timeout etc, it uses HTTP status code to indicate error. Which requires extra development to handles those errors.
This is extra development required to utilize a compute service.
Max execution time limit
It has max limit of 5 minute for any lambda function execution. Mostly, people want to use such computing service to run long running batch, but because of this limit it is not suited for such application. Not sure why they just have such limit in place (could be to provision infrastructure internally). It should be customizable or some higher value taking into consideration of long running batch jobs.
I am sure, things will improve in future on AWS lambda mainly better control to user to specify configuration/limits.
To conclude, following are services which are suitable and not suitable for AWS lambda –
Suitable applications/services (with assumption of 5 minute execution time limit)-
- Micro services
- Actions on event like S3 event
- Application which does not need real time, no latency response. examples – order processing, inventory management, billing application, so on..
- Small batch jobs which can finish in given time or can be coded to adopt lambda execution time limit like if a batch process handles 1 million records, breaking it to set of lambda function each working on a subset of data which can be processed in 5 minute
Not suitable applications/services –
- Real time, low latency applications like stock market, real time streaming
- Batch processes which need more than 5 minutes and which you (should) don’t want to break in smaller processes.
- When your load is steady throughout the day, you can use dedicated instances with auto scaling to scale up/down as per load. It would not make much difference in cost if you use lambda in this case.