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 and cost saving. With feature of pay only for execution time it saves lot of cost because you don’t have to keep machine up and running when it is idle. Second, AWS keeps software updated and you don’t need to maintain that, and on top of it lambda automatically scales up to load/request required.
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 create issues which are difficult to identify. It is recommended to verify initialized variables/connections to DB etc before using it. But, why someone have to bother about these things, when lambda is just a computing service?
It would been better if it uses some sort of pool with fresh containers, even allowing user to specify pool sizing policies.
It automatically manages system resources for you. What you have to do is provide memory required for
execution of function. 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 online bidding website -on new bid you have to adjust many things in system.
Only way to perform such action is using Lambda Gateway API to execute Lambda function. This API is not standard HTTP API, it wraps HTTP and provides custom status codes etc. Internal AWS lambda error and handling of those is an extra burden on developers.
Now again, it is a compute service, why one will bother about study and do development to use a deployment 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 to provision hardware internally) or atleast this should be customizable or some higher value taking into consideration of long running batch jobs.
Some of the application which suited for lambda environment are Event based actions, Batch jobs, Crons (which can finish within 5 minutes)
Never run application which requires quick and predictable response time.
I am sure, things will improve in future on AWS lambda, mainly Gateway API and better control to user to specify configuration/limits but I personally see it is a computing infrastructure and I will never ask my development team to code to use compute service.