Benefits of serverless and why should you choose it?
Let’s explore some of the advantages of going serverless
There is a lot of buzz around going serverless. Most companies having microservices architecture have most of their infrastructure runs on Ec2 instances behind load balancers, HA proxy Nginx. Trying to put some of the benefits I have experienced moving toward serverless architecture.
This infrastructure can have below mentioned drawbacks
- Cost — Managing infrastructure has a cost associated with it and you are paying for the resources you are not utilizing in its full capacity.
- Operational management — You need to manage and monitor the infrastructure and take necessary action when something goes wrong.
- Auto Scaling — For an uneven sudden spike in traffic auto-scaling can take 5–10 min to kick off with self-managed Ec2 instances. This is problematic and tough to handle with current infrastructure.
- Time to Market
- Developer productivity
Going Serverless can help overcome some of these problems.
1. Serverless Cost:
You pay for computer time in serverless, you don’t need to keep your server up and running and maintain it.
You can start exploring serverless by building services where the number of requests is not high (eg services integrated with third-party webhook, service to generate reports occasionally) and not business-critical. If you run such services even in t2.nano(512 MB, 1 core) ec2 instances it will cost $4.23 monthly + maintenance cost.
With serverless let’s say you are getting approx 100 requests daily, and you are using 128 MB RAM and computing for 10 sec (Assuming you have consumed your free tier).
So with current lambda pricing $0.0000500 GB-second, it will be 0.0000500*0.125(128 MB)*10(sec)*30(days)*100(request)=$0.1875 monthly.
$4.23 vs $0.1875 you can see the difference.
If you have long-running jobs you can use AWS Batch, Fargate or equivalent services in GCP and Azure.
2. Auto Scaling in Serverless is easy
The success of any feature you deploy depends on how the customers respond to it. You never know whether the same will be accepted in huge numbers or will go unnoticed.
In either of the cases where the number is much higher or too lower than expected, you will have to scale up or scale down for efficient utilization of resources.
In the current setup, the number of servers to be provisioned and the auto-scale feature needs to be planned beforehand. And if there is a sudden spike, let’s say for 5 minutes, the current system will not be efficient to handle those requests as it will take some time to kick off and add extra servers to fulfill the incoming requests.
In Serverless setup, scaling is taken care of by the third-party services(AWS Lambda, Google cloud function) and it is designed to serve millions of requests instantly as and when needed.
3. Easier operational management
What if, after you roll out the feature and there is not enough traction and feature dies out and the service is not being used? Either you will plan to decommission the server or end up paying the cost for it.
If you will decommission the server it will involve an additional operating cost, For instance, DevOps team need to decommission it, and then later bring it up when we need it. So here’s where serverless comes into play.
Serverless allows you to pay per computation time which means you don’t have to decommission your service when you don’t use it. You can start using it again whenever you want to.No additional maintenance cost is involved here.
If it had been your own server, you would have to monitor it, maintain it, have proper alerts in place along with having a team to administer and manage the systems.
Apart from this, it came up with some side benefits as well.
4. Developer Productivity (Less time to Code)
As you develop a few serverless services and establish a software development process around it and if one fine day if you get a new product requirement which is supposed to be rolled out in 2 days with a requirement to store some data and hit a couple of APIs.
If you go with a non-serverless way, you have to do a bunch of things, Firstly Creating a flask application. Secondly, setting up the server, configuring Nginx, and writing Dockerfile to build the image. Finally, we need to figure out infrastructure needs and then to deploy to that infrastructure
With serverless, you just write your code, write serverless.yml config file(you can use the serverless framework for deployment), and it will automatically create API gateway using which you can invoke your service, and you are DONE.
Issues caused by the infrastructure that reduces the efficiency of a developer are no longer a concern.
5. Time to market and continuous experimentation
Because of improved developer productivity, launch times to production is reduced significantly.
In addition, Reduced Lead time to change gives the business an opportunity to experiment with new things and go to market at a much faster pace than earlier.
Cons of Serverless
- SLA for uptime — Azure provides a 99.95% uptime guarantee (21 mins of downtime a month) and Google Cloud functions have an SLA of 99.5% (3h 39m 8.7s downtime a month)
- The multi-tenant environment for serverless — In order to use their resources optimally, the provider could run multiple customers software on the same physical server, the performance of your code can be impacted if heavy load processing is going on for some other user in the same container, and you will not have to control over it.
- Vendor lock-in — Deployment configuration in serverless.yml, function signatures are specific to the third-party service provider, Therefor moving to a different vendor will require config, application change as well.
- Cold Start problem — It takes time to bring up the lambda, google function, Therefor the response time for the first request is slow. This can lead to bad experiences if you are using lambda for customers facing applications.
Follow us on