Have you ever been in the dilemma of whether to use Microservices or Serverless architectures? Here we will get into the perks they both have, as well as some situations that show when one or the other has been useful.
During the last few years, Microservices architecture have been accepted as one of the most tempting options when choosing the best software architecture for product development.
From the software construction’s point of view, the perks of Microservices are plenty. However, Serverless architectures and the possibility they bring of producing software pieces such as Function as a Services (FaaS) raise a new stage when it comes to designing the best architecture for any system.
In this article, my intention is not to thoroughly tackle what Microservices and Serverless are, but to explain – from my own experience – how my decisions have been influenced since I got into the Serverless world. But before that, I would like to lay out some basics first.
Microservices
Microservices architecture has been recently established as one of the favorites when it comes to thinking about software escalation, distribution, and flexibility. Companies like Netflix, among other big companies worldwide, have proved that this architecture option really works, especially when a high demand from users must be handled (Netflix has to answer to more than a billion requests daily).
Due to its characteristics, the benefits of Microservices are plenty, especially when it comes to software maintainability:
- Has a small size
- Offers the possibility of displaying each Microservice independently of other services
- Has its own logic that is generally easy to test
- Offers the possibility of being developed into any programming language
- The independent scalability
- The reuse of each Microservice (which I consider the most important benefit)
Each Microservice should be designed to be used for different applications or even for other services and not just for one single client. My experience in building business architectures has taught me that if the only client of a Microservice is and will be one single application, the best architecture choice is a Monolithic one, even though this word may not sound nice nowadays due to its lack of popularity.
Content related: Quick guide: Monolith vs Microservices vs Serverless
There is a large number of benefits of Microservices, and for sure, everyone who needs to choose a new architecture gets enthused with it. However, there is a dark side we have to cope with, which includes the Microservices dependence, the handling of the versions and the management of the distributed transactions, and the deployment of the Microservices themselves, among others.
Fortunately, all these problems hold several solutions: design patterns implementation, frameworks or library usage, and a great number of tools that have been developed in the Microservices ecosystem.
From my own experience, I would like to point out that deployment and operation of Microservices might be the most annoying ones to me. Docker and the containerization technologies have helped a lot in this aspect. However, when the Microservices grow, the management efforts are also huge, and it is necessary to add more tools and skilled professionals within the teams. In this case, what had happened is that the project focus turned out to be how and where to develop the containers and how to scale, manage, and monitor them instead of thinking about the final solution the development originally had.
Content related: Microservices: The biggest challenge might be your own company
Serverless
This architecture, where the implementation is focused on Function as a Services (FaaS) or Backend as a Service (BaaS), presents the implementation of a function that attends different clients and gives a specific answer. This function is generally exposed through an API Rest or other invocation ways.
One of its greatest benefits is that Serverless completely ignores management of the underlying infrastructure. The infrastructure that hosts functions is actually anonymous, which favors the resolution of the requirement without having to think about solving infrastructure issues.
This big plus that I encountered has helped me focus my attention in Serverless architectures for a while now. I came across similar benefits to the ones that Microservices offer, with no need of putting effort in architecture management which has allowed me to forget about operative systems, escalation technologies, load balance, costs strategy, etc.
Do not miss this: Serverless Architecture Part I and Working with Serverless Part II
So, Microservices or serverless?
It is true that a FaaS is not directly comparable to a Microservice. FaaS is even more granular. Personally, I like to think of FaaS as a micro-microservice.
That said, looking retrospectively at different scenarios I have had to deal with, I find it timely to tell you how I solved some specific situations, especially after getting to know Serverless and more precisely, FaaS.
- A few months ago, in the backend of a mobile app (Android and iOS), I had to implement a service that would allow the search of products in a catalog. Before knowing about FaaS, my first option would have been for sure to create a product web search service, deploy it in Docker, and manage it with Kubernetes. In this case, the development and management would have been my greatest problems, while the development of the solution itself (product search) would be left aside. Using FaaS to solve this requirement allowed me to focus on the development without having to worry about anything else.
- In another similar scenario, I had to solve the update of an access control in a central system, where I had to create a service that could update, in real time or near real time, the monitoring of people’s access to different offices around the world. A Microservice attending this necessity would fit perfectly. However, the implementation of FaaS was the most suitable to attend this demand.
- Not only did I realize that web services can be attended through FaaS, but also that Batch processes fit perfectly in specific scenarios to be replaced by FaaS. Most FaaS implementations allow several entrance points as well as an API Rest, such as configuring its execution from time to time or at a certain time of day.
So, why should we not replace FaaS with a Batch service that recollects transactions made in an app for a Business Intelligence system every hour? In this situation, FaaS is once again a much simpler solution in terms of architecture.
To Sum Up
From now on, every time I think of a Microservices architecture, I first try to figure out whether FaaS is the simplest and most effective solution. Although it is clear that Serverless is not Microservices, the truth is that scenarios solved with Microservices architectures can be solved in a simpler and more affordable way with FaaS.
Nowadays, architectures of big, complex, and distributed systems must be generally designed with hybrid architectures – that is, with architectures oriented to services, Microservices, FaaS, etc.
The important thing is to know the wide spectrum of technologies that exist in order to know which the right one is in each scenario.
Comments? Contact us for more information. We’ll quickly get back to you with the information you need.
