I just stumbled upon this article by Roman Krivtsov on YC News Is shared database in microservices actually anti-pattern?. As a seasoned DBA in another life, I was intrigued by the title.
I devoured the piece.
Join 38,000 others and follow Sean Hull on twitter @hullsean.
One quote at the end really sums things up…
In the very beginning you probably don’t need microservices. Start with monolith and see, if you really need them in future.
Here’s my takeaway from it.
1. DB access by proxy
As the database itself is a service, does it make sense to use a microservice to essentially front the database? By doing that we simply add a layer of abstraction, need to keep the API up to date, and eat the network and compute expense of interacting with that data by proxy.
Related: When you have to take the fall
2. Changing db schema or service API
In a traditional database, when we update a schema, we can keep the old columns around, and simply add new. Thus we are backward compatible.
With the one db per microservice model, we must update the API everytime we add and change schema. This requires a lot more coding, and maintenance. It also means more nuance to remain backward compatible.
3. Consistency of data on restore
This is one factor that is often forgotten. Suppose you have an orders service and users service. The Users db behind the users service fails, and must be restored. When the db is restored, a new user that happened just before failure, is lost. However, the Orders service still has a record which references that lost user. What then?
From there we would need a cleanup routine that would go around and remove inconsistent child records after failure. Alternatively we would need a way to backup all dbs from all microservices in a consistent point in time manner. *NOT* an easy task.
Shared database solves these problems in an elegant way.
Related: Why i ask for a deposit
4. Improving performance
Allowing access to orders & users tables in the same db call means eliminating all those slow API calls, associated network congestion and more. It centralizes that, allowing you to do SQL joins. Here the database does the heavy lifting of slicing and dicing, and returning only the packets of data you need.
5. Should we bring back db admin job role?
When we centralize our database, we also centralize responsibility. There too, we return to the old debate of ops versus devs. I wrote an article years back titled the four-letter word dividing dev and ops.
When we have a job role for the database management, they have a mandate. Ensure backup & recovery, consistency & performance. Watch things. Monitor. Provide care & feeding. Put fences around applications, and constraints on data going in and out.
All these things are good things. And just like you want a building inspector to be different from the building developer, so too you want those separation of job roles in the software arena.