7 ms·

Invariably this is an ideal and does not match up in reality. I work at ~50 ish employee company and we have layers of dependencies between at least 6 or 7 vari

Invariably this is an ideal and does not match up in reality. I work at ~50 ish employee company and we have layers of dependencies between at least 6 or 7 various microservices. I can see this adding up in complexity as the product scales

rileymat2 2y ago
Yes, the real world trumps theory, hence my question.
- jrs235 2y ago
  Reminds me of a favorite quote: "What's the difference between between theory and practice (reality)? In theory, they're the same."
flimsypremise 2y ago
If the microservice has dependencies on other services it is not a microservice.
- blitzar 2y ago
  Connecting to a messaging queue or database count as a dependency? Why not break a microservice into a series of microservices, its microservices all the way down.
  - Cthulhu_ 2y ago
    Only if you cannot change one service without changing the other simultaneously. It's fine to have evolving messages on the queue but they have to be backwards compatible with any existing subscribers, because you cannot expect all subscribers to update at the same time. Unless you have a distributed monolith in a monorepo, but at least be honest about it. Multiple services connecting to the same database has been considered a bad idea for a long time. I don't necessarily agree, but I have no experience in that department. It does mean more of your business logic lives in the database (rules, triggers, etc).
    - chipdart 2y ago
      > Only if you cannot change one service without changing the other simultaneously. Not true at all. You're conflating the need for distributed transactions with the definition of microservices. That's not it. > Multiple services connecting to the same database has been considered a bad idea for a long time. Not the same thing at all. Microservices do have the database per service pattern, and even the database instance per service instance pattern, but shared database pattern is also something that exists in the real world. That's not what makes a microservice a microservice.
- dns_snek 2y ago
  According to whom? How do those microservices get anything done if they just live in their own isolated world where they can't depend on (call out to) any other microservice?
  - dns_snek 2y ago
    Would anyone care to explain the reasoning behind their down votes?
- chipdart 2y ago
  > If the microservice has dependencies on other services it is not a microservice. You should read up on microservices because that's definitely not what they are not anything resembling one of their traits.
nightski 2y ago
So basically a distributed monolith :P
- Tainnor 2y ago
  I'm sure companies with well designed and properly isolated services exist but... in my time spent at several companies, "microservices" invariably degenerate to distributed monoliths.
chipdart 2y ago
> Invariably this is an ideal and does not match up in reality. No, this does indeed match reality. At least for those who work with microservices. This is microservices 101. It's baffling how this is even being argued. We have industry behemoths building their whole development experience around this fact. Look at Microsoft. They even went to the extents of supporting Connected Services in Visual Studio 2022. Why on earth do you believe one of the most basic traits of backend development is unreal? > I work at ~50 ish employee company and we have layers of dependencies between at least 6 or 7 various microservices. Irrelevant. Each service has dependencies and consumers. When you need to run an instance of one of those services locally, you point it to it's dependencies and you unplug it from it's consumers. Done. This is not rocket science.
- Tainnor 2y ago
  You can't compare Microsoft to your run-of-the-mill small (or even large) software shop, though. Maybe on HN, most people work on these amazingly designed systems, but in my experience most tech out there is shit and has no proper design or architecture beyond "we're doing microservices because everyone is".
  - chipdart 2y ago
    > You can't compare Microsoft to your run-of-the-mill small (or even large) software shop, though. I'm talking about how Microsoft added support for connected services to Visual Studio. It's literally a tool that anyone in the world can use. They added the feature to address existing customer needs.
    - Tainnor 2y ago
      Apart from the fact that not everyone uses Visual Studio, "connected services" appears to be something by which you can connect to existing cloud-based services. How does that solve the problem of a mess of interconnected services where you may have to change 3 or more of them simultaneously in order to implement a change?

rileymat2 2y ago

Yes, the real world trumps theory, hence my question.

jrs235 2y ago
Reminds me of a favorite quote: "What's the difference between between theory and practice (reality)? In theory, they're the same."

flimsypremise 2y ago

If the microservice has dependencies on other services it is not a microservice.

blitzar 2y ago
Connecting to a messaging queue or database count as a dependency? Why not break a microservice into a series of microservices, its microservices all the way down.
- Cthulhu_ 2y ago
  Only if you cannot change one service without changing the other simultaneously. It's fine to have evolving messages on the queue but they have to be backwards compatible with any existing subscribers, because you cannot expect all subscribers to update at the same time. Unless you have a distributed monolith in a monorepo, but at least be honest about it. Multiple services connecting to the same database has been considered a bad idea for a long time. I don't necessarily agree, but I have no experience in that department. It does mean more of your business logic lives in the database (rules, triggers, etc).
  - chipdart 2y ago
    > Only if you cannot change one service without changing the other simultaneously. Not true at all. You're conflating the need for distributed transactions with the definition of microservices. That's not it. > Multiple services connecting to the same database has been considered a bad idea for a long time. Not the same thing at all. Microservices do have the database per service pattern, and even the database instance per service instance pattern, but shared database pattern is also something that exists in the real world. That's not what makes a microservice a microservice.
dns_snek 2y ago
According to whom? How do those microservices get anything done if they just live in their own isolated world where they can't depend on (call out to) any other microservice?
- dns_snek 2y ago
  Would anyone care to explain the reasoning behind their down votes?
chipdart 2y ago
> If the microservice has dependencies on other services it is not a microservice. You should read up on microservices because that's definitely not what they are not anything resembling one of their traits.

nightski 2y ago

So basically a distributed monolith :P

Tainnor 2y ago
I'm sure companies with well designed and properly isolated services exist but... in my time spent at several companies, "microservices" invariably degenerate to distributed monoliths.

chipdart 2y ago

> Invariably this is an ideal and does not match up in reality. No, this does indeed match reality. At least for those who work with microservices. This is microservices 101. It's baffling how this is even being argued. We have industry behemoths building their whole development experience around this fact. Look at Microsoft. They even went to the extents of supporting Connected Services in Visual Studio 2022. Why on earth do you believe one of the most basic traits of backend development is unreal? > I work at ~50 ish employee company and we have layers of dependencies between at least 6 or 7 various microservices. Irrelevant. Each service has dependencies and consumers. When you need to run an instance of one of those services locally, you point it to it's dependencies and you unplug it from it's consumers. Done. This is not rocket science.

Tainnor 2y ago
You can't compare Microsoft to your run-of-the-mill small (or even large) software shop, though. Maybe on HN, most people work on these amazingly designed systems, but in my experience most tech out there is shit and has no proper design or architecture beyond "we're doing microservices because everyone is".
- chipdart 2y ago
  > You can't compare Microsoft to your run-of-the-mill small (or even large) software shop, though. I'm talking about how Microsoft added support for connected services to Visual Studio. It's literally a tool that anyone in the world can use. They added the feature to address existing customer needs.
  - Tainnor 2y ago
    Apart from the fact that not everyone uses Visual Studio, "connected services" appears to be something by which you can connect to existing cloud-based services. How does that solve the problem of a mess of interconnected services where you may have to change 3 or more of them simultaneously in order to implement a change?