Microservices and monoliths are both mistakes - picking the appropriate architecture for your application is still a best practice

TL;DR

Anti-microservice architecture tweets are still popular

Anti-microservice architecture tweets still generate lots of engagement:

Microservices are such a fundamentally and catastrophically bad idea that there are going to an entire cohort of multi-billion companies built that do nothing but contain the damage that they have wrought.

— Nick Schrock (@schrockn) October 16, 2020

On the one hand, there’s an element of truth to this tweet. For example, some organizations have mistakenly treated microservices as a magic pixie dust and used them inappropriately. What’s more, a key principle when considering adopting microservices is to first make the most of your monolith.

In-reality: the monolith is sometimes a mistake

But on the other hand, this argument is about as useful as a stopped clock. The idea that you should never use microservices is quite absurb:

Yes. I've heard rumours that Netflix, Uber and Amazon have all recognized that microservices are a giant mistake. They are all busy merging all of their respective services into a giant application.exe that will be released on April 1, 2021.😜

— Chris Richardson (@crichardson) October 17, 2020

(Note: I so hope these companies are not considering this 🤞🏾😀)

The reality is that which architecture you should pick for your application depends on your requirements. If you are a small team of developers then you should probably start with a monolith. But as your application and its team grows from very small to very large, it’s likely that at some point you will outgrow your monolith. Development and delivery - as measured by deployment frequency and lead time - will, for example, slow down. At that point sticking with your monolith could very well be a mistake and you should consider migrating to a microservice architecture.