I believe that the microservices versus monoliths discussion is a false dichotomy. I've always built products where my architecture of choice is what I call the "rider and the elephant". In this article I'll convince you why the rider and the elephant is better than microservices versus monolith. The 'elephant and rider' is not a new invention, but just the name I call it internally.
The name of this architecture comes from ideas similar to Sigmund Freud's ID, ego and superego concept (yes, yes, he's a freak. We understand). This concept is where your ID and superego are in constant battle with each other while being referred to by your ego. Simply put, your 'ID' is the part of your mind that wants the icecream, your 'superego' is what knows you shouldn't have the icecream and your 'ego' is the judge between the two. Another modern and understandable example of this is likening your more developed, and intelligent forebrain to an elephant rider and your less developed but more powerful 'lizard/caveman brain'. To an elephant. As with an elephant, you can't control it, but you can guide it.
The elephant does what he wants without working with the rider and nothing productive will get done, if the rider tries to work without the elephant he won't be able to overpower the elephant because the elephant is much more powerful than him. The only way these systems can work is when they cooperate.
Traditionally, the question when designing a web app comes down to many microservices or a monolith. Why not have the best of both worlds? In one of my projects, I process many tens if not hundreds of thousands of images and PDFs, scrape tens of millions of websites, and run tens of millions of regular expressions per webpage. But the main app is written in NextJS, so how doesn't the infrastructure choke? NextJS/NodeJS is single-threaded, after all (yes, NodeJS isn't, JS is — this is for the sake of argument). Our infrastructure doesn't choke because we have two nodes. The "elephant" is a GoLang application, it doesn't contain any business logic, but at any moment has tens of thousands of goroutines turning data at all times. This is controlled by the "rider" NextJS application. The NextJS application contains all the business logic database access et cetera but none of the actual heavy data processing capabilities. We've found this to be a highly performant, and decently easy to maintain architecture.
In recent years, many companies have been moving away from microservices back to traditional monoliths. Most recently (and publicly), Amazon Prime. You know it's a decision made out of necessity when the company that owns all of the infrastructure (AWS) is moving away from its own products. Those of us who never bought into the hype-cycle could see this coming. (without even jumping onto microservices in the first place.)
This is because, during testing, we figured out that even though NodeJS runs many threads for IO/networking etc., its regular expressions all run on one thread. This translates to terrible performance when you're doing many regular expressions in the background while also trying to run the back end of your web app. Alternatively, Golang is perfect for this, you can comfortably throw tens of thousands of CPU-bound processes and it will happily churn through all of them.
Now the reply to this is, why not just write your entire application in something high-performance, like Golang for example? By that logic, it should be written in assembly. The reality is that higher-level languages are safer and more productive. There are considerably more JavaScript or Python programmers than Rust programmers. This means that not only does an hour of Rust development cost more than an hour of JavaScript development, but an hour of Rust development ends up achieving a lot less than an hour of scripting-language development. This is the nature of using a higher-level language.
Extending this thought process makes sense that we want to write as little high-performance code as we can get away with. Realistically, 90% of businesses can probably run on a monolith written in a high-level language. My eyes roll every single time people at my day job recommend a new tech project be built using microservices — it's unnecessarily loads of technical overhead, assuming you're not one of the 10% or so of tech businesses that do need some kind of data-processing setup.
Your elephant can be written in a high-performance — but harder, and therefore more expensive — language. And most of your web app (i.e. the rider) can be written in a high-level, often asynchronous programming language like Node or Python.
This means that you can keep your low-level programming costs to a minimum while maintaining high performance and being hyperproductive with a cheaper workforce working on your high-level languages.
The argument of "if there are higher performance languages, then why not just write everything in a higher performance language". This is one of the responses to companies like Discord switching from higher level to lower level languages such as their famous Go to Rust switch a few years back
If you have a full team of engineers who are willing and able to write Rust, then you should probably write Rust (unless the extra complication doesn't make sense, like a basic CRUD application). Even as someone who has been programming for the best part of a decade, I find Rust tedious (even if I am a fan of it), preferring much simpler writing and productive languages such as Typescript, Golang, Python etc. The issue with this "just write Rust" thought process, is that the overwhelming majority of software dev houses probably cannot afford to attract programmers who are raving about Rust. Most programmers are just regular people who clock in at 9 and out at 5 then go home to spend time with their family, they don't have 23.5 hours a day to spare learning about the wants and needs of Rust's borrow checker. Most companies cannot afford Rust developers, and most developers can't be bothered to develop in Rust. (this applies to all lower level / higher performance languages, not just Rust). Inherently, you get more done, in a shorter period of time in a higher level language.
This is something to keep in mind, and this is one of my many gripes with microservices. Something very important, especially because our elephant doesn't contain any kind of business logic is that we want to reduce communication overhead as much as possible often microservice architectures are built off of interprocess communication using JSON, JSON is a terrible format to communicate between microservices the serialisation and deserialisation overhead is obscene.
In my projects, I use gRPC to keep the overhead in communication between the elephant and rider to a minimum. Using a low overhead communication protocol we can afford to send a huge volume of data between the two nodes. Sending large volumes of data is also oftentimes a requirement because the elephant will not contain any kind of business logic so it will be treated as a "dumb worker".
“There are no solutions, only tradeoffs”
Ultimately, the conclusion of this article is this old Sowell quote. But I like this compromise between the flexibility of microservices and the reduced mental overhead of a monolith. Go fast where you HAVE to (not where you WANT to), and choose higher-level languages and monoliths for everything else.