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.
- 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.
- 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.
- 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.