Microservices architecture key benefits

Oguzhan YIGIT
Published by Oguzhan YIGIT
Category : Microservices

The rise of cloud PaaS solutions contributes to the democratization of microservices architectures. Behind the buzzword, the microservices architecture is based on concepts whose clear objectives. If I had to mention only 3 of them, I would choose:

  • Simplify the development of application and reduce the complexity of classic 3-tiers applications
  • Facilitate and improve scalability
  • Adopt a meaningful DevOps approach

In this post, I would like to explain how can microservices help to answer the 3 mentioned points. To do so, I would compare microservices architecture to a legacy N-tier architecture. I also want to underline that microservices architecture perfectly fits with serverless components. Combining both is the basis of a flexible, maintainable and highly available architecture.


Simplifying application development

Applications evolve

Monolithic applications are built as a standalone unit. Very often, the code is organized in a few layers to separate user interfaces from business rules and data. Nevertheless, as time passes, the business needs change, evolve and grow. And more the time passes, more monolithic applications suffer from legacy code. Links between business processes become stronger. This is resulting in harder maintainability and difficulties to build new features.


People are moving

Nothing new, we need time and people to develop applications. The bigger is the application, the more we need both. And the more likely we are that the team will change. Even with perfect documentation, a careful integration process, and a great atmosphere, it’s being harder and harder to include new team members. In my experience, I also noticed that people getting bored faster while working in a complex monolithic application. With the time passing, the quality decreases and the stress grows.


Technology is changing faster than ever

Technologies are changing. They can bring something new, better performance, better scalability or simply, they can make it cheaper to develop. It could be a big challenge to profit from new technologies in a legacy application. I remember some applications where only a framework update was a big challenge. That’s not the worst though! Sometimes a full rewrite has been the solution.


So how do microservices help to handle these challenges?

Improving maintainability and evolutivity

At the top of a microservices architecture, there is the definition of a microservice: it’s small, independent, and loosely coupled. Therefore, the complexity of one microservice is really small. Because a microservice is only responsible to persist its own state and its own data, it can easily be handled by separate development teams.

Of course, small and independent services are easier to maintain or change. Always, these microservices need to interact. Often, communication between microservices relies on APIs or application messaging systems. This way, microservices are independent and loosely coupled. Creating new features is done by adding new independent microservices. So regression risks are limited. The complexity is more in the number of microservices in the whole application than inside an isolated microservice or the number of written code lines.


Keeping the team motivation

Microservices architecture enables us to develop Applications with separate, small and standalone teams. Each team is in charge of a business or technical domain. This is the opportunity to give people clear objectives and high responsibility. By putting the intelligence of the solution on the architecture rather than the line of the code we add interest to the work of the collaborators.

Obviously, because of the size of the teams and lower complexity, the ramp-up is shorter for the new team members.


Being at the top of technology

No matter the technology stack, each service can run under different platforms, languages or even version of framework. And nevertheless, these microservices can coexist and communicate. This offers the possibility to benefit from the most suitable technology for each need. Above all, it offers the possibility to benefit from upgrades of frameworks without impacting the whole application. Besides, I think it’s also a way to keep a team motivated. Obviously, people like to test and play with the latest technical stacks. In a way, by offering them to work with recent technologies, they are offered the opportunity to work on a “cool” project in a “cool” company. In a world where the computer engineer is increasingly rare, and where you want to keep your employees at all costs, this is of great importance.


Better scalability

The needs are evolving

Monolithic applications are initially thought to be hosted in sized server. It’s always a challenge to properly size environments that meet our needs, especially in an on-premise context. Because resource prizes have been decreasing for years, the easy call is to over-size most of the components. But what if one day the sized server is no longer enough to handle application traffic? Well, classic 3-tier can be scalable vertically, but that isn’t limitless. And often, when it’s not impossible to, it’s a real nightmare to scall them. Imagine that the activity of the application varies because of different parameters (period of the year, buzz, new product release…), then you need to adapt your capacity to absorb the increase in load. Usually, classic 3-tier applications aren’t thought of for this.

Also, in a monolithic application, resources have to be provisioned all the time, so they are fully billed.


So how do microservices enhance scalability?

As it can happen with monolithic applications, there will still be spikes in demand with microservices architectures. And, the application is split on microservices that might run under different servers and different technology stack. To handle spikes in demand, you will probably need to handle a set of microservices that need to be coordinated, not only one. It is easier to manage scalabilty because you will have more granularity.  This can be managed at the microservice level. So you don’t have to rethink your whole application but only a set of microservices nor to pay for the whole infrastructure. That means you have fewer constraints but still need to have a well-defined view of the involved microservices.

That’s where serverless and microservices architecture fit really well. Microservices architectures are best on cloud and virtualized environments. These components already bring horizontal scalability as core features. When using serverless services in a microservices architecture you don’t have to worry about hosting servers, and that makes the challenge easier.


DevOps friendly

DevOps is a methodology that brings closer developers (Dev) and IT Ops (Ops) to work together to deliver software better. It enables continuous delivery. A monolith is hard to deploy. Release management involves the whole application stack. Even if the deployment is automated, the whole application is tested again and again. Therefore, more key users and developers need to be available to validate tests. Think also about the testing environment: it’s always provisioned and requires all the stack of the entire application. Then more the application grows, bring new features or evolve in any way, worst is the deployment process. Some big organizations are even stuck with a product version because the release or the migration process is uncontrolled. And no one wants to go ahead blind.


So how do microservices fits DevOps ?

First of all, DevOps and microservices are both relatively new. Microservices are thought to be managed by DevOps pipelines. They are getting popular and easier to perform thanks to cloud platforms, and these platforms are more and more designed for a DevOps gait. Microservices are small and independant. They are designed to have no platform nor component dependencies, so testing and deployment can be done at the microservice level. Think about it, you can change, fix, build or deploy a small piece of your application and you won’t have to handle big bang releases.



It is not necessarily easier to manage multiple microservices than a single huge application. It gives much more flexibility at many levels but it require a better steering, project management and a top global view of the platform. As PaaS platforms (for exemple Microsoft Azure PaaS solutions) bring more and more services to make it easier to set up microservices architecture, I believe more and more applications will be designed with microservices.