Microservices may not be the answer you need.

6 min readJun 30, 2020

Microservices is the hot thing every team is doing. It’s true. Be it a new project, redesign or a simple back end application, we are all building microservices.

The idea that we can build a very big complex application by breaking it into smaller, functional APIs that communicate with each other in order to perform tasks is captivating and makes us want to do it even more.

The world of microservices is fascinating.

It brings the Coding 101 lessons into architecture pattern, i.e. build small, modular and functional components.

Now microservices is not exactly brand new, well at least not in the modern day sense.

Dr. Peter Rogers introduced the term “micro web services” during a cloud computing conference in 2005.And later in 2011,“Microservices”, the term that we know of, was featured in another conference, experimenting with the idea of small, modular and reusable components. Netflix and Amazon were among the early pioneers of microservices.

We have come a long way since then, and every other team is doing microservices but do we need microservices for the projects we are doing or are we overkilling it ?

Many teams are guilty of this, including me. If I look back now, there were couple of projects where we could have just build one monolith app (or may be two) and it still would have worked perfectly and probably would have been easier to maintain.

Microservices are all around us, do you need them ?

Here are some arguments that came up multiple times during our initial discussions and , although were valid then, does not look like it after retrospection.
So, if you are someone who is also having these thoughts, take a read and avoid missteps.

My team can pull it off

Look at your team objectively and have an unbiased opinion. Microservices, although fun, could also lead to potential system wide failures if not implemented correctly. It is not something you can figure out on the go. The design elements need to be carefully thought through and the principles needs to be rigorously maintained. Errors, often small, cause big troubles.
Let’ s be honest, not all teams have developers like that of Netflix.
May be you have, if they move out of the team, can you get good enough replacements ?

Development, deployment, traceability, debugging etc. gets complex as we grow our microservices design. Monoliths are simpler, much simpler. Even if you can design the system perfectly, can you always have an overwatch about the code that is being written or the way it is written? Do you even want to have an overwatch ?

So, have an unbiased opinion, can your team really pull this off? If the answer is NO, all the right reasons in the world would not matter. May be start with getting the right people in the room if you absolutely have to build microservices.

We avoid making one big unmaintainable application

This is actually very convincing. This is often used as a synonym for microservices.
Let’s ask these questions instead:

Is the current application big enough or complex enough ?
Is the application that’s going to be built, complex or big enough to be split ?
Or what is big for your team ?

Big can be subjective, so the decision must be scrutinised whether it holds true value.
If the answer is “not big enough”, then the decision becomes, “We avoid making one application by making multiple applications”. And it’s a disaster.
Once we went from 4 applications to 26. It isn’t fun, trust me.

And once we walk down this path, there’s no looking back.

We can choose a different tech stacks or switch them if needed

One cannot be more wrong.
Yes, there could be some cases but usually those can be taken care of with correct planning up front.
Let’s take an example:

The above tech stacks are extremely good, no doubt about it.
But let’s take a case where Team one chooses stack “A” and few days later Team two selects stack “B”, even though they are great you don’t want to be in a situation where some one from Team two leaves and suddenly you are in a middle of a storm because developers in your team do not know the stack by Team one.
NEVER mix tech stacks, not at least in the same team.
So, ability to choose multiple tech stacks shouldn’t be a criteria at all to select microservices. That’s NOT what microservices is all about.

Also, if you have multiple tech stacks you will have to write common codes, utilities over and over again. Reusability goes for a toss.

If only one of the services has high demands, it can be scaled up leaving others as is

This is something that often comes up, when designing architecture with Functions or Lambdas . This is actually valid when backed with correct data.
Yes, that’s right, with correct data. Many a times we complicate our architecture assuming that one day we are going to have tremendous traffic increase.
Services’ demand do not magically increase overnight. There is nothing wrong with having the capability to do so but if it complicates the design with no concrete evidence to support the fact that the demand may increase, we shouldn’t do it.

Teams can work independently

To be honest, I don’t know if it is an argument solely for microservices.
Teams can work independently in Monoliths as well, all youneed is a good and agreed design.
If by working independently, you mean working in silos where the teams are not talking to each other, that’s a sure way to fail irrespective of what or how you are building software.

Teams MUST talk to each other.

Or the following might happen:
Let’s say an API structure was shared among teams, where one the field is country and if the structure does not make it explicit and the teams are not talking to each other you may have:
One team building this:

{
   "country":"NETHERLANDS"
}

And another team building this:

{
  "country":"NL"
}

This is a classic example of lack of communication irrespective of how things are being built. This causes a LOT of troubles. So, be careful about “Teams can work independently” and make sure what “independent” means.

New components can be added or deployed without affecting others

This is the most important of all.

This also falls under the category of SEPARATION OF CONCERN.

Now, this is also actually one of the reasons why one should consider microservices. But good design principles must be enforced or things will go out of your hands very fast.

With microservices separation of concern is a boon but if not implemented correctly, it become a curse and I must add, quite a dangerous one.
Few things that may break the system:

Small updates often need big changes
Most of the times, we build common packages and utilities. If for some reason, you change or update a common package. Or may be you fixed a bug in that package, you need to deploy all the application that are currently on the version. If some are on older versions, may be bring them up to speed. Making siloed components is a difficult task, one should not take it lightly
Unwanted dependencies with external applications
Sometimes, all you want to do is pass a harmless parameter and save it. But in order for that to happen, the request needs to pass through couple of application before it reaches the destination. You need to make changes in all of them. May be even deploy them. This is true for most of the microservices implementations out it the world.
We should be well aware of the implications of our design decisions.
Shared tables/collections
This is a crime. Sharing tables or collections is a sure shot way of failing spectacularly in implementation of microservices.
Each component in microservices should have it’s own table. That table should only be available to the aforementioned component. The moment the table is shared, data integrity is compromised. One app may add extra column (because it needs it) and you have code RED in production.

Now, there could be many more reasons where things could go wrong but I wanted to highlight a few of them so that one can course correct early and easily.
If these made you think, it’s good. You would make an informed decision. if you already have mitigated these, even better.

Also, this wasn’t a monolith vs microservices. Each one has it’s pros and cons and is suited for solving a certain problem.

All being said, this wasn’t meant to scare you off. I have seen many projects where microservices design was implemented with near perfection and they are running smoothly.

Have fun building microservices and make new mistakes ;) .