When we should not to use microservices?

Question

In which scenario, we should not use micro services architecture? So far I can see the design for micro services, looks good for many use cases.

One of the basic use case I will not recommend for POC (Proof of concepts) projects.

Rhapsodize

Answer 1

This is a very broad, and possibly, very opinionated question. I would not advocate the use of micro services when you have a single application with many shared dependencies that is generally always deployed as a unit.

Micro services are great, and they have their place - but if your application is of a such a nature that it's always deployed as a unit, micro services can seriously expand complexity - now you're deploying a multitude of separate artifacts, all at once, instead of just a single application. The example that comes to mind for me is an ERP system.

Edit: And to expand on this, micro services shouldn't be your default architecture for an application. Keep it as simple as possible, and if you run into scalability issues, or something else that justifies going the micro services route, then do it. Keep it as simple as it can possibly be. So, IMHO, the answer to "when should I not use micro services?" is "when you don't need them".

See YAGNI.

Salt

Answer 2

In which scenario, we should not use micro services architecture?

You don't have to apply the microservices architectural style for scenarios that do not come with the problems that the style tries to solve. So which problems are those?

Before giving the answer - Microservices is a buzz word and describes an architectural style that tries to answer the age-old question of "how to break an application into logical components". While there is no exact definition, it usually comes down to independently develop-able and deploy-able components with a specific domain purpose. So with that in mind - Here are the problems that the microservices architectural style tries to solve:

1. The most important problem is scaling development in large organizations. Microservices allow independent teams to move fast with independent release cycles. Compare that with a large "monolith" that has to aggregate all dependencies and can spit out a release every couple months at best. So whenever a company is trying to organize hundreds of developers to develop a large server based application they should probably look into setting up teams being responsible for microservices. This is because "Architecture follows Organization" (Conway's law).

2. Scalability of the application itself. In conjunction with a stateless design the services can be deployed at scale in a clustered fashion. So whenever the user base is supposed to be growing over time you will most likely benefit from a microservices architectural style.

3. Enforce separation of concerns. In a "monolithic" development it is common to minimize persistent data schemas and have many components use the same database persistence. This increases complexity by adding indirect dependencies and thus adds to the communication and organizational overhead of releasing new software versions. Microservices are not allowed to share data persistency so this issue can be avoided.

4. Communication issues. If the communication between components is not well defined, the effort for reusing components increases drastically. Especially over the lifecycle of multiple versions of a component. Thus the microservices architectural style has a strong focus on well defined interfaces to the outside world. This includes the definition of interface versions (Major/Minor) for downstream consumers.

Then about your conclusion:

One of the basic use case I will not recommend for POC (Proof of concepts) projects.

Based on the above points your statement does not necessarily hold true. If it is a POC development with a large team and you anticipate any of the mentioned problems you will still benefit from the microservices architectural style.

Logography