Microservices and database

Question

What is the best practice to deploy database in microservices architecture, more precisely in distributed environment, such as docker swarm? Microservices principles states each service should be stateless to enable scaling. As database obviously has a state, should it live at fixed position outside of cluster, deployed and configured before the cluster is initialized?

I'm confused, because all docker compose examples includes database container in the service definition. But things aren't that simple. Often the database needs a lot of configuration before it's ready to use. Also, docker sucks at coordinating the service starting order.

If it's really a good practice to deploy the database alongside with services to docker swarm, how to ensure consistency and persistence of cricial data?

Answer 1

This is a good question and one I think a lot of people are still thinking through as far as best practices are concerned. The answer really depends on your needs. There are several ways to crack this nut but these are the two I'm using right now:

• Running the database in the typical manner on dedicated machine(s) with replication, etc
• I am currently experimenting with running the database as a service on a Docker Swarm cluster with the data persisted across the cluster with GlusterFS
  • I have three machines in the cluster labeled as database machines
  • These database machines all run a GlusterFS container providing the GlusterFS capabilities
    • When the database service is started I map the GlusterFS share into the container and specify that the service should only run on a machine labeled as a database node. With this setup it doesn't matter which node the database service starts on and if a machine fails the database service is automatically migrated to another node labeled as a database node. The GlusterFS replication of data ensures the integrity of the persisted data.

As mentioned, it is my understanding that there is still a lot of experimentation going on with this and 'best practices' are not entirely established. Those best practices will ultimately depend on your needs and risk tolerances.