5 ms·

There’s a model of software based around shipping events around, and subscriptions between systems. The purposes of separation are at least a couple important,

There’s a model of software based around shipping events around, and subscriptions between systems. The purposes of separation are at least a couple important, perhaps you know. Each has a DB, often embedded, that is suitable and materialized from the subscriptions and its own; mutated predictably.

Glyptodon 6y ago
Transmitting events is fine, I like transmitting and receiving events. But if you end up having a bunch of DBs with a lot of overlap I don't know how much you're gaining as it pretty much turns into another permutation of DB sharding. Of course microservices done wrong doesn't mean event-based systems done right are bad.
- rualca 6y ago
  > But if you end up having a bunch of DBs with a lot of overlap I don't know how much you're gaining You're gaining component isolation and separation of concerns, and the ability to scale services horizontally without bothering about shared state. Also, you gain the ability to develop each system without having any constraint imposed by third parties. In other words, you're making your service not only simpler but also more robust, easier to operate and maintain.
  - danmaz74 6y ago
    Each individual microservice becomes simpler, but the whole system becomes much more complex than an equivalent monolith with a single DB. Microservices have their advantages, but simplicity and testability aren't part of them.
    - rualca 6y ago
      > Each individual microservice becomes simpler, but the whole system becomes much more complex than an equivalent monolith with a single DB. Indeed a distributed system forces developers to think through how dependencies communicate, which otherwise would be taken for granted. However, that misses the whole point of microservices. Services are peeled off monoliths because the monolith no longer meets operational requirements, which is trivial to provide with a distributed system. I'm referring to aspects such as reliability, or ceasing to be able to scale vertically. In addition, some people simply mindlessly develop monoliths not realizing they already have a distributed system, once we account for the fact that managed services and even running a database already opens that door wide open. > Microservices have their advantages, but simplicity and testability aren't part of them. Not really. Contary to your claim, microservices make systems more easy to test. The only thing that changes is that you're no longer able to drop a breakpoint in a request and track it all the way through a database. However, you get cleanly separated components with very crisp boundaries that make it trivial to test interactions. Perhaps the main cultural clash that is added by moving from a monolith to a distributed system is that developers start to need to thing things through when they put up an interface.

Glyptodon 6y ago

Transmitting events is fine, I like transmitting and receiving events. But if you end up having a bunch of DBs with a lot of overlap I don't know how much you're gaining as it pretty much turns into another permutation of DB sharding. Of course microservices done wrong doesn't mean event-based systems done right are bad.

rualca 6y ago
> But if you end up having a bunch of DBs with a lot of overlap I don't know how much you're gaining You're gaining component isolation and separation of concerns, and the ability to scale services horizontally without bothering about shared state. Also, you gain the ability to develop each system without having any constraint imposed by third parties. In other words, you're making your service not only simpler but also more robust, easier to operate and maintain.
- danmaz74 6y ago
  Each individual microservice becomes simpler, but the whole system becomes much more complex than an equivalent monolith with a single DB. Microservices have their advantages, but simplicity and testability aren't part of them.
  - rualca 6y ago
    > Each individual microservice becomes simpler, but the whole system becomes much more complex than an equivalent monolith with a single DB. Indeed a distributed system forces developers to think through how dependencies communicate, which otherwise would be taken for granted. However, that misses the whole point of microservices. Services are peeled off monoliths because the monolith no longer meets operational requirements, which is trivial to provide with a distributed system. I'm referring to aspects such as reliability, or ceasing to be able to scale vertically. In addition, some people simply mindlessly develop monoliths not realizing they already have a distributed system, once we account for the fact that managed services and even running a database already opens that door wide open. > Microservices have their advantages, but simplicity and testability aren't part of them. Not really. Contary to your claim, microservices make systems more easy to test. The only thing that changes is that you're no longer able to drop a breakpoint in a request and track it all the way through a database. However, you get cleanly separated components with very crisp boundaries that make it trivial to test interactions. Perhaps the main cultural clash that is added by moving from a monolith to a distributed system is that developers start to need to thing things through when they put up an interface.