A good friend asked me last week, “Ido, as a DevOps Engineer, what do you prefer: a serverless architecture or a microservices one?”
My friend is a software engineer with knowledge and experience in both, but he is confused (much like several of our customers), so, I’ll try to help.
First, a small explanation on both
Microservices is a very popular concept right now, from the beginning of Docker in 2013 and the Kubernetes project everybody in the Tech community is talking about moving from Monolith applications to microservices such as containers. The Idea of microservices is decoupling the application to small pieces of code, each runs on its own server. When we want to develop a new feature or deploy a new upgrade to the application, working with microservices is idle. Simply update the part you want and redeploy the container while the other parts of the app remain available.
The Concept of Serverless was introduced to the world in 2015 at the announcement of AWS Lambda. Serverless computing in general is event driven, the serverless code is running as a response to triggers. AWS Lambda can be triggered by more than 50 different services for example. The main Idea here is that developers and DevOps engineers can run small functions and perform small actions that only happen when needed, without the need to launch, configure, maintain and pay for a server.
Next, find the differences
Although the two are different, they have a lot in common. They both were invented to minimize operational costs as well as the application deployment cycle, handle ever-altering development requirements, and optimize everyday time- and resource-sensitive tasks. The main difference is that microservices are eventually servers no matter how small they are, this fact has its own benefits such as accessing the underlying infrastructure and granting developers full access to relevant libraries. But, there are two sides to every coin: , the access to infrastructure comes with great responsibility of course.
Serverless and especially Lambda functions are limited to the libraries the cloud provider offers, for example not all Python libraries are available and sometimes you’ll need to improvise. In addition, Serverless is an automated way to respond to events, performing long calculations and processing might not be a great idea with Serverless because you pay-as-you-go and you are limited to max execution time.
Now, how do I choose?
When architecting a new solution that will be deployed to the cloud we need to think of the traffic we are expecting to the application. The more we can anticipate the traffic it will be more cost effective to use servers such as containers or a kubernetes cluster. Serverless is a pay-as-you-go model that grants the business advantages such as small to almost no cost when the traffic is slow. But Serverless has it’s limitations such as concurrent executions for Lambda functions. Sure these limitations can be increased but for steady high intensive workloads Serverless is not the answer.
On the other hand, if the average usage of our servers is small and unpredictable, a serverless architecture is a better choice rather than servers, The infrastructure will be ready to absorb workloads without pre-worming or launching new servers. As a rule, if the average cpu utilization of your fleet is under 30% consider Serverless.
Keep in mind that serverless is meant for automated responses to events in our environment, so the use of both is important. The best solution will always consist a little bit of both. A company will deploy their application on a containers fleet with a load balancer and auto scaling and use Lambda and API Gateway as a serverless mechanism to deploy WAF rules on top of the Fleet. Another example is creating a Lambda to isolate and tighten the Security Groups of a compromised instance.
In a world that rapidly changes, in cloud environments that enable you to grow fast and reach clients all over the world, a business must know how to launch their applications faster.
Not sure which architecture is best suited for you? Give us a call