Is a shared database in microservices actually an anti-pattern?

Re:Is a shared database in microservices actually an anti-pa... by ChicagoDave on Sunday February 24, 2019 @02:08PM (#19240028)

Because business complexity modeled relationally becomes stale over time, reduces agility, and develops massive amounts of code rot/tech debt.

Relational databases are tools to be used where it makes sense. NoSQL tables are tools. Graph databases are tools. Configuration files are tools.

Given your statement, Linux’s entire configuration footprint should be in a relational database.

As any good architect will say in response to a design question, “It depends.”

MSA’s aren’t a panacea either. Event Streams are an interesting development and new patterns are likely to emerge.

But today? I’d focus on reducing complexity with domain-driven design and choosing patterns that enable agility and support separation of concerns. MSA fits very well into that philosophy.

[ Parent | on HN ]

Re:Is a shared database in microservices actually an anti-pa... by taffer on Sunday February 24, 2019 @02:30PM (#19240122)

> As any good architect will say in response to a design question, “It depends.”

I absolutely agree with that. However I don't like being strawmanned. I never said linux configuration "should be in a relational database". I said I'd like to have my data in one place to reduce complexity and decoupled from the layers above.

[ Parent | on HN ]

Re:Is a shared database in microservices actually an anti-pa... by gcufhg on Sunday February 24, 2019 @04:05PM (#19240603)

You can for the start use a single database as long as the different services don't use / know about each others tables. Then again you could just use separate db's.

[ Parent | on HN ]

Re:Is a shared database in microservices actually an anti-pa... by taffer on Sunday February 24, 2019 @05:16PM (#19240981)

Sure, but as I said, if you split your database, you have to deal with transactions, joins, consistency, over- / underfetching. All this leads to complexity and performace issues you wouldn't have otherwise.

[ Parent | on HN ]

Re:Is a shared database in microservices actually an anti-pa... by ChicagoDave on Sunday February 24, 2019 @06:26PM (#19241335)

Reliable messaging and eventual consistency eliminates the need for transactions. Performance can be a mitigating factor. Joins are for reporting. In the cloud, performance is just a cost factor.

[ Parent | on HN ]

Re:Is a shared database in microservices actually an anti-pa... by taffer on Sunday February 24, 2019 @07:06PM (#19241559)

Eventual consistency makes everything even more complicated and I am by far not the only one who says so [1].

[1]: https://cloud.google.com/blog/products/gcp/why-you-should-pi...

[ Parent | on HN ]

Re:Is a shared database in microservices actually an anti-pa... by tyldum on Sunday February 24, 2019 @05:18PM (#19240989)

Agreed. One DB to focus resiliency on, but every table or database is owned by a single service and managed using migrations.

You can optimize that away later if necessary.

[ Parent | on HN ]

Re:Is a shared database in microservices actually an anti-pa... by wrmsr on Sunday February 24, 2019 @02:18PM (#19240076)

Given your statement we should all be running GHU Hurd.

[ Parent | on HN ]