5 ms·

Those boundaries also increase the cost of development. If you are institutionally incapable of enforcing coding standards such that you can't prevent juniors

Those boundaries also increase the cost of development. If you are institutionally incapable of enforcing coding standards such that you can't prevent juniors from coupling your modules, perhaps it's worth it. But there are more efficient ways to build and run an engineering organization. The best place for such boundaries is at the team/division/org level, not team-internal or single dev-internal like microservices implies with its name. Embrace Conway's law in your architecture, and don't subdivide within a service.

guywhocodes 4y ago
Are organizations ever capable of enforcing coding standards even remotely close to that of what microservices _should_ provide? Because I have not seen it. However this is muddied by the fact that I almost never see microservices, I see a lot of distributed monoliths tho.
- BackBlast 4y ago
  I guess the birth of the term distributed monolith gives lie to the idea that the service boundaries can't be breached by devs. :)
- BackBlast 4y ago
  For an org capable of adhering to standards. I've seen success in small teams. I've never seen it in a large org through, it's always a dumpster fire. Especially anything that grows really fast, culture is out the window to randomness, and it's a hodgepodge of understanding and methods that are all over the map.
dalbasal 4y ago
"If you are institutionally incapable of..." This is the road to bullshit. Of course no manager or CEO will admit that their team/company is that. Admitting technical non-excellence is nearly impossible. Organisation inadequacy... impossible. So the best course of action is to pretend your organisational methods are really just software architecture... and back to square one.
- BackBlast 4y ago
  If you can't admit the problem. Can't stare it down. Can't comprehend it. Then I don't know how you can ever solve it. I try to avoid these places, not easy though.
  - jacobr1 4y ago
    Are there any examples of large organizations that don't have this problem? I can imagine places with small teams that are basically isolated that can operate efficiently, but once you scale to point where dozens to hundreds of teams needing to cooperate, it seems like all you have is tradeoffs and fundamental coordination and scaling issues. I've never heard of a big org that didn't have some flavor of disfunction resulting from that kind of complexity. Some places seem to be "less-bad" but that doesn't mean good or efficient.
    - locutous 4y ago
      Jim Keller mentioned this problem in the hardware space. Basically when people breach the interface design and couple things and how that coupling limits your ability to grow the design. When he helped set the tone for the Zen architecture he took AMDs existing people, set them on a more aggressive path and one of the cardinal tenants was you could not cheat on the interfaces. This is one of the nuggets you can pull from his interviews. It's possible. It happens. And the end results can be industry changing.
- guywhocodes 4y ago
  This is something I'm painfully familiar with and I'm starting to seem to me that "definition creep" that I thought was the result of marketing. Such as we see with terms like "AI" and "ML", actually mostly comes from this. If you are a dumpster-fire S&P500 company CTO and there is a new shiny thing that would actually improve things, you are probably more capable of redefining that new term into the horse-shit you are currently doing; than actually do it.
JamesBarney 4y ago
Any way you slice it, it's hard to manage/align/coordinate a 100 devs. If done right microservices is a way to transform part of your organization challenge into a technical one, which for many organizations is the right move. The biggest issue is if you aren't large enough to have challenging organizational issues it's much easier to just solve the very solvable organizational issues than implement and use microservices.
- locutous 4y ago
  > If done right microservices is a way to transform part of your organization challenge into a technical one, which for many organizations is the right move. Famous last words, if done right... Or you just multiply your organizational issue with a technical one.
  - JamesBarney 4y ago
    Sure poorly implemented solutions rarely solve problems well. But implementing microservices is not an unsolvable problem. It's a problem that 1000s of organizations have solved.
    - locutous 4y ago
      I haven't seen one that has done it well personally. Missing in this is so much of how it might be done right. There are so many dragons. Vendor lock in, logging, debugging, development (can I run the application on my laptop?), versioning. How far will out of the box tooling get me vs what I have to build. Etc etc etc. When the "new shiny" effect wears off you usually find a turd that smells worse than what came before. Which is why we see this thread ever month or two and will until the tooling catches up and companies stop creating the distributed turds or the method falls out of grace because people finally realize you can scale simple systems pretty far vertically.

