Monolithic architecture vs microservices

Care to share?

Microservices development for eCommerce is effectively pushing monolithic architecture out of the market. Industry leaders are now building their empires on microservice architecture. But why is this approach to architecture chasing out the traditional monolithic structure? We’re going to take a look at monolithic architecture vs microservices to find out which is better for business and why.

What are the pros and cons of monolithic architecture?

It is a traditional model for software in which the structure is a single and indivisible unit. A monolith has one code base with multiple modules. This architecture has been the go-to functioning model for many years and countless applications have been successfully built as monoliths.

The advantages of monolithic architecture

  • Starting a new project and developing it is simpler using monolithic architecture
  • It is much easier to test a structure that is a monolith
  • Components like frameworks, templates or scripts can be easily applied 
  • Deployment is very simple. All you have to do is paste the previously prepared application to the server

The disadvantages of monolithic architecture

Like any solution, monolithic architecture has its drawbacks. Here’s a list of some disadvantages:

  • A large code base can be significantly harder to understand
  • The Integrated Development Environment can become overloaded, and size may also slow down startup time
  • Every element is closely related and dependent on the others, so it is difficult to change to a new or advanced technology, language, or framework
  • Updating can be a challenge as it redeployment of the application
  • Problems with scalability, because each element has different resource requirements
monolithic architecture vs microservices
Make eCommerce ready for changes with microservices architecture >

The advantages of microservices architecture

One of the most popular arguments for getting into microservices architecture is that it can make the software easier to maintain by decomposing and decoupling it into smaller units. 

Considering monolithic architecture vs microservices, most monoliths are not well modularized and their features are not easy to test (unit testing, behavioral testing). It becomes difficult to deploy the changes because of the tight-coupling between the modules it’s quite easy to break some other features.

The advantages of monolithic architecture vs microservices

It’s worth noting that the problems with monoliths can be fixed without major re-architecting of your application. For example, Shopify started as a startup with a Ruby on Rails base and now they’re perhaps the only force in the world to compete with Amazon.

Ruby on Rails is well known for its flexibility with a “convention over configuration” approach that has just a few strict rules on designing the application. You can get results fast and it is a fun and productive way for developers to work. In fact, startups often choose Rails because they need to be fast, validate, and pivot. In essence, if Shopify had started with microservices architecture, complex deployment schemas, and complicated CI/devops processes, they may have failed.

Monolithic architecture is the easiest to implement. If no architecture is enforced, the result will likely be a monolith. This is especially true in Ruby on Rails, which lends itself nicely to building monoliths due to the global availability of all code at an application level. Monolithic architecture can take an application very far since it’s easy to build and allows teams to move very quickly in the beginning to get their product in front of customers earlier. 

Maintaining the entire codebase in one place and deploying your application to a single place has many advantages. You’ll only need to maintain one repository, and be able to easily search and find all functionality in one folder. It also means only having to maintain one test and deployment pipeline, which, depending on the complexity of your application, may avoid a lot of overhead. These pipelines can be expensive to create, customize, and maintain because it takes concerted effort to ensure consistency across them all. Since all of the code is deployed in one application, the data can all live in a single shared database. Whenever a piece of data is needed, it’s a simple database query to retrieve it. 

Source: Deconstructing the Monolith, Shopify blog

Why do microservices work well for large projects?

Unlike monolithic architecture, which consists of one element, microservices are created by cooperating services. Each of them is a small-scale service that performs functions from a single business area. Microservices were born out of SOA (Service-Oriented Architecture), as a solution to the challenges associated with monolithic applications. The division of large projects into small ones has gained more importance, especially among developers, and the impact of microservices on eCommerce is significant. One of the main reasons why the independent modules met with positive reception is its ability to manage the API and perform specific tasks. Microservice architecture divides services into small, autonomous elements, each with its own independent function. 

Why has microservices gained such popularity among key players like Zalando, Netflix, and Amazon? Primarily, a departure from monolithic architecture has made it possible to relieve programmers. They no longer need to maintain large projects. Thanks to microservices, they can focus on small parts of independent projects. It is also easier to introduce new people to the project. It is not necessary to familiarize them with the entire monolith, but only a small part of it.

“When businesses come to us looking to replace their monolithic loyalty program architecture, their most common reason for wanting change is that their technology is ‘limiting’ their ambitions and capabilities.

