[iofj]

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.

[gbog]

> 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.

[aikah]

> 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.

[gbog]

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?

[kasey_junk]

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.

[hinkley]

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).

[lsm]

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.