Dec 19, 2018
Blasphemy! Multiple microservices, shared database.
Originally published on https://oprea.rocks/blog/multiple-microservices-shared-database/
Here are some of my thoughts on microservices. It’s a small rant, but if you bare with me, you’ll also get some value from it.
We’ve come to believe that some microservices rules are set in stone. The microservices cargo-cult is getting bigger and bigger.
You need to have 30 services and each of them should be no bigger than a couple of functions.
You shouldn’t use a single database for multiple services.
It’s not a microservice if it takes more than 2 weeks to build.
It’s not a microservice if it requires more than an “2 pizza team” to work on it.
Here are some of my thoughts on the database thing. The rest are just laughable as they stand, I don’t need to comment.
“Why can’t a shared database exist in the microservices realm, yet a message bus can?
At the end of the day, both the database and the message bus are I/O devices. Using table events on PostgreSQL to mimic a message bus, or using Redis’ pub/sub system in the same manner or using a message bus are one and the same thing. They’re just at different levels of “specialization”.
After building microservices for almost 5 years I have come to the conclusion that monoliths are far superior, especially when starting something.
You may say that a single database for multiple services is a no-no. Even if it had clearly defined tables and no cross-querying between the tables of one service and the ones of a different service. But in the microservices world the networkis your biggest point of failure.
Yes, let me write that again, for you to print and stick to your walls or tweet it or whatever people do these days: In the microservices world, the network is your biggest point of failure.
Get over the “But Amazon/Netflix/Google does it” mentality. All these companies have an average of 1000 software developer jobs to fill, any given day. To make it clearer, any day of the week, Amazon has around 1000 open software developer positions.
You may have 10, 20, 50 developers. Stop it with the cargo-cult!
Over & out!
