Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

hackernoon.com

Post reply on HN
Print view View original

21–30 of 93 posts

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

#21

Post by taffer »

ChicagoDave wrote: post #18
taffer wrote: post #12

Earlier quoted context omitted.

> monolithic architectures have a known lifetime while MSA’s tend to mitigate long term coderot I'd say it's exactly the other way around: the programming languages and technologies change every five years or so, but the data stays forever, so why couple the data with the technology du jour? I'd rather have my data managed in one place so I can adapt the technology layers that sit on top whenever requirements change,…

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…

> 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.

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

#23

Post by gcufhg »

ChicagoDave wrote: post #9
taffer wrote: post #5

Completely agree with the article. If each piece of code has its own data store, you lose all the advantages of the DBMS: you have to handwrite your joins, your transaction system and get all sorts of problems with cache invalidation, data inconsistencies and n+1 fetching. Encapsulation is important, but there are better ways to do it, such as using the authorization system of your DBMS.

The only thing that needs a relational data store are reports. Operational data stores should only be concerned with their own domain and expose behaviors and events. There are exceptions, but if you’re building a complex system, monolithic architectures have a known lifetime while MSA’s tend to mitigate long term coderot. It’s hard to see this until you’ve built domain driven micro service based systems properly.

You could build a separate ReportService which replicates only the data that's needed for a report in RDBMS.

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

#24

Post by gcufhg »

taffer wrote: post #21
ChicagoDave wrote: post #18

Earlier quoted context omitted.

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…

> 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.

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.

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

#25

Post by sigi45 »

karmakaze wrote: post #11
jzoch wrote: post #3

This is more likely to be a problem if you split your services up by noun (Users,Orders) rather than by function (makeOrder, loginService, etc). This isn't bulletproof either but I've seen it helps reduce this occurrence a lot. Pardon the poor examples

This is the most important point when making microservices. There's lots of talk about bounded contexts but very little about how to draw the boundaries. Most are superficial and repeat bad examples like OrderService (order is both a verb and boun, OrderingService sounds ok). Using two part service names (ContentComposition, MessageDelivery) usually works out well. As to the shared db aspect, while spitting a miniser…

Why would you make Miniservices?

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

#27

Post by taffer »

gcufhg wrote: post #24
taffer wrote: post #21

Earlier quoted context omitted.

> 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.

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.

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.

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

#28

Post by tyldum »

gcufhg wrote: post #24
taffer wrote: post #21

Earlier quoted context omitted.

> 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.

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.

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.

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

#30

Post by barrkel »

ChicagoDave wrote: post #9
taffer wrote: post #5

Completely agree with the article. If each piece of code has its own data store, you lose all the advantages of the DBMS: you have to handwrite your joins, your transaction system and get all sorts of problems with cache invalidation, data inconsistencies and n+1 fetching. Encapsulation is important, but there are better ways to do it, such as using the authorization system of your DBMS.

The only thing that needs a relational data store are reports. Operational data stores should only be concerned with their own domain and expose behaviors and events. There are exceptions, but if you’re building a complex system, monolithic architectures have a known lifetime while MSA’s tend to mitigate long term coderot. It’s hard to see this until you’ve built domain driven micro service based systems properly.

The trouble is, if you push state into different services behind APIs, you end up reinventing 50 to 80% of RDBMS anyhow. You need transactions, replication, indexing, integrity, backups etc. etc. You can use an event stream (a substitute for a commit log) but then you need to migrate your event stream, be able to undo events in the stream, etc. It's complexity you really ought to avoid unless you need it for serious business reasons.

Monolithic architectures have tended to last for decades in mature industries. I don't think we have a good handle on the lifetime of microservice architectures yet - typically, when they come into being out of necessity rather than fashion, they're part of a startup that hit a major hockey-stick and needed multiple teams working concurrently without stepping on each other, and microservices serve an organizational purpose rather than an architecture purpose.

I will second what other people say: the database tends to stick around. Code may rot, but the data is reused by the next generation.

Post reply on HN