Monoliths don’t necessarily limit businesses in terms of features. You can build any feature you like with enough time and resources. They limit the way that brands can interact with customers and offer more modern experiences. And the speed at which they can do it.

A headless approach, using microservices exposed through an API, lets companies deliver those experiences faster and allows them to evolve as the relationship with customers develops over time.”

Cezary Olejarczyk, CEO, Open Loyalty

The keys to a successful microservices build

I’d risk the statement that a successful migration towards microservices architecture depends more on the proper organization structure than any other factor. In my recent interview with Kelly Goetsch, we concluded that one of the key factors for changing the architecture is to have a project sponsor with a budget and vision. On top of this, you then need the proper team structure. Only those factors – combined – will let you reach full speed.

We can also say that successful architecture stands on three legs: a proper domain model, people, and an operating model.The structure of the people, divided into the teams and their operating model differs from company to company, product to product, project to project. However, I really liked the observation made by Sam Newman in his book “Monolith to microservices” that the best structure is the one which gives the team full ownership. Usually, the ownership means the independent deployability of the services the teams are working on.

“Adding more people will only continue to improve how quickly you can deliver if the work itself can be partitioned into separate pieces of work with limited interactions between them”

Sam Newman, Monolith to Microservices – after the “Mythical Man Month”

This means that, to perform well, the team has to have full competences (developers, design, and DevOps) to build and ship new features to production. They should not need to communicate with different structures. Of course, they need to fulfill the API service contracts and interfaces. Other than that, they should be able to experiment and ship new features solely on their own.

Monolithic architecture vs microservices comparison chart

What architecture should you choose for your business? We’ve broken the decision down into the different areas that you might consider and assessed each one in both scenarios. 

Area Monolith architecture Microservices architecture
Deployment This architecture allows you
to deploy once and then
customize your solution
based on current changes.
But if something goes wrong,
the whole project will break
Deployment is a complex
process in microservices.
Each microservice must be
implemented separately, which
extends the implementation
process. If something
goes wrong, only one
microservice will be damaged,
and it will be easier to fix it.
Maintenance Maintenance in a monolithic
architecture requires an IT
team that specializes in multiple
platforms, like Pascal, .NET, Java, or
DB2. Finding errors and making
changes takes a lot of time in the
monolith. However, testing itself is
simple and will be done in one go.
Maintenance in microservices
is faster than in monolith.
Smaller services are also easy to test,
saving programmers time.
Over time, it increases
efficiency and saves money. 
Reliability If it comes to reliability, the monolith
has no chance against microservices.
If something goes wrong in
monolithic architecture, it can stop
the whole structure. Meanwhile, in
microservices architecture,  breaking
one service will not cause critical
problems in the overall
Microservices are stable and
mostly reliable. Breaking one part
only affects that element, while the
others remain intact. Such flexibility
allows for a fast pace of development
and the introduction of changes in
one function without interfering with
Scalability Scalability in monolithic
architecture is difficult to
achieve due to the size and
scale of the structure. This option
is hard to upgrade.
In the case of microservices,
scalability is much easier because
we can scale only those parts that
require more resources.
Development The development of monolithic
architecture takes a little bit longer
than microservices. This is due to the
need for a parallel operation on the
same code by all teams. 
Microservices guarantee fast
development. Teams don’t
have to work in parallel, as they
do in monolithic architecture,
because each application can
be delivered independently. 
Releases A monolith is a one-piece structure
which cannot be separated into
smaller elements.That is why
everything must be ready before
release. Potential delays in the work of
the team will impede the entire project.
Due to the structure, microservices
allow for faster releases of new
Cost Monolith architecture is more
affordable and faster to develop,
but each case must be considered
individually. For businesses, monoliths
involve one huge investment, which is
a higher risk and a bigger strain
on the budget.
Microservices are usually more
expensive, and the whole
development takes more time
than in monolith. But in the long
run, they can cost less, if we count
developers’ work time in
the long-run will be less
than with a monolith. 

Monolithic architecture vs microservices: Which to choose for your company?

Like everything, these two technologies both have their advantages and disadvantages. Monolithic architecture is a solid solution for simple eCommerce applications or blog platforms, especially when ongoing changes and development are not predicted. Microservices have grown to become a better fit for complex applications and are the modern solution in a time when constant improvement and development of sites and services is the norm. 

Microservices Architecture for eCommerce eBook. Download for free >

*This article is an updated and augmented version of a piece originally written for Divante by Ola Mazur and published in 2019.

Published January 14, 2020