3 ms·

I've worked on a large-scale micro-service architecture and I had a great time! I don't "pick a side" of this almost idealistic argument, but I do have some pus

I've worked on a large-scale micro-service architecture and I had a great time! I don't "pick a side" of this almost idealistic argument, but I do have some pushback for you: 1) You're right that there aren't merge conflicts, but you swap out merge conflicts with interface changes. Meaning let's say programmer A is working on Microservice B that consumes from Microservice C and she changes the "what I expect from Microservice C" interface. Who changes Microservice C? In THEORY it could be whoever "owns" it, or Programmer A, but in practice sometimes it falls between the cracks. 2/4) We ended up actually writing our own Python packages that did end up being shared amongst some of the microservices. If you want to abide by DRY (not juts as dogma but you just don't want to implement the same thing twice), you do need some shared code. Maybe that "breaks" the microservice "model" and we didn't do it "right"? Maybe. But with what we did, we still did have "internal Python package" updates intended for one Microservice that effected another This is all from my personal experience so it could be that we just didn't follow best practices or fell into some traps.

jeffbee 6y ago
You don't change interfaces. It is that simple. There's not a paradox here. To change your RPC protocol in a distributed system, you may add optional fields to the request but you must not add required fields nor change the semantic meaning of any field. You can add new services and methods but you must not disable one that anyone calls.
- marcus_holmes 6y ago
  Which is surely an argument for "never start a project using microservices"? Who knows exactly what their interfaces are going to be, across their entire project, on day 1, and gets that right every time?
  - com2kid 6y ago
    > Who knows exactly what their interfaces are going to be, across their entire project, on day 1, and gets that right every time? Same problem exists for binary interfaces, or source code interfaces. Or for a client system that talks to a cloud service. Or for a cloud service that exposes APIs for other cloud services to call. Technologies exist to version APIs. It is sad that JSON is the standard interchange format, since it is pretty miserable at this entire problem.
    - marcus_holmes 6y ago
      I agree completely, but all this is exacerbated if you have to make your interfaces immutable from the first version
      - jeffbee 6y ago
        They aren't immutable. You can safely add fields and you can add methods or entire services. It is easy to change microservice interfaces, you just do it in a particular way.
  - jeffbee 6y ago
    God forbid anyone should sit down for an hour and think through their interfaces before furiously typing.
    - marcus_holmes 6y ago
      hehe this is so true. But still. The problem is more in the requirements. I've never, in >25 years commercial coding, met a business problem described accurately enough that I could nail the design first try.

jeffbee 6y ago

You don't change interfaces. It is that simple. There's not a paradox here. To change your RPC protocol in a distributed system, you may add optional fields to the request but you must not add required fields nor change the semantic meaning of any field. You can add new services and methods but you must not disable one that anyone calls.

marcus_holmes 6y ago
Which is surely an argument for "never start a project using microservices"? Who knows exactly what their interfaces are going to be, across their entire project, on day 1, and gets that right every time?
- com2kid 6y ago
  > Who knows exactly what their interfaces are going to be, across their entire project, on day 1, and gets that right every time? Same problem exists for binary interfaces, or source code interfaces. Or for a client system that talks to a cloud service. Or for a cloud service that exposes APIs for other cloud services to call. Technologies exist to version APIs. It is sad that JSON is the standard interchange format, since it is pretty miserable at this entire problem.
  - marcus_holmes 6y ago
    I agree completely, but all this is exacerbated if you have to make your interfaces immutable from the first version
    - jeffbee 6y ago
      They aren't immutable. You can safely add fields and you can add methods or entire services. It is easy to change microservice interfaces, you just do it in a particular way.
- jeffbee 6y ago
  God forbid anyone should sit down for an hour and think through their interfaces before furiously typing.
  - marcus_holmes 6y ago
    hehe this is so true. But still. The problem is more in the requirements. I've never, in >25 years commercial coding, met a business problem described accurately enough that I could nail the design first try.