In theory, yes, you don’t need the network boundary to write better code but that’s just part of the problem. Keep in mind that very few organizations are able to keep the employees for a long time so a microservice architecture would help new developers (especially non-senior developers) get up to speed quickly simply because it’s a smaller codebase and it’s easier to figure out that individual part of the domain. From my experience, that makes it a lot easier to understand the domain.

If you kept track of which services were on which hosts, could you use same-host calls when possible and prevent the network boundary? And if you kept track of service dependencies, could you schedule services to run on optimal hosts (like CPU affinity) and solve that problem with your service scheduler?

As with nearly everything, the actual answer is “rules of thumb don’t work and you need to know what you’re doing”. But because knowing what you’re doing is difficult and extremely rare, most organizations go with rules of thumb instead (or the people who know what they’re doing get overridden by those who don’t) and we end up with ridiculous scenarios like the micro vs. monolithic service “debate”.

Agreed. I am in favor of beginning with a monolith, and as the problem domain and implementation’s needs solidify, shaving off compartmentalized chunks of functionality into services (be they “micro” or just the standard variety).

That implies that the monolith lives on, possibly just until more isolation occurs and it shrinks to nothing, but possibly lives on forever. And that can be okay.

The big take-away being that starting with microservices is not likely to provide the same advantages that transitioning to microservices provides for a more mature product and team.

Agreed. I am in favor of beginning with a monolith, and as the problem domain and implementation’s needs solidify, shaving off compartmentalized chunks of functionality into services (be they “micro” or just the standard variety).

I’m in favor of writing modular code so that when the need arises it’s simply a matter of extracting the module from the monolith and writing a new main. But realistically, I’m not rewriting anything, just turning off parts of the monolith that aren’t going to run in this new, split out service.

Indeed. Sometimes what is labeled as a microservice, isn’t; and sometimes its responsibility could better be implemented as a library.

There are a lot of things that can go wrong: distributed resource sharing, choice of wrong protocol, improper state handling, etc. It’s curiously a lot easier to design a microservice incorrectly than it is to botch up a monolith.

You want to use a different language for a certain bit of functionality

You have a large number of dependencies for a project, which makes the monolithic approach no fun to work with
(certain machine learning libraries can be a huge pain to install)

There is very little overlap between the two components and it improves your ability to monitor the system to separate them. (IE. I could run Thumbor on my main API, but its much easier to have it running on its own cluster)

I’m curious, when do you like to use micro services? Or you prefer 100% monolithic?

I’m curious, when do you like to use micro services? Or you prefer 100% monolithic?

I’m not a microservices proponent; i agree with the article. But i don’t think that not going for a microservice architecture implies going 100% monolithic. You can have different services without going micro ;)

For instance, a common architecture for websites nowadays is having an API backend as one service/project/thing, and the webapp frontend as another service/project/thing. I think this kind of separation, without going to ridiculous lengths of separating every functionality into its own microservice, makes a lot of sense. And it’s not a 100% monolithic solution, as you have the freedom of making architectural changes to either the frontend or backend services (like change the language/framework it is written in) without affecting the other.

As patrickdlogan points out above, you don’t really have to choose, since it’s a false dichotomy. It’s only about the size and responsibilities of the service, and that metric is absolutely relative, in the context of the developing organization.

I second this. At my workplace there used to be two monolithic applications and they are getting converted into two microservices (billing and session management) and another big application (a backoffice app). It doesn’t have to be an all-or-nothing type of approach.

Also known as Erlang. Which is indeed a nice concept, but the problem arises when people have crashable stateless services without the important pieces of Erlang: supervision trees, sane message passing, process links.

Microservices as many folks implement them really are poorly specified, slow, buggy implementations of half of Erlang.

And even if you do have all those pieces, there are hard problems at the application level to think about.