AWS Lambda- Some Drawbacks and Workarounds

You might have heard about serverless architecture or serverless applications. They basically refer to an approach where applications are run either using third-party services or on containers especially and temporarily created for executing particular functions. This approach is also known as Function as a Service (FaaS) for from the point of the developer all they need to focus on is developing the function while every other hardware requirement is taken care of by the architecture. There are many advantages to serverless applications. Perhaps the most attractive of them is the rapid and automatic scaling that it enables. It also has significant cost advantages as one pays only for what you use, you are charged based on requests and function execution duration. All of this makes server-less architecture very attractive to clients. However, there are also a number of drawbacks that might not be immediately apparent. Having worked with AWS Lambda for a number of projects I have come across a number of such drawbacks and in this blog post, I would like to point out some of the biggest such drawbacks along with workarounds for each drawback. In my experience, the three biggest drawbacks of working with AWS are the following:

• Cold Start: As already mentioned, serverless architecture executes commands and functions on temporarily created containers. So for instance, take the case of a simple function such as a client registering their details. In this case, as soon as the client submits his or her information to the Lambda function, AWS Lambda will create a temporary container, deploy all dependencies and run the required code. After the request is completed, the container is destroyed.

However, starting up or creating this temporary container can take between 100 milliseconds to 2 minutes and it is this delay which is known as a cold start. The workaround for this is an approach known as the warm start. To achieve this, you will need to ping your Lambda after every 5 minutes so that the container is not destroyed. So even if it takes two minutes to start the first time, all subsequent requests get executed within 100 milliseconds.

• Computational Restrictions: Being based on these temporarily created containers, the usable memory is limited to about 2GB of RAM and the time to about 5 minutes for your Lambda to execute. This means that functions which require a lot of processing cannot be handled by AWS Lambda.

However, there is a workaround for this as well. That is to use a step function or a queuing process to break up your work into a series of smaller functions and execute them using AWS Lambda. Another way would be submitting the request from your lambda to AWS Batch for long running processes.

• Vendor control and vendor lock-in: One of the issues about using AWS Lambda is that the third-party applications used or the Hardware and Software patches etc. all get to be decided by AWS. Thus, working with AWS Lambda means giving away a lot of control over your application.

There is also the aspect of vendor lock-in as once you have built up your own operations around a serverless application like AWS Lambda it can be costly, time-consuming and difficult to port your operations elsewhere. There is, of course, a workaround for this and it is to create a separate function for your business logic and then call that function from your Lambda handler. Once this separation is made, you can at any time remove the Lambda and go straight to your function. Serverless frameworks like Zappa lets you deploy your WSGI apps to AWS Lambda. Unfortunately, while there is a workaround for vendor lock-in, there is no such workaround for vendor control.

• Issues with working in a Virtual Private Cloud: Many clients use a Virtual Private Cloud (VPC) for applications or processes which need an extra layer of security. However, if your Lambda needs to work with any such function which resides within a VPC, it cannot then talk to any other resources which are outside the VPC. In such cases, using AWS Lambda also entails some additional delay over and above the cold start mentioned above as the VPC creates something called ENIs or Elastic Network Interfaces for security purposes and this takes some time.

This too can be dealt with using a warm start. The above is just an indicative list of some of the top disadvantages or issues I have faced when working with AWS Lambda. Have you faced any of these issues? What are the typical workarounds you use? I’d love to know what your thoughts about AWS Lambda are, so please do comment below and share your thoughts.