That was my 1st reaction too ... but hold on. If you design the 2 components to be non-chatty and have robust error handling, then it can be safe to make it location transparent.

In other words, the problem in the past was, we designed it as if it would be used locally, then we naively made it remote. But now, we're talking about designing it for remote use, but then using it locally.

Interesting.

It still has all the other disadvantages of remote services, like consistency problems (everybody always assumes that RPC calls are as reliable as 2 phase commit, and they're not), more and more complex code that's harder to change, less flexibility on all fronts except for the one, ...

Things like distribution are a tradeoff, an optimization : you should never split a monolithic application into 2 communicating parts until you have good reason to do so.

A monolithic system executing a given function is pretty much guaranteed to be simpler than a distributed system doing the same function.

A small amount of microservices is easier on the guy doing ops work for the system, because they can be individually replaced, upgraded or changed (IF the developers put in the constant amounts of efforts needed to make that possible. Every release should be able to deal with past versions of everything it talks to). These guys are also usually the ones doing load balancing and the like, so bonus points for being able to spread them over the network.

Of course, numbers of microservices always grow, and grow, and grow some more. Soon it's not easier anymore on the ops guy, and becomes a constant drag on progress for everyone.

> A monolithic system executing a given function is pretty much guaranteed to be simpler than a distributed system doing the same function.

And what about a monolithic system executing thousands of different functions?

If your app is a simple todo list, sure, go monolithic (but you should still delegate storage to some other tool). If it is much more complex than a todo list, then it is very likely that you have many packages containing many modules developped and maintained by many programmers. And if one glitch on one side of the monolith affects a remote module and functionalities depending on it, or even breaks down the whole monolith, then you should go microservices. Or split your code base. Or do whatever is needed so the thing can still move forwards, if slowly, without breaking apart at each little step.

> If it is much more complex than a todo list,

See , that's the problem with you people advocating micro-services , RIGHT HERE. Your statement is ridiculous and make it hard for people like me to take micro service advocates seriously.

I'm sorry, I do not understand why you find this statement ridiculous (I'm not native English-speaker). Would you mind explaining a bit?

Because we have decades of examples of monolithic apps more complicated than a to do list, but very little time with micro services.

If you honestly believe you can't write robust & scalable monoliths at all, that is an extreme position that is hard to square with many peoples experience.

The problem is that for a monolithic system to be divisible, your team has to have been applying a level of discipline that is not verifiable. It's all on the honor system, and (half jokingly) developers have no honor.

Seriously though, all of the problems breaking the system up will be blamed on people who already left the company, whether they deserve it or not, and the patterns that keep you in a monolith will continue on forever.

The only solution I've seen sort of work for this is to make a single binary, but create modules with extremely clear boundaries. Even so far as compiling them separately if the language is statically typed. But even that can go sideways the moment someone builds caching into the system.

I've come to appreciate why external caches are so popular, but for my money I prefer caching at the HTTP layer. You have to solve all the same problems, but you get one level of cache for free, it's easier for QA to understand, and it puts cache eviction in the hands of mature pieces of code that all implement the same spec (which might account for my previous point).

I agree, the consistency problems should be handled inside each individual services and the layer before all the services should be as simple as normal balancer.

Top-down configuration (as opposed to discovery like UDDI) via something like zookeeper or dns solves this problem. And APIs shouldn't do WSDL either, the code and docs should document the API. It's possible to add so many over-engineered layers of YAGNI flexibility that almost no one can understand what the heck is going on or how to hack on it, e.g., Eclipse plugins.

Keep it really simple, until it breaks too often.

Really good suggestion for the API doc. I admit that writing documentation is much harder than code;)

People could (and did) design robust CORBA and (D)COM objects, but the overhead was too high in some (many?) cases. Overhead in development time, but also run time. If I can pass a const pointer to a bunch of data (if I know the consumer will live in the same memory space), then that's way faster (in development and run speed) than having to marshal that data into a common byte-order and alignment etc., most likely requiring copying, keeping track of who changed what when, ...

Now that I have my old fogey hat on anyway, I might as well state the 'old wine in new bags' feeling I get with articles like this. Encapsulation and separation of concerns is good you say? But inconvenient because there is overhead? So infrastructure to manage dependencies and deployment of sets of loosely coupled components is useful? Whodathoughtthat!

It's tough.

Pass by reference became de rigeur for high performance systems when we agreed that the message passing overhead represented the plurality of computation time.

But pass by reference is shared state, and as we started trying to build systems with threading and for multiple cores the ugly truth about memory coherence on modern processors came out. It was pretty bad. Java and later C had to come up with some pretty odd looking compromises to get safety without throwing away all of the speed advantages.

Yes, you got the idea. We focus on providing developer the "ability to switch or mix between microservice and monolithic styles" so people get flexibility they need for different circumstances (e.g. development vs deployment vs testing).

And then we agreed that location transparency was bad in RMI, and then again in EJB. It's regular as the tides. In a couple years you'll hear everyone talking about how stupid the Cloud is and everyone will be buying their own servers. Then we'll decide that peer-peer is the way and the light.

Didn't Vonnegut have a line about how it affects you to see the same mistakes repeat over and over?

Its more about bandwidth vs capacity vs dollars. The optimum changes as the technologies change.

Touché. Every time we hit a new balance in the inequalities we have to re-evaluate all our answers.

I guess what bugs me is not the mind changing (I do that all the time myself). It's that those without a history lesson behave as if this is a bloody revolution, and they have to pick sides. And the people who think switching solutions will magically fix all of our problems.

I don't think the failure of one (or even two) implementations invalidates the concept itself. I see nothing fundamentally wrong with the idea of location transparency (where it matters)