3 ms·

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

by taffer 8y ago

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

ChicagoDave 8y ago
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.

by taffer 8y ago

ChicagoDave 8y ago

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.