5 ms·

Maybe that microservice needed to change its method signature because it was missing something.

• chii 7y ago
  and so you don't have a microservice, but just code that's spread out. a feature of microservices is a way to add new apis while retaining old apis (for compatibility). So you'd write the new signature, and deploy. Everything still works fine. Then the other services can be slowly updated to use the new signature, one at a time.
  • allover 7y ago
    So you're making the same change but taking longer to do so?
  • cc81 7y ago
    Yeah, unless it is a bug like I said. Maybe you forgot that you need to save X as a well and that all services that use it must pass X otherwise the data saved is invalid.
  • magicalhippo 7y ago
    What if all the other services using the old API are doing the wrong thing because the old API was wrong? The bug isn't fixed until they all use the new API. As an extreme example, just to highlight, what if you have a login service where you only take the username and hand back an access token. This has the exploit that anyone can get super user access by simply passing the right name. So you patch the login service to take a password as well. But the exploit is live until all the other services is using the new API... so wouldn't you want to prevent the old API to be used, breaking any service that hasn't been updated yet?
    • yebyen 7y ago
      If the interface is so wrong that the implementers actually can't use it safely, that's not a microservices problem any more than it's a monolithic architecture problem. It's important to design interfaces before they are implemented everywhere. And the D in SOLID stands for Dependency Inversion, I think it applies here. It asks: When you design a dependency relationship between a big (concrete) thing and a bunch of little (concrete) things, which way should the dependency relationship between them be arranged? Should the big thing depend on the little things, or is it the inverse? There might seem to be an obvious right answer, but the way I phrased it is deliberately deceptive because according to Dependency Inversion the answer is neither. You should have an abstract interface between them that both depend on, as I understand it. (and I'm learning, I got my CS degree almost 10 years ago but just now finding out about these things, so nobody feel bad if you didn't know this... and anyone else who can explain better is also welcome) This principle is important here because keeping interfaces simple and abstract makes it easier to spot issues like this one, that should never make it into production. An authentication interface that only takes one parameter username is something that would never make it past the first design review meeting, unless it was a specification buried in a majorly overcomplicated concrete implementation (or if they didn't look at the interfaces at all).
      • magicalhippo 7y ago
        > If the interface is so wrong that the implementers actually can't use it safely, that's not a microservices problem any more than it's a monolithic architecture problem. Right. My point was that there are code bugs and architectural bugs, and from what I can see microservices only really help with the first of those.
    • staticassertion 7y ago
      Then you redeploy everything. But you're making that call based on risk, not due to a technical requirement.
  • jussij 7y ago
    This will only be true if the bug fix had local impact. If instead the discovered bug was more fundamental in nature (i.e. a problem was found in the actual design/implmentation of the signature/api itself) then every service using that api will need to change.