Deploying microservices and their databases on separate nodes

Question

I have a general question concerning microservice applications and their deployment.

Based on the pattern, due to loose coupling and separation of concerns, that every microservice should have its own database (if needed) is clear. However, can these couples of microservices and databases be separated exclusively and be deployed on separate hardware nodes?

For example, if I use Docker, can I deploy the microservice X and corresponding database X in two different containers residing in two different machines with separate IP-addresses?

It should be possible with the extra afford. However, what makes me curios is actually what would speak for or against such an approach? Would there be any gain by doing it? Or would it be just an over-engineering?

Answer 1

For example, if I use Docker, can I deploy the microservice X and corresponding database X in two different containers residing in two different machines with separate IP-addresses?

Yes, that's what I would suggest you do, because your microservice and datastore can scale independently and you can set up monitoring, metrics and alerts independently (for the metrics that matter to that service).

Downside: Well, you will have a bit of network latency, and you will have to maintain two different "machines".

NOTE: "Two different machines" is arguable, as you may end up in 2 different VMs in the same physical machine unless you go with the bare metal machines in your own data center.

Answer 2

Reason why you are asked not share databases is to make sure that you connect with other services only via api contracts and nothing else, giving you freedom to change anything behind your apis.

Now whether you deploy all your services on one node or n different nodes are not dictated by microservices. It is dictated by your requirements, your scale and how resilient you want system to be.

If you need to scale you can do that by deploying same container on same node multiple times, but that will not give you fault tolerance, your machine goes down and you service is down. Having them on two different nodes, or on two different places altogether depends on your requirements. There are pros and cons to each one of them, and that is the choice you have to make.

Today infrastructure can be abstracted from you. You work on kubernetes, and you might not know or need to worry about if your app is deployed on same node or on different ones. You are concerned with availability and as long as the underlying system guarantees that to certain extend you should be good.