Microservices go beyond encapsulation in important ways, and regress in other ways.

Build/deploy/release cycles become independent with microservices, which can be great. Also you can write microservices in different languages.

But the APIs can become less rich. Try passing callbacks between microservices written in different languages. And it can be more of a pain to change APIs. And if there's any state to worry about, you need to manage that and maybe use a stateful protocol (which are harder to get right).

> Build/deploy/release cycles become independent with microservices, which can be great.

I accept that coarse-grained services can have independent lifecycles, but not microservices. I'm working on a microservice-based project, and two things we've learned are that there are almost no features we can implement in just one microservice, and that if we don't test microservices together, we get bugs. So, in practice, their lifecycles are tightly coupled.

Some people ding this for being a 'distributed monolith' rather than some kind of 'true microservices', but i don't see how we could factor this application into micro-sized bits that would not be tightly coupled.

> Also you can write microservices in different languages.

I worked somewhere that tried that for a while (although small services, rather than microservices). It turns out that it makes it really hard to share people, libraries, and learning between teams, and that the task-specific advantages of particular languages mostly aren't great enough to make that worthwhile. We managed okay with some bits in Java and some in Scala, but adding Clojure and Groovy was too much. I think there are some bits in R now, but they're owned by a completely separate part of the organisation, so Conway's law allows it.

> It turns out that it makes it really hard to share people, libraries, and learning between teams

The idea is that you don't do that. It's a matter of duplicating functionality across teams so that each team isn't beholden to another team. pushing that library doesn't suddenly break things, for example.

Whether you agree with it or not, when you choose microservices, you choose to avoid sharing libraries like that. In the small it's probably ok (across microservices in 1 team, depending on circumstances), but in the large the gain isn't worth the added maintenance hassle.

Libraries, sure. But if you've chosen an approach where you can't move people and learning between teams, you've chosen failure.

I don't even know what that means.

The independence of microservice is not always achieved. You often end up with a mess of interrelated services depending on fairly narrow version ranges to retain compatibility. The more homogeneous your production environment is, the less that's a problem. The worst case is when you have a dozen (or hundreds...) of production clusters that are all independent and not necessarily in-synch as far as deployed version goes.

Absolutely.

Developers often gloss over how truly difficult it is to make good API choices. And when the wrong choices are made, it goes wrong quickly.

Microservices probably amplify this effect, but it's hard to say.

And if its a business application, and the company survives long enough, it will invariably get complicated.