Life With Serverless Applications at Armut
First time I heard the “Serverless” word was about a year ago when I joined Armut. We were in a grooming meeting about my task and I heard lots of new words I have never heard in my life like “Kinesis, Firehose, Lambda Function, Serverless”. The only keyword took my attention was “Serverless” . It did not mean anything to me at that moment.
Is it REALLY Serverless?
The answer is yes. There is no server, no virtual machines, nothing. There is only cloud.
You don’t need to worry about launching an instance and it’s hardware. You can only focus on your function. This approach is called Function as a Service.
Cloud Providers
The big 3 cloud providers(AWS, Azure and Google) all have support for serverless applications. AWS and Azure, they support nearly all of the programming languages, however, Google only has support for Node Js.
In this article, I will share my experiences on AWS as we use it in Armut.
When you start using AWS, the first thing you will realize and love is that first “1 Million” requests are free ! It comes with a monitoring and alerting tool as well! You can either develop only your function(basically methods with a custom context) or you develop a whole application. You are able to use AWS features with your function too. For instance, you can attach your Lambda to Kinesis and read the data! Furthermore, you can create a scheduler job by giving CRON expression too! In addition to these amazing features, you don’t need to worry about scaling your app!
If you’ve read so far and shared the same feelings I had, you are most probably ready to move all your infrastructure to serverless applications, however just be patient and keep on reading to find out more.
With Great Power Comes Great Responsibility
As Uncle Ben said, we need to be careful about our choices. Hearing about these excellent features made me think what the cons are. One and only thing I noticed was, the request dies in 5 mins. In a normal world, your response should and actually must return in milliseconds. However, if you wanted to make a scheduler with Lambda function this might not be the best solution for you.
I was building a Lambda function(not Lambda application) and as I dig into the project, I realized that it is really hard to debug and test it. For my experience, there is no direct debugging for Lambda functions. You have to make a trick and use your method outside in another app and pass a self generated context to it. In order to test your function, you can either deploy it or do the trick I have done for debugging.
Although these two issues increase the development time, the worst point about the Lambda function is Vendor Lock.
You become dependent to your cloud provider. There are several ways of distinguishing your app, however, this will bring you more development effort. Is it worth doing it?
What’s the Need for Serverless Applications in Armut?
To stream user events from back end, front end and mobile devices to Kinesis, we have a serverless application called Sentinel.
To update data on Iterable by the time they’re modified, we built another Lambda function and connected it to Kinesis through a Kinesis Firehose. We didn’t even bother with deployment.
As you might already know, we give gifts(we call it coupons) to our customers. We determine coupons through Payment Options API. By providing a yaml(YML) file to Segmentation API, it queries data from Elastic Search and our database and decides whether the customer can have coupons or not.
We needed to build a webhook in order to gather info from our payment providers. As a team we got use to infrastructure as a code, thus, we used Terraform to configure AWS.
Last but not least, those applications are on live and never caused any problems after the deployment. Development process was harder but the quality is higher than a normal application. In my opinion, Lambda functions are the best fit for using AWS features and creating webhooks.
For more information about our serverless applications, you can refer here.
