The Only Reason you need to embrace Microservices Architecture

What is Microservice Architecture?

It’s an architectural style where autonomous, independently deployable services collaborate to form the whole application.

Why do we need Microservice Architecture?

To understand the reason we need to understand the problems we encounter with the opposite approach i.e. a Monolithic architecture.

A monolithic architecture is one where the whole application is packaged as a single codebase and everyone works on that codebase. To make even a small change whole code needs to be compiled and deployed again.

Problems with the Monolithic approach

Let’s say an individual developer launched a successful SaaS startup. The SaaS application has a monolithic architecture where the developer can work quite efficiently and can output let’s say 5 features per month.

Now, to stay ahead in the competitive market he needs to deliver 15 features per month. So he asked two of his close friends to join him in his venture and together these 3 were able to deliver 12 features per month (~ 4 features per month per person).

They were expecting a development rate of 15 features per month as they were equally caliber but were surprised to learn their actual development rate. But they managed to increase it by spending some extra hours.

By the end of the year, the team grew to 10 developers working at the rate of 30 features per month (~ 3 features per month per person). Again they noticed the rate at which they were delivering features was quite lower than what they expected. Somehow the effect of adding more people to increase the development rate shrank quite a bit and the whole team wanted to know what was causing this.

This is the major problem with monolithic architecture i.e. adding more people after a certain threshold does not drastically improve the development rate. In other words, it is very hard to scale the team/organization with a monolith architecture.

When the number of people in the team is large and they have a monolithic architecture then the team faces the following problems and that is why their productivity decreases instead of increasing.

Communication

As the number of people in a team increases, it becomes more challenging to coordinate activities and ensure that everyone is on the same page. Communication becomes more complex, and it takes longer to reach a consensus, which can slow down decision-making and project progress.

In Microservices architecture, one large team is divided into smaller teams and the size of the team is minimal thus communication problems never creep up.

Less Independence

In Monolithic architecture, due to tight coupling between different modules and components, and shared resources such as databases, it becomes very difficult for a developer to work independently without affecting other parts of the application thus hindering other people's work.

This is one of the major benefits of microservice architecture, that each team can independently work on their functionality without worrying about breaking any other part of the system.

No Autonomy

In Monolithic architecture, the whole code needs to be working to build and deploy it. Thus a developer needs to wait for his feature to get deployed because others might still be working on their features.

This is also one of the major benefits of microservices architecture, each team does not have to wait for others to finish their work. A team deploys their code whenever they want as long as they are not introducing any breaking change in their public interface.

Fixed tooling/stack

Monolithic applications are often built with a specific technology stack, and it can be challenging to adopt new technologies or upgrade existing ones without significant changes to the application code.

The developer does not have the flexibility to choose the right tools instead they need to adapt themselves according to the tech stack. In Microservices architecture, since each service is a new project, this gives the team freedom to pick the right tools and stack for the job.

Large codebase

The large codebase of a monolith application makes it difficult to understand and work on it if it is not well maintained. Also for new joiners, the size of the application is one of the main hurdles that keep them from getting up to the pace.

As for microservices, they are relatively smaller in size.

Git conflicts

In Monolithic architecture, developers may face frequent merge conflicts due to a large number of commits being pushed thus resulting in slower development speed.

In Microservices architecture, git conflicts are rare occurrences.

Reasons to choose microservices architecture

• Your number one reason for choosing microservices architecture should be having the ability to scale your team/organization.
• Information Hiding: If there is some part of code or data which should not be shared with anyone on the team then that part could be encapsulated as a microservice and only authorized people can work on it.

Wrong reasons for choosing microservices

There is a strong misconception that by having a microservices architecture, the application would have the following characteristics automatically which is, by the way, not true. Due to this misconception, people make the wrong choice and go for microservices architecture where it doesn’t make sense.

• Scalable
• Available
• Fault Tolerant
• Efficient resource utilization

Most of these characteristics can be achieved with a monolithic architecture while others do not justify the trade-offs. A few well-known examples of applications following monolithic architecture are StackOverflow and Github. These examples prove that these characteristics are not exclusive to microservices architecture only.

The thing with the microservices architecture is that it brings a lot of complexities. Such as

• Increased complexity: The application becomes more complex to work on or even understand.
• Networking: Method calls become HTTP calls.
• Deployment of the whole application becomes difficult.
• Debugging is hard
• Setting up a local environment for the whole application becomes challenging.
• Data consistency problems.
• System testing becomes difficult.

Bringing these complexities is only justifiable when they are helping us solve an even greater problem which, in my opinion, is the scaling of the organization/business/team.