Deploying a microservice with its own database: how to guarantee replication and reliability?

7/29/2020

I am building an application to be deployed in a cloud environment. I am using Kubernetes with Docker.

My image contains two containers: one for the application, and another with Postgres DBMS (including its own database that is stored through a persistent volume claim).

I did it like this because this way I could scale my application linearly, as my main requirement is to be able to scale it like that.

So when I scale my deployment, it will look more or less like the draw bellow (having N pods of my application): enter image description here

I have done performance tests into this architecture, and it works very well for my needs, and it scales as I needed too.

However, I am worried about the data replication and its reliability.

So here are my questions:

  1. How to do replication with this type of architecture? Is there a way in which Kubernetes takes care of it through a specific storage class? What is the best approach?

  2. In general, what is a DBA expectation when looking into this architecture? Is it acceptable as I may end up with too many databases?

-- José Carlos Ribeiro
cloud
database-administration
docker
kubernetes
microservices

1 Answer

7/29/2020

Postgres scaling cannot be performed as you suggested and persistent volumes cannot be mounted in read/write mode in multiple pods (with a few exceptions)

To scale Postgres you can consider CrunchyData

More over, decoupling the application layer from the DB, has many benefits, including the granular control of the scaling policies upon each layer.

<br>

PS: Nice diagram. It makes the question very intelligible.

-- Neo Anderson
Source: StackOverflow