Take a good hard look at people's ruling principle, especially of the wise, what they run away from and what they seek out. - Marcus Aurelius

The monolithic architecture has been with us for a long time. It can be thought of as the default option from the very beginning of the software industry and even nowadays. It has evolved and adapted to different technologies and frameworks, but the principle remains the same: an approach in software design where an application is developed as a single, indivisible unit, isn't it?.

The endless discussion about Microservices vs. Monolithic is heating up again. Companies like Amazon Prime Video moved last year from a Microservice architecture to a monolithic architecture, saving 90% of their spendings!!!—an impressive achievement in the current economy, perhaps it raises a couple of interesting questions around the causes why that happened, hence this article aims to explain the possible reasons why monolithic architecture is becoming popular again.

Monolith is not that bad

This architecture began to gain a bad reputation, probably after 2015, coinciding with a period when companies struggled to hire software engineers. One of the popular strategies that tech companies used to attract more talent was speaking at different tech events, demonstrating how fun it could be to work with them using the hottest tech stacks at the moment, turning out Microservices being one of them (Show Figure 1).

Figure 1 CEO at Monzo mentioning the tech strategy in 2015, got from https://www.infoq.com/presentations/banking-thousands-microservices-2023/

Another against was related to how poorly monoliths evolved over time, which is quite fair to be honest. Having everything in the same repository can indeed become messy. However, that does not mean it is the architecture's fault; it often comes because of different situations, for instance bad practices, technical debt, and software engineer rotations. In any case, Monolithic architecture wasn't that bad, as the propaganda sold it, there wasn't a grand theory that concluded that. I think some developers just felt cooler choosing microservices over monoliths because it was fashionable, and faced the cruel reality later  that microservices does not fit all the use cases.

The current economic

After the pandemic in 2020, interest rates were down globally. Let's take the US as an example, for most of 2021 and the beginning of 2022 (Show Figure 2), the rates were pretty close to 0. This phenomenon caused money to start moving largely into startups, making small/medium companies raising a lot of money.

Figure 2: Federal founds effective rates from 2009 to 2024

So why this topic is important though? When interest rates are too low, banks pay too little for having money in the bank, making it more attractive to invest in companies that could become unicorns in a few years (Show figure 3). With 2021 being a 'bull market,' most startups focused on high growth and burning money to justify further investments. At that time, the variable cost in an architecture decision wasn't really essential; in fact, spending more could help justify raising more money.

Figure 3: Investment in startups from 2012 to 2021; got from https://aviationweek.com/shows-events/space-symposium/funds-raised-space-startups-2021-double-154-billion

Of course, times change. In the middle of 2022, interest rates rose rapidly to bring down inflation, starting a 'bear market' and making raising money much harder. After that, sequoia shared a document with one of its biggest recommendations being to focus on profitability and cutting costs. Cutting costs was likely what many companies did; we saw a lot of layoffs, as well as the closing of some low profitable projects.

One of the biggest advantages of monolithic architecture is the cost; it is generally cheaper than implementing microservices, especially at the beginning. In times like we are right now, not only startups, but also big companies, will advocate for anything that helps save money and accelerates implementation to deliver business value faster. This makes modular monolithic architecture a particularly interesting option (it will be explained later).

Cost plays a very important role in any architectural decision (when the market requires that). I have been in an endless number of decision meetings where the decision matrix ended up weighing more on the price dimension, and perhaps that match the new strategy for a lot of companies, playing it safer. I watched a pretty interesting conference by Gergely Orosz, where he delves into this topic and explains it much better than me.

The state of the art

Big tech companies, such as Facebook, Amazon, Apple, Netflix, and Google (also well known for the acronym FAANG) are very vocal about their architecture decisions, they usually shared their leanings and their experience trough blog post and social media (LinkedIn). On the other hand, there are medium-small and medium companies (let's say, companies that already've found their product market fit) being low profile about their stack, architecture decisions and the technologies they use. Furthermore, most of the information about them is experiential, but what I've seen is that most medium and small companies trend to start approaching problems with simplicity, focusing on fixing the business problem first, using the less amount of resources. It means when a new discussion like microservices vs. monolith start, and the complexity appears (in terms of developers and infrastructure) they will advocate for the monolithic architecture.

With the enormous increased of blogging, it is not a secret that software engineers consume content from different tech blogs, and even these blogs have become part of the main source of their learnings. Evidently, that creates a gap, the lack of information about small and medium companies bias the decisions that architects and software engineers could take, making them advocate for the solutions where the industry is “moving” having the 'state of the art' as a component of the justification.

We've learned

The last decade has been so important for the technology sector, it has grown so fast birthing to the desk many tools, more strategies, but also developers with more experience. Microservices had been here for a long time (more than a decade), and during this time we could learn a lot about the good parts and perhaps about the bad parts too. As a result of that, a new approach came, it is called modular monolithic (Show Figure 4).

This approach trend to start off on the right foot, you can think modular monolithic as a big application which contains small applications inside (each application with its logic separated), it can be mixed with another approaches, for instance: clean architecture, design driven domain, etc. The separation of the modules is the more significant part about this approach, and one of the way to do that, is using boundaries, it can help to model an application that map the complete business context.

Additionally, high-cohesion and low coupling is not headache anymore, off course it can be achieved if the implementation is done in the right way. There will also be a path already in place if eventually a separation is needed into something more like a distributed system (so microservices).

Figure 4 :The modular monolithic architecture

Change is the only constant

Everything changes, so software does. Software engineers have to be prepared to evolve the software architecture when it is needed. It can mean migrating from microservices to monolith or migrating from monolith to microservices, of course timing is the key and the one which dictate what is needed is the business itself, don't forget, having clarity about the business prioritization will help to address the decisions to the best land.

Taking better architecture decisions, also require more than thinking only in a very technological way. It requires using soft skills such as communication, teamwork, and adaptability. I have seen throughout my career, a lot of projects fall apart only because the architecture decisions ended up being very hard approaches to implemented, and even they didn't match what the company required.

The final conclusion, if we want one, is that the Microservices or whatever architecture is trend tomorrow are not the bad guys. They are just approaches to solve problems, we should work more in the way we conclude what the word “ideal architecture” means (it will vary), and hopefully sharing more about these experiences at the small/medium companies level, enriching the content available in the literature.