Bartosz Nowak | Cloud Services | 24.11.2021
At a time when the popularity of microservices architecture is growing, in addition to designing and writing applications, you should also take care to manage these applications, choose solutions for orchestration, network layer management, etc. This usually involves building a dedicated and specialized team. If you want to avoid this and make life a bit easier, you can write an application using serverless architecture such as AWS Lambda. Read on to find out more about using the AWS Lambda function, the costs involved, as well as the advantages and disadvantages of AWS Lambda.
AWS Lambda is an event-driven serverless Function as a service (FaaS). The Lambda function allows you to write code and manage the application without the need to maintain your own servers. It allows you to create applications in the cloud, e.g. using the popular ZIP deployment method.
Function as a Service is gaining popularity because the user only pays for the processing time of a given function. For example, in the case of the REST service that triggers Lambda, the fee is charged only for a single endpoint call (this approach is known as pay-as-you-go) while maintaining availability, reliability and scalability.
This is an event that tigers AWS Lambda. The tiger can be 1 or more events from different AWS services, e.g.:
Each of these events could be a topic for a separate article, so if you would like to explore this matter further, I encourage you to read the Lambda Amazon Web Services documentation where everything is described in detail.
It is worth mentioning the type of the function call (InvocationType). Lambda can be triggered in two modes:
Synchronous – This mode can be compared to a REST call in which a request is sent and a response is received, which is why it is called a request/response type.
Asynchronous – In this mode, the request to Lambda is sent to the event queue. If an error occurs, the request will be sent twice at most. AWS does not guarantee that all messages will be delivered – for example, when an application cannot handle a given number of queued events. Since we do not know whether the function has been executed, using DLQ (dead-letter-queue) might be useful. In this case, the Destination Block helps us. This mode of triggering is called event triggering.
The function code can be written using one of the languages supported by AWS. Currently, we can choose from programming languages such as:
Using technology such as e.g. Node.js, you can take advantage of the built-in editor to write a function. You can also provide the code for an externally created function as a package in a ZIP file. There are various plugins for development tools that can help you create a structured code package (such as Apache Maven Shade creating Uber-JAR).
This block is responsible for sending notifications about the status of the function execution. In the case of correct or incorrect execution, AWS can send a notification to one of the 3 available channels:
or run another Lambda function.
However, this functionality will only work while triggering the Lambda function asynchronously. When testing Lambda in UI AWS, the Destination Block will not work because the request is sent in the request/response mode, not event mode.
AWS Lambda is an FaaS which means that Amazon Web Services manages the infrastructure. The function code itself is stored on AWS S3. We should remember the limits, such as those concerning the amount of code in GB that can be stored in a given cloud region, among others. For the European region, the limit is 75 GB.
When the request is sent to the Lambda function, it is launched as an instance of our service in the internal environment. It is similar to the AWS EC2 environment (virtual machines on AWS). However, the user does not have access to this environment. When we try to launch an instance, the AWS mechanisms check whether such an instance has already been launched, and – if it is running – whether it is processing the request. If the instance is busy, AWS Lambda mechanisms create a new instance of the function. Otherwise, it uses the current instance or, if the instance does not exist, creates a new one. If a function instance remains unused for a long time (AWS manages the time itself), the function instance is removed.
Now let’s move on to an aspect which is inseparable from the cloud, namely scalability. AWS Lambda, like any other service, has certain limitations, one of which is the limit of active instances for a given region – in the case of European AWS regions it is 1000 active instances. This pertains to all of the Lambda functions we have in our account in a given region. To ensure that the minimum number of instances is always launched when needed, you can book the number of instances per function in the Lambda configuration. Also, it is worth mentioning that each Lambda instance has access to the internal memory (/tmp) with a capacity of 512 MB which is not deleted until the instance is removed.
When creating Lambda, two important parameters must be provided:
Memory – this is the available RAM assigned to the instance of our service. In the event of exceeding the memory limit, the instance is stopped. Currently, the maximum memory limit is 10 GB.
Timeout – the maximum time for the function execution. This is a very important cost-limiting parameter. If we set this parameter, for example to 30 seconds, and our function execution time is longer than the response time, this function will be stopped. You can set the maximum time of 15 minutes.
AWS Lambda – important configuration elements:
The answer is: it depends. In AWS Lambda, you pay for the amount of time you use the function for and the memory used. The billing unit used by AWS is gigabytes per second (GB / sec). You also pay for the number of requests; however, in the starter package for a new account (free tier) you get 1 million requests per month and 400,000 GB / sec. That’s quite a lot for free testing of AWS cloud solutions.
Let’s assume that we have an application serving 500,000 requests a day which needs 512 MB of memory. The total monthly cost is approximately $267. This is the only cost we will bear as we don’t need to maintain the application infrastructure (k8s, Service Mesh etc.).
I wouldn’t like to compare the costs to the server instance here, e.g. EC2, because this comparison would not be adequate. I will leave everyone to judge which approach is more viable for them.
Read also: Building WordPress on AWS
It is worth considering whether AWS Lambda will “lighten” our infrastructure and allow for cost optimization. As part of the analysis, it may turn out to be a tailor-made solution. Of course, AWS Lambda is not an ideal tool. It has its limitations, and it will not always allow you to achieve your goal. I hope that I have been able to introduce AWS Lambda, along with its advantages and disadvantages. I encourage all who are interested to explore this subject further and learn about the solutions allowing us to use the potential of AWS Lambda – S3 or SQS libraries. It is also worth investigating solutions allowing you to reduce the “cold-start”. There are many of them – AWS Serverless Java Container Spring to name one – but that is a topic for a separate article.