5 ms·

The point of microservices is not technical, it's so that the deployment- and repository ownership structure matches your organization structure, and that clear

The point of microservices is not technical, it's so that the deployment- and repository ownership structure matches your organization structure, and that clear lines are drawn between responsibilities.

sim7c00 2y ago
its also easier to find devs that have the skills to create and maintain thin services than a large complicated monolith, despite the difficulties found when having to debug a constellation of microservices during a crisis.
- phil21 2y ago
  For the folks who downvoted this - why? I hire developers and this is the absolute truth of the matter. You can get away with hiring devs able to only debug their little micro empire so long as you can retain some super senior rockstar level folks able to see the big picture when it inevitably breaks down in production under load. These skills are becoming rarer by the day, when they used to be nearly table stakes for a “senior” dev. Microservices have their place, but many times you can see that it’s simply developers saying “not my problem” to the actual hard business case things.
  - pards 2y ago
    > retain some super senior rockstar level folks able to see the big picture This is the critical piece that many organisations miss. Microservices are the bricks; but the customer needs those assembled into a house.
  - mannyv 2y ago
    You need those senior folks who can see the big picture, whether you use monoliths or microservices. The real benefit of a microservice is that it's easier to see the interactions, because you can't call into some random and unexpected part of the codebase...or at least it's much harder to do something that's not noticeable like that.
    - paulryanrogers 2y ago
      At the cost of network boundaries everywhere, and all that entails
      - mannyv 2y ago
        If there are network problems everything fails anyway, so it's not really an issue in production. In the end, it depends on your skillsets. Most developers can't deal with a lot of complexity, and a monolith is the simplest way to program. They also can't really deal with scale, and cost of learning how to build a real distributed system is high...and the chances you'll hit scale are low. So instead people scale horizontally or vertically, with ridiculously complicated tools like k8. K8 basically exists outside of google because developers can't write scalable apps, whether monolithic or microservice-based.
    - actionfromafar 2y ago
      It's so funny we always use technical solutions to solve social problems, while confusing which parts are what. :)
      - randrus 2y ago
        My interpretation of Conways Law is that social problems) in development organizations) are isomorphic to (gross) technical problems, and that leverage works both directions.
  - kunley 2y ago
    Btw, important factor: you can only see the big picture properly if you co-created the setup. Hiring senior rockstars as a reaction to problems will satisfy some short-term goals but not solve the problems overall
  - poszlem 2y ago
    "I see you have a poorly structured monolith. Would you like me to convert it into a poorly structured set of microservices?"
- hinkley 2y ago
  It's easier to find people who are confident that they understand a microservice, but the fact is that it interacts with the system as a whole and much of that interaction is dark matter. It's unknown unknowns that lead to Dunning-Kruger. People looking at a large system have more known unknowns and are less likely to be overconfident to the same degree. Also we need to have about 5x as many people graduating with formal classes in distributed computing as are now or have been for the last several decades and it's just ridiculous how many people have to learn this stuff on their own. Distributed debugging is really had when you don't understand the fundamental problems.
deleted 2y ago
[deleted]
Joker_vD 2y ago
But, uh, both Google and Yandex use monorepo-style of development; and microservices style of deployment, yes. Go figure.
ton618 2y ago
The reality is, the organizational structure likely to change over time, then would anyone want to mirror it in the repo structure?
- actionfromafar 2y ago
  Not likely, no.
atemerev 2y ago
I prefer mid-scale services. For a given app, there shouldn’t be more than 20-30 of them (and preferably around 10). Each will still have clean ownership and single responsibility, but the chaotic quadratic network effect will hopefully not get out of control. Cleanly defined protocols become a necessity though.
hinkley 2y ago
Except it never does. Have you ever heard of a company with a thousand teams? Or for that matter, how many default alive companies have more teams than customers?

sim7c00 2y ago

its also easier to find devs that have the skills to create and maintain thin services than a large complicated monolith, despite the difficulties found when having to debug a constellation of microservices during a crisis.

phil21 2y ago
For the folks who downvoted this - why? I hire developers and this is the absolute truth of the matter. You can get away with hiring devs able to only debug their little micro empire so long as you can retain some super senior rockstar level folks able to see the big picture when it inevitably breaks down in production under load. These skills are becoming rarer by the day, when they used to be nearly table stakes for a “senior” dev. Microservices have their place, but many times you can see that it’s simply developers saying “not my problem” to the actual hard business case things.
- pards 2y ago
  > retain some super senior rockstar level folks able to see the big picture This is the critical piece that many organisations miss. Microservices are the bricks; but the customer needs those assembled into a house.
- mannyv 2y ago
  You need those senior folks who can see the big picture, whether you use monoliths or microservices. The real benefit of a microservice is that it's easier to see the interactions, because you can't call into some random and unexpected part of the codebase...or at least it's much harder to do something that's not noticeable like that.
  - paulryanrogers 2y ago
    At the cost of network boundaries everywhere, and all that entails
    - mannyv 2y ago
      If there are network problems everything fails anyway, so it's not really an issue in production. In the end, it depends on your skillsets. Most developers can't deal with a lot of complexity, and a monolith is the simplest way to program. They also can't really deal with scale, and cost of learning how to build a real distributed system is high...and the chances you'll hit scale are low. So instead people scale horizontally or vertically, with ridiculously complicated tools like k8. K8 basically exists outside of google because developers can't write scalable apps, whether monolithic or microservice-based.
  - actionfromafar 2y ago
    It's so funny we always use technical solutions to solve social problems, while confusing which parts are what. :)
    - randrus 2y ago
      My interpretation of Conways Law is that social problems) in development organizations) are isomorphic to (gross) technical problems, and that leverage works both directions.
- kunley 2y ago
  Btw, important factor: you can only see the big picture properly if you co-created the setup. Hiring senior rockstars as a reaction to problems will satisfy some short-term goals but not solve the problems overall
- poszlem 2y ago
  "I see you have a poorly structured monolith. Would you like me to convert it into a poorly structured set of microservices?"
hinkley 2y ago
It's easier to find people who are confident that they understand a microservice, but the fact is that it interacts with the system as a whole and much of that interaction is dark matter. It's unknown unknowns that lead to Dunning-Kruger. People looking at a large system have more known unknowns and are less likely to be overconfident to the same degree. Also we need to have about 5x as many people graduating with formal classes in distributed computing as are now or have been for the last several decades and it's just ridiculous how many people have to learn this stuff on their own. Distributed debugging is really had when you don't understand the fundamental problems.

deleted 2y ago

[deleted]

Joker_vD 2y ago

But, uh, both Google and Yandex use monorepo-style of development; and microservices style of deployment, yes. Go figure.

ton618 2y ago

The reality is, the organizational structure likely to change over time, then would anyone want to mirror it in the repo structure?

actionfromafar 2y ago
Not likely, no.

atemerev 2y ago

I prefer mid-scale services. For a given app, there shouldn’t be more than 20-30 of them (and preferably around 10). Each will still have clean ownership and single responsibility, but the chaotic quadratic network effect will hopefully not get out of control. Cleanly defined protocols become a necessity though.

hinkley 2y ago

Except it never does. Have you ever heard of a company with a thousand teams? Or for that matter, how many default alive companies have more teams than customers?