AWS Lambda

AWS Lambda is a serverless, event-driven compute 💻 service that lets us run code for virtually any type of application or backend service without provisioning or managing servers. It’s basically a serverless counterpart of traditional on-premise and cloud servers (e.g. EC2) with few limitations 🤷🏻 (no access to operating system, file system, server’s hardware, etc). The beauty of Lambda is that it’s the simplest way to run code in the cloud ⚡ as it abstracts away everything except for a function interface, which you get to fill in with the code you want to run.

Overall, lambda is very cost 💰 effective if used in the right way. It is most suitable for small snippets of code that rarely change and one of most effective ways in which lambda can be used is to consider it as a plugin 🧩 system for other AWS services. For example:

1. S3 doesn’t come with an API to resize an image after uploading it to a bucket, but with Lambda, you can add that capability to S3.

2. Kinesis doesn’t come with an API to filter records and write them to DynamoDB, but this is very easy to do with Lambda.

3. And so on….

Lambda is a great way to extend existing AWS features but the problem comes, when people start to consider it as a replacement of a general-purpose server. It might look compelling at first — no servers to manage, no operating system to worry about and no costs when unused, but Lambda’s limitations typically reveal themselves once your application evolves into something bigger. Some major issues which arise when working with lambda:

1. ColdStart: When a function is invoked after a period of inactivity or when Lambda decides to start running your function on new backend workers. When lambda service receives a first request the service first prepares an execution environment — it downloads the code, creates an environment with the memory, runtime, and configuration, run initialization code and then finally invokes the lambda handler. All these steps of downloading the code and starting new execution environment is known as “coldstart”.

2. Limit of 250 MB for your code bundle, including all your dependencies. Depending on the programming language we are using, we can find ourlselves quickly exhausting this limit (especially in Java) .

3. Lamda is stateless in nature (unlike EC2) and hence, if we need to keep/access some state, we have to use something like S3 or DynamoDB.

Conclusion:
If you have a small piece of code that will rarely need to be changed and that needs to run in response to something that happens in your AWS account, then Lambda is a very good default choice. For everything else, we need to do rigorous analysis of whether lambda will fulfill our usecase or would we need to switch to EC2. Overall, while doing software development in current time Lambda has its place, but it is certainly not a substitute for EC2.