Microservices Architecture

Understand the differences between Monolith and Microservice architectures and when you should opt for them.

Oct 30, 2022

Microservices architecture is a software architectural style where an application has small independent services communicating with each other over well-defined APIs. Each microservice focuses on a single application process.

On the other hand, a Monolith architecture is the conventional style where an application has tightly coupled code and run as a single service.

Popular applications like Netflix, Facebook, and Whatsapp started as Monolith applications and later switched to Microservices architecture.

This week’s post will discuss microservices architecture, its benefits, the differences between monolith and microservices, and when to implement them.

Understanding microservices

Microservices are decoupled smaller services that contribute to the working of a software application through well-defined integration using APIs.

Each service is independently developed, tested, and deployed without affecting the working of the other services.

Let us look at a simple social media application’s architecture to understand it better. We’ll assume that our application has four functionalities — Posts, User profiles, Notifications, and Chat.

The above implementation is a monolith architecture where our major functionalities are developed in a single service and tightly coupled without the need for integration.

These modules are all within the same code base and can interact with each other using function calls.

In the above microservice architecture, the functionalities are decoupled and deployed as separate services. Each service focuses on a single responsibility and has its database.

The services are integrated to communicate with each other via APIs. This aids in the overall working of our application.

Benefits of microservices

1) Easy to scale

With a microservices architecture, you can analyze the usage statistics of each service and scale them independently.

If your social media application gets a large number of requests for user posts, then you can add more servers for the Posts service instead of scaling the entire application.

2) Technological freedom

Each microservice is independent, and they communicate with each other using APIs. Hence the developer team implementing the microservice has the freedom to use the language and the framework that suits its functionality.

There is no necessity for long-term commitment to a tech stack. Developers can implement any latest technology that suits the service.

With a monolith application, using a different language or framework for each functionality might be tedious and time-consuming.

3) Easier testing and deployment

In a monolith application, debugging an issue might take longer because of tightly coupled code. For larger applications, the huge code base adds more complexity for debugging.

Also, any minor change or feature added to a monolith requires testing and deployment of the entire application.

Microservices architecture helps us narrow down a bug to a service to reduce debugging time.

When we add a new feature or fix to the application, we can selectively deploy the microservices involved instead of deploying the entire application.

4) Improved data security and governance

Microservices communicate with each other using secure APIs. Developers working with this architecture find it easier to implement data security practices to their services and APIs.

Since each team of developers focuses on handling specific services, microservices provide greater accountability when complying with data governance frameworks like GDPR and HIPAA.

When should you opt for microservices?

Considering the benefits, is it implied that we should implement microservices every time? No.

There are a lot of factors to consider before implementing microservices for our application.

Skilled architects:
Microservices architecture requires a skilled architect to design the services. This will prevent our application from redundancy, communication lag, and security vulnerabilities.
Presence of large teams:
Developing and maintaining a microservice architecture with a small team of developers might be tedious. This might put some additional burden on testing, deployment, and monitoring of all the services.
Hence opt for microservices when there are enough developers to focus on each microservice.

Before designing the base architecture for your application, consider the factors that might affect development time, monitoring, scaling, and technological commitment.

StackOverFlow, a well-known application that helps developers find answers, still runs on monolith architecture.

I hope this gives a clear perspective on monolith and microservice architectures.

Useful resources

Visit https://microservices.io/. This is maintained by Chris Richardson and considered one of the best resources for microservices.
Checkout this video by Nana explaining microservices in detail.

Books on microservices:

Microservices patterns: With examples in Java by Chris Richardson.
Building Microservices by Sam Newman.

Toxic Productivity

Last week, I read an article about how we get addicted to finding new ways to increase our productivity, which hinders our productivity in the long run.

It makes us feel like we were productive when we actually did nothing.

We’ll discuss more on “Toxic Productivity” in my next post.

Until next time!