[asdfman123]

I'm by no means an expert architect yet, but has the argument for microservices in smaller orgs basically become:

"Since y'all can't seem to use classes and interfaces correctly, let's physically separate the software so changing the service contracts becomes a bigger pain in the ass"?

I'm not even trying to be sarcastic. I'm genuinely curious. I feel like 90% of the benefits of microservices would be accomplished with discipline and good code review, but those things of course are more easily said than done.

(I understand your Facebooks and Netflixes benefit from having completely separate teams responsible for services with more autonomy, but I'm talking about small to midsize orgs that seem to have adopted microservices.)

[jeff-davis]

Microservices are different from language abstractions (classes, etc.) In two important ways:

1. More decoupling means you can use an entirely different langauge

2. Services can be deployed, restarted, etc. independently.

But that comes with disadvantages. The contract then becomes message passing and serialization/deserialization, which is fairly primitive. You can't pass functions/callbacks, and simple static checks become a whole validation problem. It also limits your ability to use interesting types across services.

The XML craze 20 years ago tried to tackle all of these problems (remember XML schemas?), but it became unweildly and didn't really succeed despite a huge enterprise push.

[asdfman123]

In a mid-size shop is another language an advantage?

[jeff-davis]

It certainly can be. Sometimes you start in one language but then need to integrate with something else that really only works well with a different language.