8 ms·

CQRS and microservices has so much overhead, I'm amazed at how many companies adopt microservices without having anyone know a single thing about distributed sy

CQRS and microservices has so much overhead, I'm amazed at how many companies adopt microservices without having anyone know a single thing about distributed systems. I think people underestimate the glue required to make microservices be useful. I had a similar situation at my last company where they spent a year and a half converting their monolith into half ass microservices and it still wasn't working properly. They also stopped releasing new features on their product during this entire conversion which obviously lead to a drop in customers. The mass exodus of employees at the end was something beautiful though.

Lapsa 7y ago
I would argue that main reason for adaptation of microservices is to actually prolong development time (moar dollars) and make devops as convoluted as possible to safeguard data. Or foolishness.
- allover 7y ago
  You're assuming malice over incompetence. Having heard mainly "nothing but guff" justifications for microservices in non-enormous orgs, I think (as usual, and some law I forget dictates) the latter is more likely.
  - mandelbrotwurst 7y ago
    You're thinking of Hanlon's razor.
- marktolson 7y ago
  I don't understand the hate for microservices on hn. I have found microservices are a great way to extend monoliths developed with legacy frameworks. There are so many pros with the cons easily avoidable with the right tooling / processes.
  - JamesBarney 7y ago
    Basically it comes down to Distributed logging:hard Distributed debugging: hard Distributed versioning: hard Distributed transactions: very hard And on 95% of projects these problems aren't worth solving for the benefits of microservices.
    - bogdanu 7y ago
      > And on 95% of projects these problems aren't worth solving for the benefits of microservices. And especially with a team of 4 or 5 developers.
      - deleted 7y ago
        [deleted]
      - capableweb 7y ago
        I just started working on a new project about half a year ago, completely greenfield. The backend developer (there is only one...) jumped into microservices directly, deploying on AWS Fargate, trying to split out as many things into containers as possible, because that's the "proper" way of doing it. We still have few users as the project is new, but hey, at least we could scale to 100000s users in a few minutes, instead of having easier logging, debugging and versioning A lot of stuff in software engineering is just driven by what's popular, not what's needed.
        bcrosby95 7y ago
        A monolith can handle millions of daily unique users. The database is the hard part. In the web world, if you have less than 10s of millions of daily users, as long as you design an application that holds no state itself, the architecture is usually more important for scaling your team and the size of your codebase rather than the number of users you can handle.
        redis_mlc 7y ago
        With microservices, you lose the ability to use database transactions across services/tables. Later on, when people realize this, it's too late. It's priceless to see their expressions when senior mgmt. and business owners finally find out.
0x8BADF00D 7y ago
They are adopting microservices for the wrong reasons. It's easy for them to scale up, they don't need to scale out.
nikanj 7y ago
They're perfect for a startup with lots of funding and little traction. So much busywork to keep the team churning!
pc86 7y ago
Is anyone surprised that a "half assed" implementation of anything doesn't work properly, though?
Volrath89 7y ago
Why do people always associate cqrs with microservices? I have a project where only 3 developers work; we re designed it to be cqrs. I was sceptical at first - I especially don't like some of the boilerplate it creates - but I'm now sold on it by combining it with the mediator pattern, now I can have validation, logging and performance checks on every command and query without repeating code, works like a middleware And ofc being only 3 devs it would be nuts to have microservices so we are happy with a cqrs monolith

Lapsa 7y ago

I would argue that main reason for adaptation of microservices is to actually prolong development time (moar dollars) and make devops as convoluted as possible to safeguard data. Or foolishness.

allover 7y ago
You're assuming malice over incompetence. Having heard mainly "nothing but guff" justifications for microservices in non-enormous orgs, I think (as usual, and some law I forget dictates) the latter is more likely.
- mandelbrotwurst 7y ago
  You're thinking of Hanlon's razor.
marktolson 7y ago
I don't understand the hate for microservices on hn. I have found microservices are a great way to extend monoliths developed with legacy frameworks. There are so many pros with the cons easily avoidable with the right tooling / processes.
- JamesBarney 7y ago
  Basically it comes down to Distributed logging:hard Distributed debugging: hard Distributed versioning: hard Distributed transactions: very hard And on 95% of projects these problems aren't worth solving for the benefits of microservices.
  - bogdanu 7y ago
    > And on 95% of projects these problems aren't worth solving for the benefits of microservices. And especially with a team of 4 or 5 developers.
    - deleted 7y ago
      [deleted]
    - capableweb 7y ago
      I just started working on a new project about half a year ago, completely greenfield. The backend developer (there is only one...) jumped into microservices directly, deploying on AWS Fargate, trying to split out as many things into containers as possible, because that's the "proper" way of doing it. We still have few users as the project is new, but hey, at least we could scale to 100000s users in a few minutes, instead of having easier logging, debugging and versioning A lot of stuff in software engineering is just driven by what's popular, not what's needed.
      - bcrosby95 7y ago
        A monolith can handle millions of daily unique users. The database is the hard part. In the web world, if you have less than 10s of millions of daily users, as long as you design an application that holds no state itself, the architecture is usually more important for scaling your team and the size of your codebase rather than the number of users you can handle.
        redis_mlc 7y ago
        With microservices, you lose the ability to use database transactions across services/tables. Later on, when people realize this, it's too late. It's priceless to see their expressions when senior mgmt. and business owners finally find out.

0x8BADF00D 7y ago

They are adopting microservices for the wrong reasons. It's easy for them to scale up, they don't need to scale out.

nikanj 7y ago

They're perfect for a startup with lots of funding and little traction. So much busywork to keep the team churning!

pc86 7y ago

Is anyone surprised that a "half assed" implementation of anything doesn't work properly, though?

Volrath89 7y ago

Why do people always associate cqrs with microservices? I have a project where only 3 developers work; we re designed it to be cqrs. I was sceptical at first - I especially don't like some of the boilerplate it creates - but I'm now sold on it by combining it with the mediator pattern, now I can have validation, logging and performance checks on every command and query without repeating code, works like a middleware And ofc being only 3 devs it would be nuts to have microservices so we are happy with a cqrs monolith