3 ms·

> is only good advice if the tables are application specific data Isn't that the whole point? > and you don't do microservices in that stupid braindead way th

by rualca 6y ago

> is only good advice if the tables are application specific data Isn't that the whole point? > and you don't do microservices in that stupid braindead way that (...) I feel that this cynical jab is not only set as a flimsy straw man but also adds absolutely nothing to the discussion. Independent services need to have their own independent database. Simple. Each service has its bounded context, persists it in its database, and just runs. It matters nothing what data the bounded context holds or what your opinions are on microservices.

jayd16 6y ago
A lot of posters here seem to have been deeply burned from microservices designed along the wrong lines. I mean, sure, it happens. You're going to make mistakes just like you can misjudge how to separate concerns in a set of classes. It shouldn't be an issue to fix it. Maybe some teams focus on pure separation before they have a solid design? Maybe its just a culture of feeling like service boundaries can never change? I don't really get it either.
- etripe 6y ago
  I think what we're seeing here is Conway's law in action. Most places I've worked don't define their bounded contexts based on separation of concerns, but rather on separation of reporting. That is: team A has been given arbitrary stewardship of generic app functions T, U, V based on management purview. Team B has been given stewardship of generic functions W, X, Y, Z. So the bounded context is along those lines. But wait, both V and W are related to billing, you say? No matter! Since the cliché is you can't solve people problems with technology, the same applies to micro-services: it's much harder to convince managers to shift accountability than it is to move the code from one micro-service to another. Even if you do move the code, you get to have your shit and eat it, too.
  - rualca 6y ago
    > I think what we're seeing here is Conway's law in action. Most places I've worked don't define their bounded contexts based on separation of concerns, but rather on separation of reporting. You're not wrong. I mean, one of the goals of microservices is to peel off responsibilities to a service that can be owned and managed by a small team. However, what I've been seeing in these anti-microservices rant is developers struggling to acknowledge the need to reason with loosely coupled interfaces, reason about partial system failure modes that were always there in monoliths but we're either ignored or turned into critical system failures, and the microservices tax.
    - Glyptodon 6y ago
      I think some of the problems I've encountered are related to teams trying to do microservices before each service can actually have a small team.
  - Glyptodon 6y ago
    That pretty much sounds like my workplace in action.

by rualca 6y ago

jayd16 6y ago

A lot of posters here seem to have been deeply burned from microservices designed along the wrong lines. I mean, sure, it happens. You're going to make mistakes just like you can misjudge how to separate concerns in a set of classes. It shouldn't be an issue to fix it. Maybe some teams focus on pure separation before they have a solid design? Maybe its just a culture of feeling like service boundaries can never change? I don't really get it either.

etripe 6y ago
I think what we're seeing here is Conway's law in action. Most places I've worked don't define their bounded contexts based on separation of concerns, but rather on separation of reporting. That is: team A has been given arbitrary stewardship of generic app functions T, U, V based on management purview. Team B has been given stewardship of generic functions W, X, Y, Z. So the bounded context is along those lines. But wait, both V and W are related to billing, you say? No matter! Since the cliché is you can't solve people problems with technology, the same applies to micro-services: it's much harder to convince managers to shift accountability than it is to move the code from one micro-service to another. Even if you do move the code, you get to have your shit and eat it, too.
- rualca 6y ago
  > I think what we're seeing here is Conway's law in action. Most places I've worked don't define their bounded contexts based on separation of concerns, but rather on separation of reporting. You're not wrong. I mean, one of the goals of microservices is to peel off responsibilities to a service that can be owned and managed by a small team. However, what I've been seeing in these anti-microservices rant is developers struggling to acknowledge the need to reason with loosely coupled interfaces, reason about partial system failure modes that were always there in monoliths but we're either ignored or turned into critical system failures, and the microservices tax.
  - Glyptodon 6y ago
    I think some of the problems I've encountered are related to teams trying to do microservices before each service can actually have a small team.
- Glyptodon 6y ago
  That pretty much sounds like my workplace in action.