Comment by bszupnick | Hacker News Reader

Comment by bszupnick | Hacker News Reader

Parent Full thread

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.

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.

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?

> 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.

I agree completely, but all this is exacerbated if you have to make your interfaces immutable from the first version

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.

God forbid anyone should sit down for an hour and think through their interfaces before furiously typing.

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.

Reply on news.ycombinator.com