Introducing Microservices

Introducing Microservices


8 min read

Hello, Hello, Hello ~ welcome to this new blog. In this blog, I am going to explain Microservices so sit back relax and keep your focus on and let's get started.

A modern software application you wanted to perform well?

Introduction to Microservices

Microservices is an architecture style that is grown rapidly and gain popularity over the last decade it has the ability to achieve the goals of modern software applications.

What are Microservices?

So what is really meant by Microservices? Let's answer this question.

A Microservice is an architecture style where autonomous, independently deployable services collaborate together to form a border software application or system.


That's it, as simple as that, you might even work on system that follows this approach without calling it microservices architecture.

The name of microservices itself, suggests that the services should be small but there is no such size limit this is depended on the developer that how much larger or smaller he wants to build it so that it can follow the microservices approach.

Now the question here generated is why? Why do we even need microservices?

To answer this question we have to understand what is monolith and what is the problem of the monolith.

Monolith Architecture

Before microservices, we were using monolith architecture to develop the application. The application that follows monolith architecture has:-

  • Single codebase:- Monolith application typically has all of its code in a single codebase, All the developers collaborate together in the same code repository

  • Single process:- The build artefact is usually a single executable or process that runs on a single host server or virtual machine and persists all of its data in a single database.

  • Consistent technology:- The development environment typically uses a single consistent technology, such as what programming language or SDKs using throughout the codebase.

Monolith Benefits

  • Simplicity:- The code is in one place so it's Easy to find things, there is only one thing to build and run, so it is straightforward for developers to work on

  • Deployment:- When it comes to deploying the monolith to production there is only one single application to deploy and if in future we have to update the version then also we just have to replace only one application.

Remember just because nowadays we use microservices more than monolith that doesn't mean there is something wrong with the monolith approach if everything is working fine and great for you think twice Do you really need microservices just because the world is using them? If in your organization everything is good while the following monolith you should stick with it. in my opinion. until you are really facing problems due to monolith.

The problem with monolith

The problem of scale:-

The problem with a monolith is when it comes to scaling, the Monolith model works well with single developers or small teams who are working together just for 2 to 3 months may be to build a small website that handles a modest number of visitors.

What happens when our project grows much larger?


Let's assume we got 20 to 30 developers who are working for several years building a system that has 1000s of users and stores a massive amount of data.

In this kind of situation monolith approach becomes a big problem.

As a codebase grows larger there is a tendency to become more difficult to maintain due to growing complexity and the accumulation of technical debt.

Even if you made a concretive effort to keep your monolith modularized often you will find that these modules end up becoming very entangled and interdependent.

The problem in Deployment:-

When it comes to deploying the monolith even a single line code change requires an entire application to be deployed which is **risky **and usually involves a period of downtime which is unacceptable in the modern era of cloud services that are expected to maintain high availability.

Difficult to scale:-

Scaling of the monolith to meet demands of increased usage or a large amount of data is also very difficult, unless great care has been taken to make your monolith stateless you probably can't scale it horizontally. So the only option is to scale vertically where you provision much more powerful and **expensive **service. A monolith application requires an entire application to be scaled out together rather than just scaling the component that actually needs extra processing power.

Wedded to legacy technology:-

With the monolith, you can very easily find yourself wedded to legacy technology, The technology you have used to build the original application version is going to be very hard to get away from in the monolith applications, as you have to upgrade the entire application to move to a newer framework. And this **reduces your agility **to adapt newer patterns and practices, and also takes advantage of new innovations such as new tools and services that would benefit your application.

Distributed Monolith

Now you may be thinking that my application is not a monolith it is made up of several services that run on different hosts and talk to each other over the network.

REMEMBER:- Just because your application architecture is based on services doesn't mean that you are using microservices.

It is possible to create a system where you have several services but they all access data in a shared database. and they are tightly coupled to each other in such a way that you have to deploy them all together. And any change you make to the system requires modification to multiple services.


A system like this is sometimes referred to as Distributed Monolith and these things are big trouble because it may combine all the downsides of monoliths and all the challenges of microservices and offers very few of the benefits of either approach.

that's why it is very important to have a clear understanding of microservices before diving into creating them or you could end up using Distributed Monoliths and wake up in a world of pain🥲

The Benefits of Microservices

We have already looked at the drawbacks of monoliths, now let's take a look at the benefits of microservices.


  • Small Services:- By breaking down our application into smaller pieces each microservice can be owned by a small development team, and it is much easier to understand and work on. The best thing about the service is to be small enough that it can be thrown away or rewritten if necessary.

  • Technology Choice:- Microservice allow us the freedom to adopt new technology without needing to upgrade everything in one go, and gives us the flexibility to use the right tool for the job *for example:- * one microservice might use a relational database to store data while another uses a document database, one microservice might be written in functional programming language while another might use object-oriented approach. of course, there are still benefits to using standardised approaches where possible but there are no hard requirements. individual microservices teams have the freedom to use the most appropriate technology.

  • Individual Deployment:- When we create microservices they are loosely coupled which means that we can deploy them individually and this is a huge benefit since there is a much lower risk than upgrading everything in the entire system in one go. And it also helps us to achieve zero downtime deployments, and that's because while we are upgrading an individual microservice it's quite possible for the rest of the system to carry on running. The microservice architecture enables the team to deploy with much greater frequency rather than waiting months between upgrades which is often common between monoliths changes to microservices can be pushed to production as soon as they are ready and it is even possible to deploy microservices multiple times a day.

  • Scaling:- Microservices give us much more control over scalability, we can scale out each microservice individually which is much more cost-effective than scaling a monolith.

  • Agility:- Microservices make us more agile we can adapt more rapidly to changing business requirements by keeping our microservices lightweight and decoupled and more easily reusing scenarios.

Downside of Microservices

Hey, you have seen the benefits of Microservices but nobody is totally perfect, right? there must be something always missing someone. So microservices also have some downsides let's discuss them also.

Microservices solve some problems but bring new challenges.

While reading about the benefits of microservices you may think well OK if microservices are so great why don't we use them for everything🤔? ~ well, it's not a free lunch there is something that can be more challenging with a microservices architecture. So in order to understand whether microservices is the right fit for your application or not you must know the downside of microservices.


Developers' productivity:- How can you ensure developers are productive working on the system? do they need to download the code for every single microservice and run it individually and configure them to talk to each other which could be very error prone and time-consuming. You also need to have a way of working that enables developers to easily work on an individual microservice in an isolated environment as well as a test of microservice in the context of the whole application.

Complex Interaction:- If we break an application up into dozens of microservices then it will be very complex to set up interactions between those microservices, which makes it hard to understand the behaviour of the system as a whole. It can also lead to performance issues, if you don't take care you can find that the single operation requires lots of inefficient robust communications between many microservices.

Deployment:- Well deploying an individual microservice is a smaller and safer task than deploying a monolith, when you have many microservices automating deployment becomes critical because you are going to have many more deployments to do.

Monitoring:- If there is a problem in production we don't want to have to connect individually to every single microservice and examine its logs to find out which one is the cause of our trouble. So it is essential to have a great monitoring solution to view logs of all of your microservice in a centralized place.

The good news is there are lots of tools and practices available to overcome these challenges and help you succeed with microservices.

I may write some blogs on some of them in future. For now, that's it Thank You for reading this blog 😊😊


Did you find this article valuable?

Support WeMakeDevs by becoming a sponsor. Any amount is appreciated!