[falcolas]

I'm going to disagree with one particular point - microservices are not better than monoliths. They introduce whole new layers of complexity, latency, and points of failure that no amount of tooling can overcome.

The primary reason microservices have the opportunity to shine is that they are easy to scale horizontally.

Having been repeatedly burned by microservice complexity and failures, I'm firmly of the opinion that you should do Monoliths until you can't do them anymore. If you compose your code thoughtfully and have well defined API boundaries from the beginning, it won't be that hard to start breaking it out into microservices if you find that you can no longer scale vertically.

[cdumler]

Having built many, large, scalable systems, I would like to make a finer point: I agree that microservices are not better than monoliths. I also claim that monoliths are not better than microservices.

When implementing any architecture, the are a lot of confounding issues going to in the choices, including things like: what are the skills of the team, what are the SLA expectations, what hardware resources are available, what are the comfort levels for alternatives, what is the comfort level of retooling, what are the process audit requirements, what are the maintenance costs, what is the black-bus factor, so on and so forth.

Architecture is about addressing needs, not building software in the "hey, this is the current fad, so let's do it." Although, for some companies, that is actually a design feature. "Hey, react.js developers, come here!"

I've seen microservices that fail to scale because the entire thing was written with synchronous/single-queue calls. The biggest reason for writing a microservice is the guarantee I can prove that nothing has changed. If your authorization/authentication API is separate and proved out, I can deploy my application without concern for backdoors getting (accidentally or intentionally) into the code. I always remember: "No code is easier to verify for correctness than no code."

I always cringe when I hear "kill X before it kills you" or "x is considered harmful." What will kill any project is failing to understand and appreciate the implications for the design decisions.

[sp527]

I feel like I alluded to this, so my bad if I wasn't clear enough. Microservices are absolutely more (and perhaps only) appropriate for larger orgs dealing with serious traffic. I do also think there's an intermediary 'macroservice' concept that isn't quite several hundred services a la Netflix/Uber, but also isn't as primitive as a layer of (stateless, homogeneous) overburdened API servers with too much business logic.

[twic]

I don't buy the scaling argument in the slightest. You can scale a monolith more easily and more efficiently. It's called cookie cutter scaling:

http://paulhammant.com/2011/11/29/cookie-cutter-scaling/

The one performance-related thing that microservices give you is isolation. Say you are a newspaper; you render articles and handle comments. If you have one article where the comments section completely blows up, then with a monolith, requests for comment handling will eat all the CPU and I/O, and articles will render slowly for everyone. If you have separate services for articles and comments, you should be able to ensure that articles continue to get enough resources to be served smoothly.

[falcolas]

As with all things, it's not always that easy.

A great example I've been fighting with recently - a backend which requires a very large in-memory data graph which is unique for each user. Rebuilding this graph from the backing datastores takes between 5 and 10 seconds, but if it's in memory, responses take under 100ms.

The problem is that this monolith will be deployed in a microservice environment - stateless routers between dozens of docker hosts, each hosting multiple dozens of services, and any one of which can go up or down seemingly at whim.

Even if we were not concerned with the challenge of putting stateful applications in a stateless environment, we'd still have to worry through how to ensure that servers going down doesn't cause the entire cluster to rebalance and give everyone 10 second load times, how to route secure traffic so that users are always hitting the same servers (even across sessions), how to mitigate the data flood if the servers did catastrophically rebalance, and so forth.

So yes, theoretically, monoliths may be capable of scaling horizontally in a cookie cutter pattern. But the devil is still in the details.

Oh, and to fix your article/comments problem - just segregate off the one article to dedicated servers. Not too had a problem to solve, especially since newspaper articles are nicely routable via their URLs. Back when I worked with bare metal in colocated datacenters, it was a very popular method of handling popular customers.