6 ms·

I may be misunderstanding, but wouldn't you want the particular microservice you are working on independent enough to develop locally, then deploy into the remo

I may be misunderstanding, but wouldn't you want the particular microservice you are working on independent enough to develop locally, then deploy into the remote environment to test the integration? (I don't work at this scale)

animal_spirits 2y ago
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?
rtpg 2y ago
This is how you get to "I wrote to the spec, it's your problem that clicking the button doesn't do the thing". Huge feedback loops. When you run it "locally" enough you can do your integration stuff before you even ask for review.
- nitwit005 2y ago
  That doesn't seem possible to me. If you have a feature that involves 10 teams and 10 services, nothing will actually work until the 10th change is made (assuming everything was done perfectly).
  - Tainnor 2y ago
    If you have one team per service, yes. In many companies, you may have one team and 10 services though. I wish I was making this up.
- chipdart 2y ago
  > This is how you get to "I wrote to the spec, it's your problem that clicking the button doesn't do the thing". No, not really. You only find yourself in that spot if you completely failed to do any semblance of integration test, or any acceptance test whatsoever. That's not a microservices problem. That's a you problem. You talk about feedback look. Other than automated tests, what do you believe that is?
Neikius 2y ago
Yes, exactly. I just also like to have an option to run service locally and connect to either cloud instances (test) or local instances depending on what I am troubleshooting/testing. Much better than debugging on prod which may still be required at some point but hopefully not often.

animal_spirits 2y ago

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?

rtpg 2y ago

This is how you get to "I wrote to the spec, it's your problem that clicking the button doesn't do the thing". Huge feedback loops. When you run it "locally" enough you can do your integration stuff before you even ask for review.

nitwit005 2y ago
That doesn't seem possible to me. If you have a feature that involves 10 teams and 10 services, nothing will actually work until the 10th change is made (assuming everything was done perfectly).
- Tainnor 2y ago
  If you have one team per service, yes. In many companies, you may have one team and 10 services though. I wish I was making this up.
chipdart 2y ago
> This is how you get to "I wrote to the spec, it's your problem that clicking the button doesn't do the thing". No, not really. You only find yourself in that spot if you completely failed to do any semblance of integration test, or any acceptance test whatsoever. That's not a microservices problem. That's a you problem. You talk about feedback look. Other than automated tests, what do you believe that is?

Neikius 2y ago

Yes, exactly. I just also like to have an option to run service locally and connect to either cloud instances (test) or local instances depending on what I am troubleshooting/testing. Much better than debugging on prod which may still be required at some point but hopefully not often.