MicroservicePremium

my question is, what happen is eventually some tools can be useful for overcoming the complexity introduced by microservices (e.g. CoreOS, docker, kubernetes, Netflix OS technology, etc), what could be the argument for not using them instead big monoliths?

I preferred the 'Pattern' pattern, where each line of code is its own pattern. In fact, I think he writing a whole new book about it now.

Most linux distros can be considered a collection of micro services. The stability vs innovation tradeoffs inherent to this type of systems is well understood, as is the complexity of updating and testing compatibility. I don't see why it should be so hard to draw a parallel to microservices.

What is a monolith? Intentionally tightly coupled code that you feel is going to be manageable in the future?

I think the biggest anti-pattern is "DRY". This turns a simple rails view into a monstrosity that is used to render every page of a site, or a class into a self-referencing recursing mind-puzzle.

When a codebase starts down the monolithic path, developers will often use the DRY anti-pattern to "shrink" what is actually complexity creep. They will also use another anti-pattern which is using the test coverage percentage as a key metric for deciding what to build/improve.

Both of these are attempts to fix something that is a far bigger problem: excessive, unnecessary coupling in the core design. This is often because (as others have pointed out) of blind adherence to frameworks and framework "best practices".

In my opinion, the most important metrics are coupling, lines of code (the fewer the better) and readability/understandability. Every line of code that you maintain ads a cost to changing/improving the codebase (because someone has to understand it in order to change it).

If you think of code in terms of its consumers, nearly every API is a micro-service. The less magic/faith required by the consumer to use the API, the more effectively it can be used and changed.

There are two ways to think about microservices. Development (which your comment focuses on) and deployment. The pure/idealized microservice is isolated from the rest of your environment/codebase on both of those axes. In practice, there will be some coupling on both, and perhaps one of those isn't isolated at all.

The monolith is simply the opposite of the microservice ideal, it is heavily coupled in both development and deployment.

And yes, DRY does often run counter to the development isolation, as you need to balance repeating yourself or sharing code (and reducing isolation).

As these things generally go, any system in contact with the real world will exist somewhere between the monolith and a federation of microservices. My current company, for example, employs 2 distinct codebases, Java and JavaScript, which have 3 and 2 deployments respectively, each in two similar-but-not-the-same environments (in-house and white-label). We could easily split those deployments into twice or 5x the number, we could also join them, this just happens to be where things naturally settled for the time being.