4 ms·

Unfortunately that message was way way behind the bombast of "microservices everywhere now" that preceded it for years, to the detriment of many small orgs. I'

Unfortunately that message was way way behind the bombast of "microservices everywhere now" that preceded it for years, to the detriment of many small orgs. I've seen engineering orgs of 10-50 launch headlong into microservices to poor results. No exaggeration to say many places ended up with more repos & services than developers to manage them.

butvacuum 9mo ago
do they all manage to have 4 different ways to do something like "notify user about x", all In use because they could never be bothered to complete the "upgrade"?
- steveBK123 9mo ago
  Exactly the problem yes. Once you have more services than developers, you are probably running into infrequent releases and orphaned projects. So whenever an inevitable common utility improvement is made, the effort of pushing out 100 repo releases for services no one has touch since Jim left 3 years ago is terrifying. When there is a breaking change is going to be made and you HAVE to do the 100 releases, it's terrifying. Everyone says it never happens, but work on a project/team for 5 years and it does eventually, even once is enough to swear me off this "architecture".
- Nextgrid 9mo ago
  That's often the case yes. In a monolith a developer disgruntled about the situation can clean up the mess in a weekend, test it and push it through. No chance of that happening in microservices - you'd run out of weekend just opening PRs in the dozens of repos and dealing with all the nitpicking and turf wars.
  - butvacuum 9mo ago
    I've had the unfortunate experence to run into a situation where two dev's who hated eachother ended up building two systems with one passing the customer's API calls' http content directly to the front end... It was supposed to be back end and front end.
swiftcoder 9mo ago
I once worked with a startup that had 3 total engineers, and their architecture diagram called for 8 micro services. We tore that architecture diagram up pronto
- Nextgrid 9mo ago
  Out of interest how do you get the authority to make those decisions and have the existing developers continue working productively after this? To me it seems like microservices (or cloud, or whatever) is often overused for career/buzzword reasons. The engineers pushing for it aren't asking for your advice, they want to build an engineering playground - denying them the opportunity is unlikely to suddenly make them productive at driving the business forward with a simple stack when their original idea was to play with shiny tech instead. The only way I see out of this is to have management buy-in to get the microservices and their developers out the door, replaced by more competent people.
  - steveBK123 9mo ago
    > their original idea was to play with shiny tech instead This is a behavior I would say is very hard to manage out of people and should be screened for aggressively in interviews.
    - Nextgrid 9mo ago
      This behavior is self-inflicted by a decade of low pay and lack of significant raises to reward seniority. The most effective way to increase income for a developer is to join a place, rack up as many buzzwords as possible and leave after 2-3 years, using those buzzwords to secure a higher-paying role somewhere else. Rinse and repeat until you get a management position where you can use politics to increase your income instead. If you want guys that use boring tech to drive the business forward you have to pay them upfront the money they’d otherwise make playing the above game. It still makes sense (an engineering playground is anything but cheap) but good luck getting an employer to pay anything above “market rate”.
Scubabear68 9mo ago
The worst I ever saw was an engineer misunderstood microservices, and made a service per endpoint. He started complaining to management that 50 CI/CD setups was his limit he could support. He was absolutely amazed when I showed him he could combine endpoints into a larger logical service. 50 services became three, and it’s still three a few years later now.
- steveBK123 9mo ago
  Nanoservices

butvacuum 9mo ago

do they all manage to have 4 different ways to do something like "notify user about x", all In use because they could never be bothered to complete the "upgrade"?

steveBK123 9mo ago
Exactly the problem yes. Once you have more services than developers, you are probably running into infrequent releases and orphaned projects. So whenever an inevitable common utility improvement is made, the effort of pushing out 100 repo releases for services no one has touch since Jim left 3 years ago is terrifying. When there is a breaking change is going to be made and you HAVE to do the 100 releases, it's terrifying. Everyone says it never happens, but work on a project/team for 5 years and it does eventually, even once is enough to swear me off this "architecture".
Nextgrid 9mo ago
That's often the case yes. In a monolith a developer disgruntled about the situation can clean up the mess in a weekend, test it and push it through. No chance of that happening in microservices - you'd run out of weekend just opening PRs in the dozens of repos and dealing with all the nitpicking and turf wars.
- butvacuum 9mo ago
  I've had the unfortunate experence to run into a situation where two dev's who hated eachother ended up building two systems with one passing the customer's API calls' http content directly to the front end... It was supposed to be back end and front end.

swiftcoder 9mo ago

I once worked with a startup that had 3 total engineers, and their architecture diagram called for 8 micro services. We tore that architecture diagram up pronto

Nextgrid 9mo ago
Out of interest how do you get the authority to make those decisions and have the existing developers continue working productively after this? To me it seems like microservices (or cloud, or whatever) is often overused for career/buzzword reasons. The engineers pushing for it aren't asking for your advice, they want to build an engineering playground - denying them the opportunity is unlikely to suddenly make them productive at driving the business forward with a simple stack when their original idea was to play with shiny tech instead. The only way I see out of this is to have management buy-in to get the microservices and their developers out the door, replaced by more competent people.
- steveBK123 9mo ago
  > their original idea was to play with shiny tech instead This is a behavior I would say is very hard to manage out of people and should be screened for aggressively in interviews.
  - Nextgrid 9mo ago
    This behavior is self-inflicted by a decade of low pay and lack of significant raises to reward seniority. The most effective way to increase income for a developer is to join a place, rack up as many buzzwords as possible and leave after 2-3 years, using those buzzwords to secure a higher-paying role somewhere else. Rinse and repeat until you get a management position where you can use politics to increase your income instead. If you want guys that use boring tech to drive the business forward you have to pay them upfront the money they’d otherwise make playing the above game. It still makes sense (an engineering playground is anything but cheap) but good luck getting an employer to pay anything above “market rate”.

Scubabear68 9mo ago

The worst I ever saw was an engineer misunderstood microservices, and made a service per endpoint. He started complaining to management that 50 CI/CD setups was his limit he could support. He was absolutely amazed when I showed him he could combine endpoints into a larger logical service. 50 services became three, and it’s still three a few years later now.

steveBK123 9mo ago
Nanoservices