5 ms·

I think most criticisms around microservices are about good practices and skills beating microservices in theory. And the virtue of microservices is that they

I think most criticisms around microservices are about good practices and skills beating microservices in theory. And the virtue of microservices is that they create hard boundaries no matter your skill and seniority level. Any unsupervised junior will probably dissolve the module boundaries. But they can't simply dissolve the hard boundary of having a service in another location.

BackBlast 4y ago
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.
marcosdumay 4y ago
> But they can't simply dissolve the hard boundary of having a service in another location. I've seen people doing that a few times already. They start changing due to some uninformed kind of "convenience", and then you look at the services API and it makes no sense at all.
- jeltz 4y ago
  Yeah, I feel that happens all the time.
esailija 4y ago
Huh? They can, and will, just add the things they want to the rest api of the microservice A and then call them from B. That doesn't change with microservices. Look up a thing called "distributed monolith".
- jacobr1 4y ago
  That is harder when each service and team has their own repo and review process. Doesn't mean they won't just get merged, but there is increased friction and less-trust about random PRs from engineers that aren't actively working on the same team, so those PRs might get more scrutiny.
  - esailija 4y ago
    Then why cannot you have separate repos and review processes for modules? This has nothing to do with microservices vs modules.
    - jacobr1 4y ago
      Agreed - ther is no reason for that not to be the case. It just is that in practice (and not as some essentialism of how organizations needs to structure things) that miroservices tend proliferate git-repos and modules tend to be part of monorepos. But, sure, there is no need for that to be the case. So given a world like that, the repo seperation is what enforces the friction for junior devs to submit changes across repos. With monorepos it is easier.
pjmlp 4y ago
If the modules are distributed in binary form, for the languages that support them, the junior will have no way around it unless they feel like learning about hacking binaries.
papito 4y ago
I have never seen a "hard boundary" in a small to medium sized company. Everyone still ends up communicating, and there are simply not enough resources to maintain truly separate services. The rigor of maintaining resilient, backward-compatible, versioned internal APIs is too resource and time consuming to do well. All I see is hack and slash, and tons of technical debt. It seems like in the last couple of years it started sinking in, that distributed systems are hard.
mattmanser 4y ago
I always love that circular logic. "Hey our developers can't make modules correctly! Let's make the API boundaries using HTTP calls instead, then they'll suddenly know what to do!" And that unsupervised junior? At one place I joined, that unsupervised junior just started passing data he "needed" via query string params in ginormous arrays from microservice to microservice. And it wasn't a quick fix because instead of using the lovely type system that TELLS you where the stupid method has been used, you've got to go hunting for http calls scattered over multiple projects. All you've done is make everything even more complicated, if you can't supervise your juniors, your code's going to go sideways whatever. Microservices don't solve that at all and it's pure circular logic to claim otherwise. If your team can't make good classes, they can't make good APIs either. And worse still, suddenly everything's locked in because changing APIs is much harder than changing classes.

BackBlast 4y ago

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.

marcosdumay 4y ago

> But they can't simply dissolve the hard boundary of having a service in another location. I've seen people doing that a few times already. They start changing due to some uninformed kind of "convenience", and then you look at the services API and it makes no sense at all.

jeltz 4y ago
Yeah, I feel that happens all the time.

esailija 4y ago

Huh? They can, and will, just add the things they want to the rest api of the microservice A and then call them from B. That doesn't change with microservices. Look up a thing called "distributed monolith".

jacobr1 4y ago
That is harder when each service and team has their own repo and review process. Doesn't mean they won't just get merged, but there is increased friction and less-trust about random PRs from engineers that aren't actively working on the same team, so those PRs might get more scrutiny.
- esailija 4y ago
  Then why cannot you have separate repos and review processes for modules? This has nothing to do with microservices vs modules.
  - jacobr1 4y ago
    Agreed - ther is no reason for that not to be the case. It just is that in practice (and not as some essentialism of how organizations needs to structure things) that miroservices tend proliferate git-repos and modules tend to be part of monorepos. But, sure, there is no need for that to be the case. So given a world like that, the repo seperation is what enforces the friction for junior devs to submit changes across repos. With monorepos it is easier.

pjmlp 4y ago

If the modules are distributed in binary form, for the languages that support them, the junior will have no way around it unless they feel like learning about hacking binaries.

papito 4y ago

I have never seen a "hard boundary" in a small to medium sized company. Everyone still ends up communicating, and there are simply not enough resources to maintain truly separate services. The rigor of maintaining resilient, backward-compatible, versioned internal APIs is too resource and time consuming to do well. All I see is hack and slash, and tons of technical debt. It seems like in the last couple of years it started sinking in, that distributed systems are hard.

mattmanser 4y ago

I always love that circular logic. "Hey our developers can't make modules correctly! Let's make the API boundaries using HTTP calls instead, then they'll suddenly know what to do!" And that unsupervised junior? At one place I joined, that unsupervised junior just started passing data he "needed" via query string params in ginormous arrays from microservice to microservice. And it wasn't a quick fix because instead of using the lovely type system that TELLS you where the stupid method has been used, you've got to go hunting for http calls scattered over multiple projects. All you've done is make everything even more complicated, if you can't supervise your juniors, your code's going to go sideways whatever. Microservices don't solve that at all and it's pure circular logic to claim otherwise. If your team can't make good classes, they can't make good APIs either. And worse still, suddenly everything's locked in because changing APIs is much harder than changing classes.