Just a reminder: picking the appropriate architecture for your application is a best practice.

As I write in my book, you must pick the architecture that satisfies your application’s non-functional requirements, which are also referred to as CFRs, software quality attributes or -ilities. I’ll give some examples of -ilities shortly.

These days, pro-monolith tweets are guaranteed to have a high level of engagement. The latest was this one:

"Monoliths are the future because the problem people are trying to solve with microservices doesn’t really line up with reality", I aspire to such savage language as that which flows from @kelseyhightower. PREACH BROTHER! 😂❤️✊ https://t.co/VJXqSsSkvT

— DHH (@dhh) January 30, 2020

which was then regurgitated by The New Stack.

The reality is that the Monolithic Architecture and Microservice Architecture are architectural patterns. A pattern is a reusable solution to a problem that occurs in a context. Monolith Always and Microservices Always are mirrors of one another. Neither is a correct except in the sense of a stopped clock. They are both examples of the “Golden Hammer” anti-pattern. Which one you should choose depends on your context, the problem you are trying to solve and the -ilities you need.

In particular, high-performance software delivery, which requires small, autonomous DevOps teams, needs an architecture that is maintainable, testable, deployable, modular and evolvable. Perhaps you can achieve high-performance software delivery of your application using the monolith architecture. That’s especially true for smaller teams and small applications. But many organization have found that they needed the microservice architecture in order to deliver software rapidly, frequently and reliably. Alternatively, perhaps your application’s key -ilities are completely different. For each application, its essential to know your -ilities and choose the appropriate architecture.

And, yes there are anti-patterns of microservice adoption including Magic Pixie Dust and Trying to fly before you can walk.

However, the fact that some organizations adopt microservices for the wrong reasons or implement them incorrectly does not detract from the value of using the microservice architecture right context.