A big predatory fish facing a school of small predatory fishes, symbolizing the system architectures monoliths and microservices, respectively.

Monoliths or Microservices? A Comparison

Which Architecture Fits Your Business Best?

It’s a question no company hosting their own app or software program can avoid: Microservices or monoliths? Which system architecture shall it be? 

Skimming through the world wide web of tech talk, you might notice a distinct tendency: The Monolith seems to have fallen out of favor in behalf of microservice SOAs. But there are counter voices, too. They point out that microservice architecture comes with its own set of problems.

But what are the specific advantages and disadvantages of microservices and monoliths? First and foremost it’s all…

A Question of Perspective

Which system architecture will prove best for a given software is very much a matter of probing the battlefield. When thinking about the ideal approach for your project, you should mind the following questions:

  • What are the core functionalities of your product? Do you want a straightforward application with a strong focus or have you already planned to add more and more functionalities as you go along?
  • How big is your development team? And how streamlined is the communication flow between your team members?
  • What does your system infrastructure look like already? Did you already decide on a system infrastructure and want to migrate on another one? Why?

How you answer these questions will give you an idea which architecture, microservices or monoliths, might work better for your company. In the end, it all comes down to the division between centralized and autonomous. It’s time for a comparison.

The Microservice Multiplex

Flexibility through autonomy: It’s what microservice architectures strive to achieve. Microservice applications consist of many interconnected, but autonomous single services.

Aspects of Microservice Architectures

Small, Individual Building Blocks

Every service runs its own processes on its own code base. When working together those singular building blocks form the whole of the application. That means development teams can modify, extend and deploy each service independently. They can even base each microservice on very different technologies and program languages. But mind, that multi-technology software is harder to keep consistent, as Martin Fowler points out.

Less Bottlenecks

In microservice environments, there are few hard dependencies among teams. Development processes are decoupled. Coding teams can work on their specific features without stepping on each other’s toes. It’s also easier to update the system to the newest technology, as this can be done one part at a time.

Easy Scaling

Microservices easily scale horizontally, as they scale independently from each other. Thus, they can cope with high traffic. Services that reach the end of their capacities can be updated without touching the rest of the system. This allows for continuous delivery of features.

Failure Safety

Coding teams can tackle different features of an application simultaneously. While doing so, they don’t have to fear breaking the whole thing. If one service fails, this doesn’t cause the entire system to fail. On the other hand, having multiple services increases effort and costs of maintenance, as interdependencies that exist between services must be closely monitored.

The Practicality Question

As corporations like Google or Netflix settled for microservice frameworks, many small companies do the same. But not all business models are suited for microservices. The microservice approach works best when backed by big, specialized teams. Keeping a multitude of microservices consistent is as huge organizational effort — all the more, if they are build on different coding languages. Mind Conway’s law.

Smaller Is Not Faster

It’s not trivial to build up a distributed system in a fashion, that the singular services don’t slow down the whole. Every service is connected through remote calls. Such calls take time, especially when many services are called in at once. Increasing the granularity of the calls can somewhat alleviate the problem. In turn it increases the complexity of the programming, though. Given time, microservices can easily amass significant overhead.

Microservices? Yes, if …

… your company wants to release a complex product, based on a variety of program languages. Microservice SOAs are also preferable, if the software’s features shall scale individually. Before inviting the complexity of a microservice framework, ask yourself how much decoupling your application will need. A straightforward app with clear, linear features doesn’t necessarily require a fractured architecture.

The Mighty Monolith

In contrast to microservices, monoliths are build as a single, consistent unit. This unit holds the whole core functionality of the application. All its singular components use the same code foundation, the same memory and the same systemic ressources.

Aspects of Monolithic Architectures

CCC-Friendly

As Sinclair Schuller rightly point out, many applications are reliant on a large number of cross-cutting concerns, be it audit trails, logging or similar processes. Monoliths have an easier time incorporating such recurring concerns, as everything shares one code basis.

Balanced Time-Cost-Ratio

Monoliths are basically one giant, linear application, when compared to microservices. As such, they are easier to plan and design than microservices, which can require some “back and forth” between the teams of several services. It’s true that deployment of single features can proceed quicker in microservice SOAs. But getting a project ready in the first place often takes more planning time. And thus, it’s more expensive.

Less Compatibility Issues

In a monolithic system every line of code stands on the same foundation. Thus, compatibility can be determined easier as in cases, where the app consists of several services using different technologies. Furthermore, the unified nature of the code simplifys testing and debugging the application.

Big and Speedy

If constructed properly, monoliths are often more performant than microservices. Shared memory and code allow faster communication between components of the software. On the other hand, microservice environments are only as fast as the communication of their processes allows.

It Stands and Falls With Communication

Monolitic architectures work best if maintained by small teams. Changing any part of the system requires updating the monolith as a whole, so team members plan their deploys in conclusion. Microservices can also suffer from bad communication — especially when the updated services are communicating with other services often. But it’s easier to spot obstacles and bottlenecks there.

Monoliths? Sure, but …

… mind scalability and team setup. A monolith has advantages for companies and startups consisting of small teams. It allows them to get their initial product released in short time and with a clear, comprehensive code foundation.

Monoliths? Microservices? The Best of Both Worlds!

Monoliths and microservices aren’t as mutually exclusive as the paragraphs above suggests.

It is perfectly possible to arrange a pool of microservices around a single, monolithic core application. The monolith runs the main business logic, while its subservices scale independently and can be deployed without changing the monolith’s code foundation.

Small companies and startups benefit from this approach. Building up their central product as a monolith will enable them to release it with short time to market. The micro-subservices add to this. They give opportunities to expand the monolith while avoiding dependencies. However, keep the microservices small enough to quickly communicate with the monolith. Otherwise you are giving away the performative edge gained by using a monolithic core.

For balancr and its sister products, we’ve decided to settle for the monolithic approach, as it fits our workflow and the layout of the software better. We are convinced by the advantages of monolithic SOAs: While monoliths have their disadvantages, they are also more reliable and easier to handle for us and for the startups and companies we’ve entered partnerships with. And as we have seen, monoliths and microservices can complement one another as the software grows.


Our products are based on monolithic architecture, but we also offer software development services. If you want to learn more, shoot us an email at info@trimplement.com.

You find more information about our company and our product balancr on our homepage. We’re also on social media, so be sure to follow us on TwitterLinkedIn and like our Facebook page.

Leave a Reply

Your email address will not be published. Required fields are marked *