3 ms·

I heard of one group that had a consultancy replace their monolith with set of microservices + enterprise service bus - all communicating with a single database

I heard of one group that had a consultancy replace their monolith with set of microservices + enterprise service bus - all communicating with a single database on the back end. The first job of the development team every morning was to review the error logs for locks and timeouts and retrigger failed messages on the highly scalable message queue.

xwolfi 5y ago
One thing I ve been painfully working on is upgrades as well. We have, in our bank, 2 system, one to trade with exchange automatically, one to approve short sells based on various inventories. Both are built as micro services, with various robots talking to each other, optimized at the sub millisecond response time. It works. But the difference is one has a release/repository organization based on each individual service, the other is deployed as a monolith with all robots all redeployed. The system with split releases is barely maintanable, bugs appear in one version of a shared dependencies and we cant upgrade all robots without a mind blowingly complex procedure, regression tests etc. It s sometimes impossible and bugs are worked around up or downstream. The monolithically deployed system is a breeze, we can fix an issue in a dependency and all robots benefit the next week. There's no difference technically except in the minds and cultures of the team that in one system it s too hard to deploy everything and in the other it s mass redeployed every week.
alexjplant 5y ago
> all communicating with a single database on the back end Those aren't exactly what I'd call a microservice then... that's a monolith with tons of type-unsafe code and unnecessary infrastructure glue.
- JimDabell 5y ago
  This anti-pattern is called a “distributed monolith”: https://www.gremlin.com/blog/is-your-microservice-a-distributed-monolith/ https://www.gremlin.com/blog/is-your-microservice-a-distribu...

xwolfi 5y ago

One thing I ve been painfully working on is upgrades as well. We have, in our bank, 2 system, one to trade with exchange automatically, one to approve short sells based on various inventories. Both are built as micro services, with various robots talking to each other, optimized at the sub millisecond response time. It works. But the difference is one has a release/repository organization based on each individual service, the other is deployed as a monolith with all robots all redeployed. The system with split releases is barely maintanable, bugs appear in one version of a shared dependencies and we cant upgrade all robots without a mind blowingly complex procedure, regression tests etc. It s sometimes impossible and bugs are worked around up or downstream. The monolithically deployed system is a breeze, we can fix an issue in a dependency and all robots benefit the next week. There's no difference technically except in the minds and cultures of the team that in one system it s too hard to deploy everything and in the other it s mass redeployed every week.

alexjplant 5y ago

> all communicating with a single database on the back end Those aren't exactly what I'd call a microservice then... that's a monolith with tons of type-unsafe code and unnecessary infrastructure glue.

JimDabell 5y ago
This anti-pattern is called a “distributed monolith”: https://www.gremlin.com/blog/is-your-microservice-a-distributed-monolith/ https://www.gremlin.com/blog/is-your-microservice-a-distribu...