6 ms·

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

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.

wrmsr 8y ago
Given your statement we should all be running GHU Hurd.
taffer 8y ago
> 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.
- gcufhg 8y ago
  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.
  - taffer 8y ago
    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.
    - ChicagoDave 8y ago
      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.
      - taffer 8y ago
        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-pick-strong-consistency-whenever-possible https://cloud.google.com/blog/products/gcp/why-you-should-pi...
  - tyldum 8y ago
    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.

wrmsr 8y ago

Given your statement we should all be running GHU Hurd.

taffer 8y ago

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

gcufhg 8y ago
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.
- taffer 8y ago
  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.
  - ChicagoDave 8y ago
    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.
    - taffer 8y ago
      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-pick-strong-consistency-whenever-possible https://cloud.google.com/blog/products/gcp/why-you-should-pi...
- tyldum 8y ago
  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.