5 ms·

> Data sovereignty per microservice > An important rule for microservices architecture is that each microservice must own its domain data and logic . Just as a

> Data sovereignty per microservice > An important rule for microservices architecture is that each microservice must own its domain data and logic . Just as a full application owns its logic and data, so must each microservice own its logic and data under an autonomous lifecycle, with independent deployment per microservice. https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/data-sovereignty-per-microservice https://learn.microsoft.com/en-us/dotnet/architecture/micros...

JamesBarney 4y ago
The big issue I've seen is that takes a lot of work, so people cut corners. The problem is of course when you cut corners with microservices and rely on a shared database for instance, suddenly you're dealing with 40% of the costs of a microservices and 0% of the benefits.
- GauntletWizard 4y ago
  Shared database can be a reasonable microservice boundary, especially when using database-as-queue or database-as-mucroservice. In the former, services a, b and c can insert and query but only D can update, i.e. any service can creat a work-order but only D can mark it completed. I. The latter, nobody can read or write and all access to tables is done through stored procedures. I don't recommend either, and it's still a code smell, but with clear definitions they can work.
  - JamesBarney 4y ago
    The benefits of the microservice pattern are you can build separate teams responsible for different business logic, and they can have their own deployment schedule. You don't get either of those benefits when a b and c have to coordinate on their work-order creation business logic, and a, b, c and d all need to be deployed at the same time anytime the schema changes. Btw some of the confusion might be what I mean by shared database. I didn't mean two services sharing a limited set of tables, using the database as a rabbitmq replacement. I meant sharing the backing database of the microservices. It sounds like we probably agree I just wasn't very clear about what I meant by sharing a database. (Ironically I am literally using a database as a queue to share data between two services we are running in prod. I don't think of it as a microservice because it's not separate teams, it just because our monolith is hosted on a platform that doesn't support certain libraries so we had to role those libraries onto a separate platform that does support them.)
    - GauntletWizard 4y ago
      I think we're in violent agreement - A database can be a queue and that doesn't link things as the same, but it's easy to break those promises and you need to be clear in that promise to begin with. If two "microservices" have to move in strict lockstep, they're not microservices, they're components of a larger service.
- P5fRxh5kUvp2th 4y ago
  That's completely untrue and glosses over the very real costs of transaction management in such an environment. Using a shared database allows you to punt a lot of that complexity to a system that's been specifically designed for it, and working well for probably 20+ years. Too many people think microservices don't have their own, severe, downsides. The likes of netflix, google, et al, can afford to pay people whose entire job is to manage the complexities of these approaches that flat don't exist in other scenarios. But it's a hell of a lot simpler to use a single database if you can get away with it.

JamesBarney 4y ago

The big issue I've seen is that takes a lot of work, so people cut corners. The problem is of course when you cut corners with microservices and rely on a shared database for instance, suddenly you're dealing with 40% of the costs of a microservices and 0% of the benefits.

GauntletWizard 4y ago
Shared database can be a reasonable microservice boundary, especially when using database-as-queue or database-as-mucroservice. In the former, services a, b and c can insert and query but only D can update, i.e. any service can creat a work-order but only D can mark it completed. I. The latter, nobody can read or write and all access to tables is done through stored procedures. I don't recommend either, and it's still a code smell, but with clear definitions they can work.
- JamesBarney 4y ago
  The benefits of the microservice pattern are you can build separate teams responsible for different business logic, and they can have their own deployment schedule. You don't get either of those benefits when a b and c have to coordinate on their work-order creation business logic, and a, b, c and d all need to be deployed at the same time anytime the schema changes. Btw some of the confusion might be what I mean by shared database. I didn't mean two services sharing a limited set of tables, using the database as a rabbitmq replacement. I meant sharing the backing database of the microservices. It sounds like we probably agree I just wasn't very clear about what I meant by sharing a database. (Ironically I am literally using a database as a queue to share data between two services we are running in prod. I don't think of it as a microservice because it's not separate teams, it just because our monolith is hosted on a platform that doesn't support certain libraries so we had to role those libraries onto a separate platform that does support them.)
  - GauntletWizard 4y ago
    I think we're in violent agreement - A database can be a queue and that doesn't link things as the same, but it's easy to break those promises and you need to be clear in that promise to begin with. If two "microservices" have to move in strict lockstep, they're not microservices, they're components of a larger service.
P5fRxh5kUvp2th 4y ago
That's completely untrue and glosses over the very real costs of transaction management in such an environment. Using a shared database allows you to punt a lot of that complexity to a system that's been specifically designed for it, and working well for probably 20+ years. Too many people think microservices don't have their own, severe, downsides. The likes of netflix, google, et al, can afford to pay people whose entire job is to manage the complexities of these approaches that flat don't exist in other scenarios. But it's a hell of a lot simpler to use a single database if you can get away with it.