Why choose Microservices over Monoliths?

 In Architecture

Why would I choose Microservices over Monoliths? Monolithic architecture is tried and true. It’s simple. It’s easy.

Microservice architecture is a cluster f**k most new devs won’t understand. But somehow, it’s gaining traction.

It’s no secret that microservice architecture is taking over the internet right now. New web frameworks are popping up every day, most of which are designed to be used in a microservice architecture pattern.

But why have microservices become so much more popular than monolithic applications? Is microservice architecture truly better than monolithic? These are the questions I’ll be discussing in this article.

But before we start comparing architectures, let’s review what exactly monolithic and microservice architectures are.

Monolithic Architecture

The monolithic architecture pattern has been around for quite some time. Developers used to love monolithic architecture because it’s so easy to work with. Consumers love it because it’s usually fast.

The idea is fairly simple. The meaning of monolithic is “formed of one single piece.” In web applications, this means the user interface, business logic, and data access layer are all formed of one application. Typically, this involves picking a framework (e.g. Laravel) and writing your entire application using that one framework.

This has some benefits, but also some bad drawbacks.

Proponents of monolithic applications praise it for being so easy to start to pick up. This is true, and it’s backed by a simple concept: less things to learn means you can learn them faster.

However, the very premise of a monolithic application leaves it at a disadvantage. Since the entire application is one piece, it doesn’t lend itself well to the concept of modularity. You can still have well defined modules, but each of your application layers will always be tightly bound to each other and the specific framework you’ve chosen.

One of the areas where this becomes most problematic is when you need to add a new user interface to your application. Maybe you’ve been tasked with creating a mobile application for your web app, maybe your current UI is just dated and needs an upgrade. Whatever the reason, accomplishing this task in the context of a monolithic application can be daunting. You’ll effectively have to refactor your application to have an API separating the business logic from the presentation, and effectively make your application have a service-based architecture. From the point of view of someone who’s had to do this a few times, I can tell you it’s not fun.

Microservice Architecture

In contrast to monolithic architecture, microservice architecture is designed with modularity in mind. The below diagram demonstrates what a microservice architecture might look like. At the very bottom, we have a few data sources we need to use. On top of that, we’ve built up a few microservices which tackle individual pieces of functionality. These microservices are consumed by an API gateway, which simply defines an interface for web and mobile apps to utilize. The API gateway utilizes the microservices defined in order to implement it’s required functionality.

This promotes a high level of modularity which keeps our implementation flexible. If we wanted to add another user interface, it’s trivial! Just write the code, and utilize the existing API. If we want to start using a new data source, write a new microservice, and have your API gateway start using it. Instead of being tightly coupled and tied to a single technology, each piece of this architecture is typically separated by common protocols (e.g. HTTP), rather than communication between the layers being tied to the frameworks in use.

Microservices are a better Architecture

That’s a daring statement, and I’m sure it rattles a lot of cages, but let me explain. In the vast majority of cases, I believe microservice architecture to be a better choice. My main reasons for this are as follows:

  • Modularity: It has very loose coupling between it’s different components.
  • Flexibility: This loose coupling allows developers to easily create new microservices and user interfaces. This alone is enough of a reason for me. I can’t count the number of projects where the owner wanted a new user interface made for their monolithic application, which usually turned into a total nightmare.
  • Scalability: Microservices can easily be distributed among a cluster of servers.

If that doesn’t convince you, then you’re probably thinking about all the good things about developing monoliths. I mean, monoliths are typically a lot easier to bring new developers into, and you can usually develop at a slightly faster pace since you only have to work in one project.

These are fine reasons to love monoliths, but the risk usually outweighs the benefits. Additionally, if the proper care is put into the initial project effort, both types of application should be just as easy to develop in once you learn the technologies used. That leaves the only major benefit being the spin-up time for new developers. This can also be reduced by having proper documentation for spinning up new devs. It is also an event that doesn’t really occur very often in comparison to the length of a project.

But what about loading speed? And SEO?

This is another reason I’ve heard for people’s fondness of monoliths.

“They load so much faster.”

“If you care about SEO at all you should use monoliths.”

This isn’t entirely true. This aspect of comparing monoliths vs. microservices is often confused for a battle between server-side and client-side languages.

This confusion is because a lot of monoliths are built using PHP (since you can do full-stack development with it), and a lot of microservice architectures use JavaScript for their user interfaces. PHP is rendered on the server, whereas JavaScript is usually rendered in the browser.

This means that PHP pages can be cached, while client-side JavaScript cannot. With regard to SEO, search engines can easily crawl all the content on server-side rendered pages, however, if your content is being created dynamically on the client-side, they’re not going to gain as much from crawling the source.

I agree that there is some kind of connection between monoliths/PHP and microservices/JavaScript. However, since the advent of server-side rendered JavaScript the point is rather flawed. JavaScript can now be prepared on the server-side before being sent to the client, so their content can be cached and crawled.

For these reasons, I’ll typically choose to use a microservice architecture 9 times out of 10.

So when should I use Monoliths?

While I am saying that microservices are a better architecture in general, I do still find valid places where monoliths are the right choice.

I build a lot of monoliths with Django as the core framework. This is because Python is super easy to work with, and the entire framework is dead simple and brings with it a lightning-fast development speed. I’ll usually do this if I have to build an application that I know will not need to scale. For instance, a web app to help manage IOT devices in my home. I also find it extremely useful for building throw-away prototypes.

Essentially, the more control I have over a project, and the more sure I am of the solidarity of it’s requirements, the more I’m willing to use a monolithic architecture (so long as those requirements are compatible with a monolithic architecture).


Microservices vs. Monoliths has long-since been a heated debate. I’ve made my preference clear, but it’s important to keep in mind that even though one architecture might be more flexible, scalable, modular, etc., that doesn’t make it the right choice for your project.

Many a time, this misconception that developers should choose the more complex, but well designed architecture/framework/tool, leads to over-engineering of a simple project.

Take this post with a grain of salt.

I try and ask myself a few questions when I’m deciding on an application’s architecture.

  • Does it need to scale?
  • Will I ever need to introduce new technologies or frameworks over time?
  • Does it need multiple user interfaces?
  • How sure am I of these answers?

If you answer yes to most of those questions, I would highly recommend looking into following a microservice architecture design. If you answered no to most of those questions, except the last, then I’d recommend looking at a monolithic architecture to make it easier on yourself.

Keep in mind that no one architecture is always the “better” choice in comparison to another. When speaking in generalities, an architecture can be a better design than another for a majority of problems. But to truly make a decision we need to be in the context of a specific problem.

Leave a Comment