The End of Microservices

First, libraries don't encapsulate very well. A storage service hides its representation from users. A storage service can change its implementation at any time without users having to know or care. Perhaps you migrate from Cloud Provider X to Y. A shared storage library, on the other hand, can't just change its implementation on a whim. Libraries vend functionality, and they encapsulate functionality at a coding level, but they don't encapsulate much at a systems level, especially in distributed systems. For example, if this function would talk to a data store like a database or another remote service, then under the service approach, only one application talks to the database, while with the library approach, a ton of applications using the library do -- and now they all need network access to that DB and credentials to talk to it. They care about the details of how to reach it. Every library consumer needs that configuration.

With a service, you can implement security features like input sanitization and access control on the service-side. With a library, you're reliant entirely on trusting its users. (A library can have these functions too, but a malicious user or attacker can bypass them if they compromise the machine it's running on. A service implementation runs in a different security context.)

When a library changes, you need to tackle the problem of distributing the new version to every application that uses it. When a service changes, you just deploy the new version, and all systems using it immediately experience the new version. When a service changes, you can completely coordinate the way in which the new functionality rolls out. You can pass 1% of requests through a new version of the code, if you want. You can pass requests through both versions of the code, and compare one to the other. You can in principle do these things with a library, but few organizations have the ability to roll out updates to all usages of a library nearly as effectively as they can change and redeploy a service. Services allow the service owner to centrally control the behavior of the functionality in all circumstances where it's used.

Libraries don't help you scale different parts of your system differently. For example, let's say that the storage service needs to cache a lot of content for good response times. If that's a library, then all of the applications using it need to have adequate RAM or disk for the cache. With a storage service, that can be hidden behind the service interface, and only the machines running the service need the extra RAM/disk.

Services are portable in a way that libraries are not. A library needs to be implemented in a way that can be consumed within many platforms. For example, it might not be easy to vend the same function for applications on Windows, Ubuntu, MacOS. With a service, I might vend only an interface description, or lightweight clients for the platforms I target.

A service separates the consumption of the functionality entirely from its operation. If there's a defect in the service, like it's returning the wrong result, then that's the service owner's problem to fix and roll out an update. If the library everyone is using in their applications is returning the wrong result, then that's now everyone's problem.

With a service, I can measure anything and everything I might want to know about the behavior of an operation. I can record metrics and log files and anything I want. With a library, there isn't always an easy way to get the information out of applications that use it. Services make applications easier to understand and troubleshoot, because you can reduce the amount of code running on any given machine (VM) to the smallest reasonable amount, compared to applications that embed potentially many libraries. Debugging a library is tricky because you need to debug the application too. I can debug or instrument a service all on its own, without affecting its clients.

The right answer to this question might depend on the scale of the component's usage, the scale of the functionality, and how much you care about these properties, and encapsulation, and coordinated update, etc. Services start to become compelling at a sort of inflection point where you have a lot of usage, enough that updating all applications using a library would be problematic, and you want to decouple things (both components within software and the organizations that develop and run them). I probably have more to say about this, but I'll leave it here. There are plenty of reasons why you'd choose to make something a library, but there are also good reasons why to choose a service.

It is called unit, module, package, library.

No need to put some network layer, with its own set of problems, between method/function calls.

I give the proponents/consultants credit for proposing a practical and incremental solution to these people instead of just insulting them or saying "you're doing it wrong".

That being said, the issue I have with microservices is the fact that the below is repeatedly used as a core technical argument :

> They had built the whose system using the classic, box-box-cylinder architecture. There were hundreds of little top tier 'services', but in practice, they all shared the same database, had to be deployed pretty much at the same time, and version upgrades had to go in lockstep. Every so often, database changes were necessary, and the world would grind to a halt for months to make the system still work after the migration: It was awful.

This is not a feature of "monoliths", this is a feature of shortsighted design (at the beginning) and cowboy design (at the end).

Let's be clear : apart for load balancing for performance critical areas (which only exist in 20% of the applications, and only cover 1% of a typical such application - or 60% if you are Google, Facebook, or Amazon or the rest of the top 10), there's nothing that microservices do better than in-memory libraries. Also, centralizing everything as opposed to having processes run on various servers creates the issue of the single point of a failure. Whole new classes of similar issues appear. It basically is buying troubles.

Adding microservices will never be a neutral operation, and incurs a real cost. This cost is the cost of distributed objects which has been known for over 20 years and has been well-documented by our fathers.

Once the above has been dismantled, it then comes to : "yes but teams can develop in different languages", "yes but dependency management becomes easier". But once again, when it comes these interoperability considerations, a solution also exists and has been created about 15 years ago. This solution is called .NET (30+ languages compiling to a single Intermediate Language, COM components, first-class library support, etc...). Even the "yes but I need to communicate with non .NET in-memory applications" is very maturely addressed by the framework. (it was one of the first-use cases addressed)

I also read in this thread : "the ability of teams to control their own destiny and not be blocked by other teams". With libraries teams can choose the version that works best for them, and a well-design in-house library would provide the extension points (Dependency Injection, Dynamic Binding...) that would allow the clients (the other teams) to specialize the behavior.

So in a gist, my main reproach for this, is that if people put the same effort they put in learning microservices to learning system and component design, they wouldn't even be a need to talk about the former. My regret is that people will always choose the hype and the new. But hey, that's how the game works.

But there's now a whole bunch of new developers out there who are just starting out and read all about these microservices, and think that it's the way to write web backends, and that if you don't do it that way, you just don't know what you're doing. Even if you're a two person team - you must use microservices if you want to scale out in the future apparently. It's just unfortunate the amount of cargo culting going on.

If by "sharp boundaries with clear interfaces", you mean API specification, how is it a microservice thing? I thought the benefits of microservices lie in behind-the-scenes details.