Monoliths have a place
The problem
As an enterprise architect, I see a lot of solution architectures. A common theme is that application teams have been told to modernize their applications with, sometimes, clear direction as to what modernizing means (use microservices!).
And this leads to all sorts of unwanted behaviours and wrong architectural decisions (we'll just take our app, shove it in a container but still use persistent storage mount points in the container as an example of a wrong architectural decision. There are exceptions of course, but generally, your containers should not be coupled tightly to a particular node pool just because of how the SAN storage is configured).
What I've been harping on about, is that, there is no one architecture pattern that fits all. And there are credible folks online saying the same. In fact, I'm going to quote Werner Vogels (AWS's CTO) from this article.
"However, I want to reiterate, that there is not one architectural pattern to rule them all. How you choose to develop, deploy, and manage services will always be driven by the product you’re designing, the skillset of the team building it, and the experience you want to deliver to customers (and of course things like cost, speed, and resiliency). For example, a startup with five engineers may choose a monolithic architecture because it is easier to deploy and doesn’t require their small team to learn multiple programming languages. Their needs are fundamentally different than an enterprise with dozens of engineering teams, each managing an individual subservice. And that’s okay. It’s about choosing the right tools for the job."