Why can't folks just assess their own situations, review/learn about possible solutions, try stuff out and then eventually go with something?
There's going to be unpleasant problems no matter what you choose. There's no silver bullet. Projects fail for many different reasons, only one of them is because of wrong "technology platform choice."
If you're anywhere near the point of "needing" microservices (if there is such a thing), there is no simple "try stuff out", fwiw. You're talking about potentially 10s of different teams needing to be involved even for some small effort.
Microservices are very complex, especially if you don't know the domain beforehand. Most of the time, the additional complexity brings more harm than the benefit.
> Microservices are completely disrupting the way we build applications nowadays. This is one of the hottest trends when it comes to software architecture. More and more developers are adopting it.
> Microservices are an alternative to the monolith approach that gives developers the flexibility, scalability, and simplicity they need to build complex software applications. Companies all over the world have recognized the advantages they get with microservices. Amazon, Netflix, eBay, Spotify, Uber, Groupon, and SoundCloud, are only some of them.
At the bottom of the challenges section, it mentions:
> Aside from all these disadvantages, it’s very important to state that the right kind of automation, tools, and developers who are rockstars in their areas every challenge can be solved.
It also does briefly mention why you'd want a monolith, but doesn't really give it much weight:
> Monolithic architecture is better when:
> * the application you’re developing is simple, and everything is in the same language and framework,
> * you want to test quickly and easily by simply launching the application, and
> * you don’t have too many new features that will trigger the release of the entire application.
So basically the way this comes off:
* Everyone is using microservices, and if you aren't, you should be.
* Only "simple" apps that aren't getting new features use monoliths (and who describes the app they are spending a significant effort on as "simple"?)
* If you find them too hard, you're not a "rockstar" and/or you don't have good tools.
It may not be the intent of the article to have this tone, but that's the way it comes across (and so many articles advocating for the trendy technology-of-the-day are written in this style).
This causes people to react strongly the opposite way to balance it out, and that knee-jerk reaction is naturally "don't!". I bet many of those reacting this way are people that have negative experience and know the downsides better than described here.
Of course every team should evaluate technology decisions on their merits, but cargo-cult programming, resume-driven development, and clueless managers that want to show they're working on the "new hotness" are all things that drive these decisions, and articles written like this strongly influence all those categories.