Optimize DevOps efficiency and cost through Serverless Architecture (AWS Lambda)
We are back with another interesting experience. This time we had to cut down the operational effort to focus better on innovation in products. In B2B domain, always expect customer specific customization to meet the need of users. At the same time, it’s a good idea to make product generic and maintainable. Though we always follow best practices to ensure maintainable code, but complexity increases with increasing number of specific jobs, analytics compilation, logs, monitoring, custom scheduled reports, etc., instead of hosting entire application including random specific tasks on an EC2, we decided to move few tasks on AWS Lambda.
AWS Lambda is one of the ways to implement serverless architecture. Lambda is completely event driven and only runs when invoked. Generally it’s good for cases where high number of requests have to be handled at unpredictable times, in other words, services having quiet periods followed by peak in traffic, making it an efficient way to ensure scalability and avoid unused server capacity.
We implemented Lambda in Chatbots (Surbo) for Channel Services and observed unutilized server and uncertain spikes (few instances in a week based on triggered campaign) in few channel services. Also requests were not long running hence we decided to move such cases (or service) to AWS Lambda. This helped us to handle the peak and save costs for allocated instances or resources.
Another case is of a Marketing Automation Product (Infinito) which was hosted on our data center; here we exposed AWS Lambda for short running, high volume Delivery Report (DLR) processing. Delivery report handling was written in NodeJS and due to heavy peaks it got difficult to successfully process requests and also scalability was a big concern. Hence we moved the NodsJS handling part to Lambda so now request gets handled in Lambda which further pushes the data to DB in data center.
The good thing about NodeJS is that we don’t miss out on any request. But with more concurrent requests, the request time against each request tends to get higher & higher. Check the below stats:
Time taken for tests:1.277 seconds
Failed requests: 0
Time per request: 127.730 [ms] (mean)
Longest Request:175 [ms]
Time taken for tests:54.611 seconds
Failed requests: 0
Time per request: 5461.053 [ms] (mean)
Longest Request: 54581 [ms]
As you can see from the stats, with a 10 fold increase in overall load, the same system showed a 50 fold decrease in request processing performance.
The demand of the system was to react on every event, DLR being the primary event, as real time as possible. Hence, lowering the request time was of prime importance. Since, marketing campaigns are time bound, scaling the hard metal servers was not a good choice to go for as relatively expensive (again adding that this application on our data center). This is where AWS Lambda perfectly fitted in, scale for short peak hours and deliver performance while saving on money. We were able to lower the ‘Time per request’ to few ms with the help of AWS Lambda.
Simple to implement / Considerations
For implementation, we upload the individual function to Lambda, and call it using the API Gateway, one of the triggers available to initiate function call. This allow us to only invoke service or method when needed, serve the request depending on traffic and scale on peaks. No more instance monitoring along with reduced cost as billing on number of requests executed.
As a best practice, do ensure to regularly ping the Lambda function to avoid missing any traffic as a cold start take time ranging from a few seconds to few minutes. Cold start is basically duration of time to provision the selected runtime container and then runs your function.
Note: You must go through default limits of AWS Lambda and get it extended on request
Besides benefits, we could not really control the setup and were unable to install few custom packages required for application on the running environment, due to which we had to make some change in the execution approach by orchestrating and organizing our function to work.
Server-less architecture depends on your requirement and decision whether it makes sense for your application. AWS Lambda has resolved the problem of deploying the code with the environment setup, and decouple it with the server’s architecture, make it more resilient.
This makes it possible for teams to focus better and divert resources on innovation. To know more, feel free to send us an email on email@example.com or leave a comment below.