13 ms·

The reverse of this also happens: new team manager joins a team of 4-5 dev and goes "eww... a monolith, we'll write an MVP in 3 weeks with microservices, CQRS a

The reverse of this also happens: new team manager joins a team of 4-5 dev and goes "eww... a monolith, we'll write an MVP in 3 weeks with microservices, CQRS and all". Long story short, one year and a half passes and the mvp is still not finished, the architect leaves the company and some poor guys (from an outsourcing company) are still going at it with the same architecture.

cameronfraser 7y ago
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.
- 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
commandlinefan 7y ago
On the other other hand, I’ve worked on system that stuck with “the old way” (like ColdFusion) for so long that it was impossible to even find documentation on the old programming environment if you could find somebody willing to maintain it. The longer you wait to upgrade, the more it’s going to hurt when you finally do.
- bogdanu 7y ago
  I'm not against replacing old systems, but this has to happen in incremental steps. This way, if an implementation path doesn't worth the effort, just drop it and don't spend dozens of months with a full rewrite and realizing that you are spending a week to implement a CRUD for a simple entity. It's even worse when devs are new to the project and have no knowledge of the domain; I've been burned by this, never again. At the end of the day, we are not in the research field, we are payed to fix business problems, to deliver something that brings a business value. Yeah, it's nice to write some really complex software that would make the system a lot more optimized, but we have to deliver it before our bosses are getting tired of excuses and pull the plug. Learned that the hard way.
- Supermancho 7y ago
  Having been in this situation, as well, I find that the aging out of technology MUST be led by a CTO who is competent enough to know that tipping point of cost-benefit. Their job immediately becomes a political choice (pass the pain to the next guy) when the point has passed and it gets worse every new CTO. Some of these systems are HUGE (hudreds of millions of lines of ColdFusion, where I worked).
  - burpsnard 7y ago
    in a way it's quite a testament to it's utility. Allaire were there with a workable solution, before jsp, php, (?) asp. Iirc only perl was serious competition. I still sometimes see lotus notes '.nsf' links
- pitay 7y ago
  The reason I have been left without product document is because Oracle bought the software the organisation was using. Cannot stress enough the value of keeping an offline copy of the documentation of a product rather than relying on a companies website or similar. Edit: Also want to add software installation files are very important to keep offline as well.
majormajor 7y ago
That's a very "junior senior" type of developer. Rewrite from scratch needs external reasons to be a good idea, because you have a huge uncertainty risk of "i don't know enough about this system to rewrite it, and now i'm spending months hacking back in edge cases to the new no-longer-beautiful-design." Uncertainty risk doesn't mean never do it, but it means make sure you understand it and make sure it's gonna be worth it.
- mark-r 7y ago
  Chesterton's fence: https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
burpsnard 7y ago
> some poor guys.. still going at it that's how you earn your thousand yard stare
- bogdanu 7y ago
  I have that stare from the first few months of my career. The perks of working in outsourcing I guess.
  - ido 7y ago
    I've never worked in outsourcing and almost every job I had in my >15 years career as a developer included at least somewhat-gnarly & often truly-gnarly code. It is very rare to see a codebase several years old that can be fairly describe as "in good shape".
jSully24 7y ago
Never hire anyone who’s top priority is not to first understand the whys of the current situation and understands how to move forward from there. If they have “the answer” but don’t understand the “why we are here today” their decisions should be, at the very least, suspect.
- Aeolun 7y ago
  On the other hand, don’t hire who wants to understand everything first either. Sometimes a bad choice was just a bad choice, and it’s a waste of time to figure out if it was taken for a reason.

cameronfraser 7y ago

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

commandlinefan 7y ago

On the other other hand, I’ve worked on system that stuck with “the old way” (like ColdFusion) for so long that it was impossible to even find documentation on the old programming environment if you could find somebody willing to maintain it. The longer you wait to upgrade, the more it’s going to hurt when you finally do.

bogdanu 7y ago
I'm not against replacing old systems, but this has to happen in incremental steps. This way, if an implementation path doesn't worth the effort, just drop it and don't spend dozens of months with a full rewrite and realizing that you are spending a week to implement a CRUD for a simple entity. It's even worse when devs are new to the project and have no knowledge of the domain; I've been burned by this, never again. At the end of the day, we are not in the research field, we are payed to fix business problems, to deliver something that brings a business value. Yeah, it's nice to write some really complex software that would make the system a lot more optimized, but we have to deliver it before our bosses are getting tired of excuses and pull the plug. Learned that the hard way.
Supermancho 7y ago
Having been in this situation, as well, I find that the aging out of technology MUST be led by a CTO who is competent enough to know that tipping point of cost-benefit. Their job immediately becomes a political choice (pass the pain to the next guy) when the point has passed and it gets worse every new CTO. Some of these systems are HUGE (hudreds of millions of lines of ColdFusion, where I worked).
- burpsnard 7y ago
  in a way it's quite a testament to it's utility. Allaire were there with a workable solution, before jsp, php, (?) asp. Iirc only perl was serious competition. I still sometimes see lotus notes '.nsf' links
pitay 7y ago
The reason I have been left without product document is because Oracle bought the software the organisation was using. Cannot stress enough the value of keeping an offline copy of the documentation of a product rather than relying on a companies website or similar. Edit: Also want to add software installation files are very important to keep offline as well.

majormajor 7y ago

That's a very "junior senior" type of developer. Rewrite from scratch needs external reasons to be a good idea, because you have a huge uncertainty risk of "i don't know enough about this system to rewrite it, and now i'm spending months hacking back in edge cases to the new no-longer-beautiful-design." Uncertainty risk doesn't mean never do it, but it means make sure you understand it and make sure it's gonna be worth it.

mark-r 7y ago
Chesterton's fence: https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...

burpsnard 7y ago

> some poor guys.. still going at it that's how you earn your thousand yard stare

bogdanu 7y ago
I have that stare from the first few months of my career. The perks of working in outsourcing I guess.
- ido 7y ago
  I've never worked in outsourcing and almost every job I had in my >15 years career as a developer included at least somewhat-gnarly & often truly-gnarly code. It is very rare to see a codebase several years old that can be fairly describe as "in good shape".

jSully24 7y ago

Never hire anyone who’s top priority is not to first understand the whys of the current situation and understands how to move forward from there. If they have “the answer” but don’t understand the “why we are here today” their decisions should be, at the very least, suspect.

Aeolun 7y ago
On the other hand, don’t hire who wants to understand everything first either. Sometimes a bad choice was just a bad choice, and it’s a waste of time to figure out if it was taken for a reason.