Monolith vs Microservices: choosing the right architecture for your organization

When Monolith is better than Microservices

Despite its name, a monolith isn’t an outdated architecture to leave in the past. It’s merely considered to be the traditional way of building applications as a single and indivisible unit. As you add new features and changes to the same code base, it will grow over time. The structure lends itself well to small teams and offers advantages like less operational overhead and focus. Monolith usually has a server-side application, front-end user interface and a single database. All functions are managed and served in one place, and that leads to big benefits.

Monolith Architecture: Advantages and Benefits

A monolithic application is easy to develop, test and deploy. After deployment, you simply adjust it based on ongoing changes. While this means there is a single point of failure during deployment, this is not inherently a problem for most organizations. With everything going through the same application, cross-cutting concerns such as logging, handling, caching and security are easily addressed because memory, space and resources are shared. The monolithic approach also comes with performance advantages, since shared-memory access is faster than inter-process communication (ICP) for example.

Typical scenarios for starting with a monolith are:

1. Your team is small and at a founding stage. A starting team of about two to five members will find a monolith architecture ideal to focus on.
2. You’re building a proof of concept. New products will pivot and evolve as you figure out what will be useful to your users. For this, a monolith is perfect as it allows for rapid product iteration.
3. Foreseeable scale and complexity. When your application doesn’t require advanced scalability and the complexity is manageable, then a monolith architecture is the best road to go down.

The need for business agility

Today, global commerce has grown exponentially as each new channel creates a whole new market. Customers worldwide are becoming more demanding, looking for inspiring shopping experiences on all channels and on all devices. Personalization, high service levels and fast delivery are just a few of the challenges merchants are currently facing. Organizations leading the way want to be able to adapt quickly.

Monolith Architecture: Disadvantages and Challenges

In this fast-paced, fast-growing market environment, the shortcomings of monolithic applications architecture become apparent:

1. High degree of software complexity. A successful application is constantly evolving to keep up with changing demands. As a result, these monolithic applications can become harder to maintain, let alone be completely understood by the developers working on it.
2. No responsibility. A large application runs the risk of being perceived as a black-box that nobody wants to take responsibility for. Called a “big ball of mud”, this can lead to disincentive for individual developers to touch anything.
3. Lack of agility. With monolithic applications, teams are usually structured according to their individual functions, such as frontend, backend or database. When a request is made that affects all of these teams, the resulting projects can take a great deal of time because tasks have to be shared by and among multiple different team members.
4. In a centralized architecture, the individual parts are highly coupled and depended on each other. This results in a single point of failure that can bring down the entire system.
5. Inefficient testing. Because of the single points of failure present in these applications, comprehensive and repeated testing becomes crucial. If only one small part of the application is changed, it needs to be tested in its entirety – also with respect to features that have nothing to do with the original changes.
6. No specialization. In a highly coupled application, individual components are usually treated equally with regard to the kind of the number of resources they have access to – regardless of a certain part needing more or less CPU, RAM or disk I/O.
7. Scaling issues. With most monolithic applications, scaling horizontally is the only option, which in turn creates many other issues. Quite understandably, companies facing the need to move faster and drive innovation are trying to find ways around these restrictions.

Microservices Architecture: Advantages and Benefits

A microservices approach encapsulates each business capability into individual services. Every application process functions as a separate, loosely coupled service with its own logic and database. Updating, deployment, testing and scaling happens within the scope of each service. While microservices don’t reduce the complexity of a system, they do make complexity more visible and manageable. Depending on need, the same service can be reused in several business processes and over a myriad of channels and touchpoints. By standardizing on contracts via business-oriented APIs, users don’t notice any changes made in the backend.

With advocates like Netflix, Airbnb, Google, Disney and Amazon, microservices have built momentum and mind share. Typical best practices for microservices architecture are:

• Clear domains. During the designing phase of the microservices, their boundaries should be clear so can align them with the business capabilities. In domain-driven-design, this is also known as bounded context. This allows you to use the language most efficient for each domain.
• Extreme requirements. Microservices can deliver maximal agility, speed and scalability. Applications with extreme requirements are best served with a microservices architecture that can cater specifically to each service.
• Expertise in microservices. To start with microservices, you’ll need a team with some experience in microservices or distributed design. DevOps and Containers experts are advised since these concepts are tightly coupled with microservices.
• Complexity. If you plan a large application with multiple modules and user journeys that lead to high complexity, a microservices architecture is the best fit. It makes scaling and adding new capabilities much easier.

Microservices Architecture: Disadvantages and Challenges

By the big names that advocate for microservices and the typical starting points you can see that the microservices architecture is not the silver bullet. Don’t choose for microservices just because you see other organizations having success with them. The microservice approach is neither suited for every business context nor does it result in development and maintenance complexity magically vanishing.

Step back from the idea that microservices make your e-commerce a no-brainer and consider the following microservices disadvantages compared to the monolith approach:

• Cross-cutting concerns. Each microservices has to deal with a number of cross-cutting concerns like logging, metrics, health checks, externalized configuration etc. It’s likely you didn’t anticipate these fully at design time. You could accept the overhead of separate modules for each concern. Or, alternatively, encapsulate these concerns in another service layer through which all traffic gets routed.
• Higher costs. Microservices come with a higher workload for operations, deployment and monitoring. This comes with higher operational overhead. As services communicate with each other, the resulting high number of remote calls can lead to higher costs associated with network latency and processing. And with each microservice deployed independently and requiring its own runtime environment and CPU, there is also a higher resource demand.
• Organizational change. Each team has to cover the entire lifecycle of a microservice to be completely independent. From design and conception, technical decisions and implementation to running operations and monitoring. That calls for organizational changes, such as moving competences and power from the managers to the teams. A DevOps culture, that also emphasizes automation practises, is strongly advised to successfully adapt a microservices approach.\

In our blog How microservices enable business agility and e-commerce success you can read more about the background, challenges and advantages of microservices.

One approach does not fit all

As a service architecture, the microservices architecture has become increasingly popular. But your own business context, evaluated against the above pros and cons, is essential to deciding if you should start with monolith or microservices. For a lightweight application, a monolithic system often suits better. For a complex, evolving application with clear domains, the microservices architecture will be the better choice.

The main takeaway? Don’t focus entirely on the architectural approach, but on the specific needs of your organization. That will help you to clarify and cut down on any unnecessary complexity and lead the way forward as a technical decision maker.