4 ms·

> (2013) (Thoughtworks) Microservices has certainly proved to be a lucrative trend for consultancies like thoughtworks. I've seen countless projects where a c

> (2013) (Thoughtworks) Microservices has certainly proved to be a lucrative trend for consultancies like thoughtworks. I've seen countless projects where a consultancy has been brought in replace some existing monolithic application with microservices. It sure creates a lot of billable work, but I can't say that I've seen much value in the business outcomes.

taberiand 5y ago
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...
vmurthy 5y ago
Distributed monolith[0], much? :) https://newrelic.com/blog/best-practices/distributed-monolith-vs-microservices https://newrelic.com/blog/best-practices/distributed-monolit...
c_o_n_v_e_x 5y ago
Funny you say that... I'm a PM and inherited a software product that was initially started by a Thoughtworks team. The software was based on microservices from day 1. The company c suite was sold into an MS architecture and gushed about how good it was. So much unnecessary complexity for an early product. What a nightmare.

taberiand 5y ago

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

vmurthy 5y ago

Distributed monolith[0], much? :) https://newrelic.com/blog/best-practices/distributed-monolith-vs-microservices https://newrelic.com/blog/best-practices/distributed-monolit...

c_o_n_v_e_x 5y ago

Funny you say that... I'm a PM and inherited a software product that was initially started by a Thoughtworks team. The software was based on microservices from day 1. The company c suite was sold into an MS architecture and gushed about how good it was. So much unnecessary complexity for an early product. What a nightmare.