Microservices in app with low load should I use?

Question

My situation is as following:

We have a complex app, and I would like to break it into multiple development teams that can work in parallel. Microservices concept handles it well, but since the app doesn't have high load it's an overkill to host many different microservices. Thus the question: should I use microservies, or it will involve extra cost in Infrastructure?

Can I run microservices on the same machine in separate processes or I need Docker for each?

Every microserivce provide Web Services/REST, can they even be bound to one IIS or Docker is the only option? how will they resolve to the main app? Will I need API gateway?

If not Microservices, anything else I could use to avoid large monolithic application?

BTW, with Microservices - how do they share the same data in one db?

Answer 1

That's a lot of fundamental questions, which definitely need good answers before you proceed with your project. I recommend reading "Building microservices" from Sam Newman.

Answer 2

Usually there are main 3 benefits for adapting microservices:

1. Scalability, which isn't your interest.
2. Maintainability, in which each microservice has a clear usecase which result in a small amount of code, which result maintainability easier.
3. Fault-tolerance, if some microservice fail, others still functioning.

If you care only about complexity, Domain Driven Design can really help here, by dividing your monolith into different domains that can be distributed to different teams. Regarding the architecture, you can adopt normal SOA architecture. If you have a well defined domains, SOA or Microservices is just a deployment architecture then.

how do they share the same data in one db? That is a very abstract question, thus the answer will be a bit abstract. Usually they don't share data in same db, in most cases each microservice will have its own db, some cases a cluster of microservices can share one db.