Hacker News Reader

Comment by taffer | Hacker News Reader

> 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, rather than writing joins and transactions in my application code. I'd rather not bother with all the complexity and keep it simple as long as I don't need an Amazon or Netflix scale.

View on HN

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.

Given your statement we should all be running GHU Hurd.

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

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.

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

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.

Reply on news.ycombinator.com