This article will look into Serverless Architecture – what is it, what are the advantages and disadvantages and how you can minimize your DevOps spend by leveraging serverless architecture.
This blog is a summary of the webinar held by Andrzej Brozniak, Senior Cloud Engineer and DevOps Consultant. You can watch the full webinar here.
What is DevOps?
For every company the application of DevOps is different, and probably it should be different, given the unique structures and challenges we all face.
DevOps integrates developers and operations teams in order to improve collaboration and productivity by automating infrastructure, automating workflows and continuously measuring application performance. DevOps is a culture, it’s a development approach essentially, and it should be inherited throughout the whole software development department. To create the process of continuous integration, continuous delivery, or deployment, everyone needs to be involved – starting with the developers and testers, and finishing with development, product and operations managers etc.
As we will investigate the application of DevOps with a serverless architecture, it is useful to define what serverless architecture is to begin with.
What is Serverless Architecture?
It’s a focus on your application, not the infrastructure.
So, the key feature of a serverless application is that you don’t have to take care of the servers, as everything is provided to you within the cloud infrastructure. Serverless architecture is a cloud computing execution model, where the cloud provider dynamically manages the allocation and provisioning of the servers. Application runs in stateless compute containers that are event-triggered, ephemeral, and fully managed by the cloud providers.
Let’s compare traditional and serverless architectures:
In a traditional architecture, you would have a frontend logic, a backend logic, and you need to handle the security and databases. When it comes to serverless architecture, how it works is that you only need to have the security covered and the rest is provided by the cloud provider.
So actually, the database is a dynamic database, and what that means is that you don’t have to specify the size and it’s also not a relational database. Basically, you just have the service and you have all the backend logic as you need like a puzzle. Your code is sent to the special infrastructure where everything is executed.
Things To Consider Before Going Serverless
What Cloud provider should you work with?
You have some providers who can provide you this special version of instances in the cloud, which allows you to execute the functions. Most of the biggest cloud provider provide this capabilities AWS has Lambda, we also got Google Cloud Functions, and Azure Functions and so on.
What framework should you choose?
Before you develop your application, you need to choose your frameworks wisely because severless is an approach where you have to code in a different way, and that requires the use of specific frameworks. As you can see below, most languages today provide such frameworks. Among the most common ones, we can count ClaudiaJs, Apax, Sparta and Gordon:
Serverless Architecture Example
General Web Architecture:
This is general web architecture in AWS, where you’ve DNS, Load balancer, auto scaling, EC2 instances, RDS, etc. So, what’s the problem of this classic infrastructure?
First of all, you need to manage this whole system, which probably means, you need to have infrastructure as a code as well as some sort of Terraform script, Ansible scripts or CloudFormation which is specific to AWS. You would need to choose the right database size. In addition to that, you need to have some networking knowledge, because you need to configure the load balancer properly. Ideally, you need to have some kind of an autoscaler and you also need to take care of the security updates, which is easy to forget about when you just have EC2 instances. So there’s a lot of ground to cover and a lot of room for problems with that.
Here we can see what a serverless architecture looks like:
With serverless architecture, we basically just have a DNS. It’s an API gateway, which manages the lambda functions, and dynamic, non-relational databases. Here it is useful to point out that using noSQL databases in serverless architecture is not a must.
What are the advantages of Serverless Architecture?
First of all, we don’t have to pay for all these instances, which normally you would have to pay regularly. This is because, you pay only for the time when a code is executed. The API gateway is the manager for all the lambda functions. Whenever your user clicks on something, the function will be executed, so you will pay only for this availability. This could be hundreds of milliseconds, maybe a couple of seconds, and the limit is up to 15 minutes, which means your function shouldn’t last for more than 15 minutes. A side note on this; back in the day, Lambda’s maximum execution time was 5 minutes (and even less) so we should expect this limitation to decrease in the future.
There are also advantages and disadvantages of the serverless approach from a business perspective. We all know that the process of agile is much easier thanks to smaller deployment units resulting in faster delivery of the features to the market, and thus, increasing the ability to adapt to changes.
The cost of hiring backend infrastructure engineers go down as well, because you will probably only need one, or two DevOps engineers in a mid-sized project. That’s enough when you adopt the serverless approach, because the amount of work with the infrastructure becomes minimal.
From the developers perspective, one of the main advantages is the reduced liability – no backend infrastructure to be responsible for. Since we don’t need to take care of the environment, and we have everything by design, we can just focus on the code, forget system administration and enjoy easier operational management. We can foster adoption of nanoservices, SOA principles, faster setup, and monitoring out of the box, which is also very important.
Testing also becomes way easier, because your testers just need access to the specific AWS lambda instances and they can execute and test various functions. Moreover, testing in serverless systems is cheaper because no one needs to take care if someone closes the instances after the test. Again, you’re paying only for the time when something is being tested, which means reduced operational costs.
Examples of Cost Reduction Using the Serverless Approach:
The first example is a very small website, but it shows the level of saving possibilities. This simple ExpressJS application with 50 to 150 daily visits. It was migrated from AWS Elastic Beanstalk to Lambda plus API Gateway. The whole migration took less than one day, and it resulted in 90% of reduction of costs, from $45 to just over $6 per month. Basically, the costs are reduced by 90% only in one day.
Below we have a bigger example. It’s a company called Heavywater Inc and it is using artificial intelligence virtual assistants to offer business process outsourcing. We can see that the cost of running their artificial intelligence application reduced monthly from an AWS bill of $30K to $4K.
Before switching to serverless infrastructure, things started getting more expensive for them, because even with the most of their EC2 instances sized t2.micro, which is one of the smallest ones in AWS, the AWS bills keeps increasing. In the span of just four months, the monthly costs increased from $10K to $30K, with over 1000 EC2 instances running. When they decided to go for the serverless approach, they reduced costs from $30K to $4K in less than four months.
The last example is a company called Postlight, they are serving 39 million requests for $370/month (instead of $10K before moving to serverless).
Their new system is running on AWS Lambda and API Gateway, built and deployed using the Serverless framework. They used AWS Lambda for everything – “from parsing the web to writing Slack bots; from batch resizing hundreds of thousands of photos in parallel to batch transcoding hundreds of thousands of videos.”
What are the disadvantages of Serverless Architecture?
Probably the biggest disadvantage is that we have to reduce our overall control because our cloud provider is the one taking care of our infrastructure. There may be security risks, because we need to remember that serverless architecture is a relatively new approach and the whole ground may not be covered yet.
Additionally, the expenditure becomes unpredictable, as the number of needed executions is not pre-defined but based on your need at a certain point in time. This usually results in cost savings, but if you have a high availability, high traffic website, you may want to keep this in consideration.
It’s possible to mitigate most of these disadvantages with open source alternatives, or paid solutions. What I have generally observed is, if you resist change due to these disadvantages, in the long run, it will cost more time and more money trying to sustain and maintain a classic infrastructure.
We also can’t deny the architectural complexity of serverless approach for someone coming in new to this area. Additionally, this kind of approach requires software teams or engineers to learn a new framework, so you need to expect a learning curve. Nonetheless, this learning curve will set a newcomer in the DevOps mindset from the beginning, so it is an investment which will be worth your while in the long run.
Final Remarks on Serverless Architecture
Serverless approach allows you to focus on your functions, not the infrastructure of the application. And, of course, as we said it’s still relatively a new technology, but I believe that if you find a way to work around the limitations, like higher amount of logs and harder maintainability, you end up with a modern application that is built to last and scale.
If you are not sure, try to go for a proof of concept. Maybe the end result will be something that you will be happy about because the potential reward is way bigger than the potential risks.
You can watch the full webinar here:
In case you have any questions or would like to get further information on the topic feel free to reach out to Andrzej!
Would your team benefit from a consultation on the topic? Reach out to us at Zartis.