Microservices architecture database location

Question

We have a monolithic application, which we will now convert to the architecture of a microservice using containers.

Our microservices have a state (that is, they need to insert / extract data from db). In accordance with the architecture of the microservice, each microservice must have its own data (for example, a database in our case).

My question is , where should the database of each microservice be deployed, should it be on the same host on which the microservice is deployed, in the same container where the microservice is deployed, or should it be on a separate server, like azure db or something else?

What are the pros and cons of each approach and what is the best approach consistent with the best microservice methods? *

Answer 1

You are right, each microservice should use its own data warehouse that best suits its needs. There may be a service that wants to store its data in the blob repository, another may store its data in the table repository or in DocumentDb or SQL Database.

You will probably want to use Database-as-a-Service without having your own db, because you do not need to worry about availability, scaling, backups ...

Answer 2

Martin's answer is good, but I want to add that since you are using a container application, you definitely need to deploy the database separately from your service containers. The reason is that your services can evolve (independently), and one of the biggest advantages of stateless service containers is that if you have their cluster, you can update them with rolling updates without any effect on the availability of your application. Updates to the state database services are more complex, but they are also expected to be less frequent (and new technologies such as cockroachdb are on the horizon). Good to read .

Answer 3

It doesn’t matter to me where it is so much, except that it cannot be inside one container, as indicated earlier in this topic.

The important part is that only one (1) microservice has ownership of the data. If access to data is required by more than one microservice, they must access it through the API provided by the microservice to which this data belongs .

You can structure it like this:

"Sql Microservice" - processes all traffic to and from SQL Server. All microservices that need data from Sql communicate with these guys. You will have a similar microservice for TableStorage.

If "microservice A" uses a different data store from Sql / TableStorage and this data store is local to Microservice A, I would create 2 microservice.

Microservice A1 will be at the place where your code runs. Microservice A2 has an API that provides access to the database for A1. When A1 needs data, he talks to A2.

Besides the fact that this template allows you to scale the data level regardless of the application nodes, you also guarantee that the data belongs to only one (1) microservice and that the key is . Single owner