I find the hackernews obsession with bashing micro services tiresome. We get it, your organization didn’t need the scale/had a relatively simple problem/couldn’t solve bad code by doing microservices.
Sometimes it’s the wrong call. Sometimes it’s the right one. It’s not a panacea, obviously. Can’t we just use our expertise and judgement to determine the correct architecture? There are always trade-offs. Our job is to rigorously evaluate them and make a good decision, not blindly follow or dismiss any particular implementation.
Tired of being bashed in the office when devs out of college want to rewrite everything because it’s not microservices. Microservices are web scale they say.
Management not knowing any better pour resources into microservices because it’s so hot. Devs who want promotions go over engineer new systems.
Devs who resist are made to maintain the entire monolith themselves, or find another job because they are not team players.
Eventually there ends up two massive piles of code and all the old and ‘new’ devs have left by then. Not sure what happens after that, I never stayed to find out.
I'm willing to bet that if the everything were clear and easy to modify, they'd prefer not rewriting everything. If it "just worked," they could focus on adding customer-pleasing, revenue-increasing functionality, a far more reliable path to promotion.
First everyone knows monoliths are bad. Next understanding existing code is hard work, writing your own new code is perfectly understandable and fun, because you’re the one who wrote it, and you write perfect code! It’s so good you don’t even need to comment it!
The default thought process is 1. I don’t understand this code and business domain, 2. It is too complex, 3. We should rewrite it as microservices 4. You’ve replace 2% of the system with your microservice, 5. New devs quit because your own service is now too much hassle to maintain, 6. Old devs quit because you wasted enough of their time 7. The org now has n+1 layers of tech debt, ready for the cycle to repeat.
When I left n=5. 4 had a good run and we really tried to keep it going. Can’t fight the HN zerg sometimes.
Why wouldn’t management know better? Where I work all management is engineers. And everyone universally agrees including experienced devs we need to finish busting up the monolith. No one wants to work on it or deal with it everyone wants to work on the new services.
That’s pretty frustrating, for sure. But I don’t think it’s reasonable to call a hammer worthless just because there are people who think swapping all screwdrivers for hammers is a good idea.
Comments
I find the hackernews obsession with bashing micro services tiresome. We get it, your organization didn’t need the scale/had a relatively simple problem/couldn’t solve bad code by doing microservices.
Sometimes it’s the wrong call. Sometimes it’s the right one. It’s not a panacea, obviously. Can’t we just use our expertise and judgement to determine the correct architecture? There are always trade-offs. Our job is to rigorously evaluate them and make a good decision, not blindly follow or dismiss any particular implementation.
Tired of being bashed in the office when devs out of college want to rewrite everything because it’s not microservices. Microservices are web scale they say.
Management not knowing any better pour resources into microservices because it’s so hot. Devs who want promotions go over engineer new systems.
Devs who resist are made to maintain the entire monolith themselves, or find another job because they are not team players.
Eventually there ends up two massive piles of code and all the old and ‘new’ devs have left by then. Not sure what happens after that, I never stayed to find out.
Why do they really want to rewrite everything?
I'm willing to bet that if the everything were clear and easy to modify, they'd prefer not rewriting everything. If it "just worked," they could focus on adding customer-pleasing, revenue-increasing functionality, a far more reliable path to promotion.
First everyone knows monoliths are bad. Next understanding existing code is hard work, writing your own new code is perfectly understandable and fun, because you’re the one who wrote it, and you write perfect code! It’s so good you don’t even need to comment it!
The default thought process is 1. I don’t understand this code and business domain, 2. It is too complex, 3. We should rewrite it as microservices 4. You’ve replace 2% of the system with your microservice, 5. New devs quit because your own service is now too much hassle to maintain, 6. Old devs quit because you wasted enough of their time 7. The org now has n+1 layers of tech debt, ready for the cycle to repeat.
When I left n=5. 4 had a good run and we really tried to keep it going. Can’t fight the HN zerg sometimes.
Why wouldn’t management know better? Where I work all management is engineers. And everyone universally agrees including experienced devs we need to finish busting up the monolith. No one wants to work on it or deal with it everyone wants to work on the new services.
Management doesn't want to go against the latest fad which is like you say, 'busting up the monolith' and 'everyone wants to work on new services'
That’s pretty frustrating, for sure. But I don’t think it’s reasonable to call a hammer worthless just because there are people who think swapping all screwdrivers for hammers is a good idea.