guywhocodes 4y ago

Are organizations ever capable of enforcing coding standards even remotely close to that of what microservices _should_ provide? Because I have not seen it. However this is muddied by the fact that I almost never see microservices, I see a lot of distributed monoliths tho.

BackBlast 4y ago
I guess the birth of the term distributed monolith gives lie to the idea that the service boundaries can't be breached by devs. :)
BackBlast 4y ago
For an org capable of adhering to standards. I've seen success in small teams. I've never seen it in a large org through, it's always a dumpster fire. Especially anything that grows really fast, culture is out the window to randomness, and it's a hodgepodge of understanding and methods that are all over the map.

dalbasal 4y ago

"If you are institutionally incapable of..." This is the road to bullshit. Of course no manager or CEO will admit that their team/company is that. Admitting technical non-excellence is nearly impossible. Organisation inadequacy... impossible. So the best course of action is to pretend your organisational methods are really just software architecture... and back to square one.

BackBlast 4y ago
If you can't admit the problem. Can't stare it down. Can't comprehend it. Then I don't know how you can ever solve it. I try to avoid these places, not easy though.
- jacobr1 4y ago
  Are there any examples of large organizations that don't have this problem? I can imagine places with small teams that are basically isolated that can operate efficiently, but once you scale to point where dozens to hundreds of teams needing to cooperate, it seems like all you have is tradeoffs and fundamental coordination and scaling issues. I've never heard of a big org that didn't have some flavor of disfunction resulting from that kind of complexity. Some places seem to be "less-bad" but that doesn't mean good or efficient.
  - locutous 4y ago
    Jim Keller mentioned this problem in the hardware space. Basically when people breach the interface design and couple things and how that coupling limits your ability to grow the design. When he helped set the tone for the Zen architecture he took AMDs existing people, set them on a more aggressive path and one of the cardinal tenants was you could not cheat on the interfaces. This is one of the nuggets you can pull from his interviews. It's possible. It happens. And the end results can be industry changing.
guywhocodes 4y ago
This is something I'm painfully familiar with and I'm starting to seem to me that "definition creep" that I thought was the result of marketing. Such as we see with terms like "AI" and "ML", actually mostly comes from this. If you are a dumpster-fire S&P500 company CTO and there is a new shiny thing that would actually improve things, you are probably more capable of redefining that new term into the horse-shit you are currently doing; than actually do it.

JamesBarney 4y ago

Any way you slice it, it's hard to manage/align/coordinate a 100 devs. If done right microservices is a way to transform part of your organization challenge into a technical one, which for many organizations is the right move. The biggest issue is if you aren't large enough to have challenging organizational issues it's much easier to just solve the very solvable organizational issues than implement and use microservices.

locutous 4y ago
> If done right microservices is a way to transform part of your organization challenge into a technical one, which for many organizations is the right move. Famous last words, if done right... Or you just multiply your organizational issue with a technical one.
- JamesBarney 4y ago
  Sure poorly implemented solutions rarely solve problems well. But implementing microservices is not an unsolvable problem. It's a problem that 1000s of organizations have solved.
  - locutous 4y ago
    I haven't seen one that has done it well personally. Missing in this is so much of how it might be done right. There are so many dragons. Vendor lock in, logging, debugging, development (can I run the application on my laptop?), versioning. How far will out of the box tooling get me vs what I have to build. Etc etc etc. When the "new shiny" effect wears off you usually find a turd that smells worse than what came before. Which is why we see this thread ever month or two and will until the tooling catches up and companies stop creating the distributed turds or the method falls out of grace because people finally realize you can scale simple systems pretty far vertically.