When You should Not use Microservice Architecture? (Answer)

 Hello guys, recently while giving interview in one of the big US based Investment bank I was asked about, what are the scenarios when you shouldn't be using Microservices architecture? When I hear this question I was big surprised not because I didn't know the answer but because most of the people ask about using Microservice architecture and this was the first time I am hearing otherwise. To be honest, it's a good question because most of the candidate will prepare about benefirst about Microservice architecture and they may not know when it's not appropriate to use it. Since I have worked in low latency high frequency application, I knew that multiple process means more latency so clearly a Microservices is a big no if you are working on a high frequency low latency application. In those cases you want to do all your calculations inside a single thread or process without even swapping memory to avoid delay. Hence the first answer to this question was, you shouldn't be using Microservice in a low latency application. 

While this is a very good answer on technical point, it doesn't do full justice if asked to a senior programmer and team leader because Microservice architecture is not just about performance its also about ease of development and teams. 

One of the main benefit of Microservice architecture is that it allows multiple people to work on their services independently. For example, consider Uber, one of the pioneer of Microservice architecture and image if you are working on an app for drivers and your friend is working on app for customers then you both can start working simultaneously without being dependency upon each other. 

Microservice breaks a big application into small or should I say "micro" services so that multiple people can work and take care of them. This strategy work really well when you have a lot of people and you are on growth mode but if you have a small team, its not necessary to break your application into small parts as it will only create maintenance overhead. 

For small teams, I think monolithic application is better choice in most of scenarios, you don't need to deploy hundred of services and then monitor and support them, its a burden and big one. It's much easier to support few services, mostly between 1 to 5.

Another case for not using Microservice architecture is when you are not using clouds and deploying on premise. With the cloud, scaling is very easy as you don't need to set up new servers, order hardwares etc, but if you are not using Cloud then these are big task and if you go for Microservice architecture then you will probably need more servers which will burden you or your support team with additional setup and maintenance. 

I still remember when it takes days to setup the server and then test the new instance of your application, do all the processed, raise multiple requests, chase multiple peoples, it wasn't just technical things but also handling all the bureaucracy. 

Hence Microservices architecture is also not suitable for small teams with 1 or 2 people. While in my case I think interviewer got impressed with my answer and I got the offer.

That's all about what are scenarios and circumstances where you are not supposed to use Microservices architecture. Low latency, small teams and not using Cloud are definitely scenarios where you can avoid Microservices architecture. 

Btw, How would you answer this question if it was asked to you on interviews? What are other points you can add or improve into my answer. I think its a really good question and shows your understanding of Microservices architecture.