Monolith vs. Microservices: Why Companies Switch Back and Forth

Microservices are no longer a trend, but a leading architecture. As one of the earliest adopters of architecture, we have been watching it progress from an emerging trend to a leading approach in software development. The list of companies who adopted microservices grows every year – Uber, Netflix, Payoneer are among the most prominent ones. 

However, does this mean that a monolithic approach is no longer relevant? Definitely no. It’s a default development architecture, intuitive and easy to conceptualize. Though it is no longer thought to fit for all projects, monolithic architecture is still the best choice for many concepts.

In this article, we’ll cover the main advantages of monolithic architecture vs microservices along with their respective challenges and use cases. 

What is a monolith architecture?

A monolithic architecture is a traditional approach to software development. The application consists of three main layers: user interface, business logic, and data access. These components of the application are governed by the same hierarchy, not as standalone services. The monolith meaning boils down to having a single codebase and data layer for the entire application. 

User interface

A component of the architecture that is responsible for the interface of the software, its interactions with users, and visible functionality. There are many approaches to building UI, but the most common one is Model-View-Controller. 

Model stores the information that the user interface will display. Model is responsible for storing users’ personal data, account details, and settings. Often, this data is stored in the field text object for faster access, and not in the database. 

View is responsible for the display of the model’s data. It controls the position of the data on the screen, its style, and interactions with the user. View renders users’ controls, collects user inputs, reacts to actions, and produces the output. It basically manages the data in the model. 

Controller is responsible for bringing the two components together. It oversees the view’s action, sending update requests, and managing data storage. If a piece of information needs to be transferred to the model, it’s the controller’s job to take care of it. 

Business logic

This component of the monolithic architecture is responsible for interactions between business objects, and methods in which they are handled, and updated. Business logic describes the route for accomplishing particular useful tasks. 

Business logic handles actual business objects – inventories, loans, accounts. The business logic of the application defines if the function is useful or not. It’s an expression of business goals. To get a better idea, let’s take a look at some examples. 

• A user should receive a notification after finishing the order;
• All users who are registered on the website should be able to access a demo-version of the service. 
• Financial transactions are processed with a particular commission. 
• Users need to validate their registration via email.

These specifications represent business logic because they connect technical specifications to tangible business and financial objectives. 

Data layer

The data layer defines the rules and methods used for storing, retrieving, processing, and transferring the data. It includes a database and a database management system. This component of a monolithic architecture is designed to supply all the other components with information. 

What is a monolithic data layer? It describes processing operation, criteria for data usage, its state, and security. This component should perform in a stable and secure way. Issues with the data layer architecture will lead to decreased performance, data leaks, inability to process a huge number of requests, and store necessary data.

When is a monolithic architecture used?

• A single team is working on the project for a long period of time;
• The application is not big and easily fits into three main layers;
• The team is small, and there’s no way of letting developers specialize, building a particular functionality;
• The speed of delivery and low costs of the project are a priority.

What is the advantage of monolithic architecture over microservices?

• Intuitive during the development process: the application is seen as a whole and broken down only into essential layers; there’s no need for excessive modulation;
• It’s a standard approach to software development. Most tools, frameworks, and educational information are still tailored to monolith projects;
• Can be built by a small team.

Disadvantages of monolithic architecture

• Coupled functionality: all features and layers of the application are tightly connected; if there’s an issue with one component, the entire codebase can be compromised;
• The code has a lot of dependencies and integrations which decreases its reusability: features often can exist only in combination with others;
• Decreased scalability: when developers introduce a new feature, they need to modify the entire structure of the application;
• It’s not compliant with a Single Responsibility Principle: a rule by which every single component should be responsible for its own execution. Each part should be included in an independent module or class. A monolith architecture doesn’t isolate features, so there’s no single responsibility. 
• Complicated testing and maintenance. A monolithic architecture needs to be tested and updated as a whole. Instead of just taking a look at one feature, developers always have to come back to the entire codebase and see if there are no unwanted changes – a major difference between microservices vs monolithic. 

Microservices architecture

Microservices are a response to issues created by monoliths. The code is broken down into independent modules, where each feature is a standalone service. Each component is dedicated to performing a single task. 

The main characteristics of microservices are the following:

• microservices are independent services that communicate with each other;
• developers can create microservices independently and even use different tech stacks;
• microservices are organized around business processes;
• microservices are highly isolated: when it’s time to update service, changing only one feature is enough – the entire infrastructure will not be affected. 
• developers are free to use different hardware and databases depending on the purpose of the service. 

Microservices are small by their definition, but they can function as independent tools and even be deployed on the server. To create a microservice software, developers need to decentralize the functionality, breaking it down into dozens of standalone modules. There’s no clear hierarchy – all services can act independently; 

It’s common to use Cloud and serverless computing for microservice architecture. Microservices are often enclosed in containers for high isolation and development ease – Docker is a leading solution. 

When are microservices used?

• The platform has to be highly scalable, expand to different niches and markets;
• High-tech innovations lie at the core of the product. The software uses AI, ML, IoT, and other technologies regularly;
• A team of developers uses different tech stacks and tools, and there’s no possibility to hire experts with unified expertise;
• The company wants to build clean, readable code right away and avoid technical debt;
• The company has human resources for microservices development: the architecture requires several developing units that will work independently on a microservice;
• The company prioritizes long-term gains over short-term benefits. 

What is the difference between SOA and microservices?

The idea of breaking the architecture down into components is not new. Before that, we had service-oriented architecture, an approach similar to microservices, but with a few key differences.

A service-oriented architecture is a modular approach to software development. It’s composed of loosely coupled components that communicate with each other via protocols. Judging by the definition, SOA can at first seem identical to microservices, but it’s not the case. 

• Every service in SOA is determined by a particular business function. This is the foundation for several differences with microservices. For one thing, business tasks are of different sizes: checking an order is smaller than creating a business agreement. So, services in SOA range in complexity.
• Granularity: SOAs can perform not just one, but multiple tasks. You can reduce the number of components, but on the other hand, if one fails, the system won’t function as well.  
• Components share information: microservices are based on the logic of sharing as little as possible, whereas components in SOAs reuse the same code. Services in SOA are generally slower performing, but take less time to build.

Is SOA monolithic? No, because the architecture is broken down by modules. In a way, it could be defined as a combination of certain principles of monolithic architecture and microservices.

Advantages of microservices

Microservices were created as an alternative microservices vs monolith, so it’s no wonder that the advantages of the architecture are directly connected to the disadvantages of a monolith. A lot of things that weren’t working in the traditional method got fixed with microservices. 

• No need to understand the entire codebase: developers involved in the process don’t have to learn the specifics of every single feature of the software. It’s important for big and scalable projects, where teams can’t possibly keep track of thousands of functions. 
• Isolation: microservices communicate with each other, but aren’t dependent. If one service fails, it’s possible to expand the functionality of the left ones or add a new service. In this architecture, other components can pick up what some left off. 
• Scalability: microservices grow quickly and easily. Developers can integrate a new service into a platform at any time and assign some of the popular protocols like HTTP or gRPC.
• Efficiency: developers no longer have to stick for the same solution for the sake of keeping a unified tech stack. In microservices, they can pick technologies that fit best the needs of particular services, combining many languages, frameworks, and integrations. 
• Smaller, more manageable teams: developers create units of 3-5 people, where each group has full responsibility for 1-2 microservices.
• Well-suited for outsourcing projects: product owners can invite outsourcing teams to join a project at any stage because there’s no need for a new vendor to understand all the complexity of existing functionality. 

Disadvantages of microservices vs monolith 

When monoliths and microservices are compared, the latter is usually seen as a definite winner. That’s a generalization, though. Microservice architecture is great, but it’s by no means perfect. Let’s take a look at the challenges that most teams face when adopting microservices. 

• Teams need to change mindset: changes need to be implemented not only at the level of development but also management, communication, and onboarding;
• The functionality needs to be modularized: before building a service, developers need to figure out how to break the overall functionality down into modules. If done wrong, the software won’t function properly;
• Teams need to communicate well: although microservices development implies a lot of freedom, it also requires teams to issue regular status updates and keep track of overall workloads; 
• Different tech stacks make automation challenging: you need to find tools that fit different languages and runtime environments;
• Communication and data transfers between microservices require additional computing power. 

Microservices require a new approach to development and process organization. By adopting microservices, the company also signs up to a shift at work processes and priorities. Establishing a system in the in-house team can be challenging – although it’s not as much of a problem if you cooperate with off-shore developers. 

Advantages of microservices and monolithic architecture

Both microservices and monolithic architecture have their respective strengths and weaknesses, but most importantly, the two architectures choose different approaches to every step of a product development process. Let’s take a look at the main distinctions between the two architectures and their implementation. 

Ease of development

Monolithic architecture is easier to develop in the first stages. Developers don’t have to break the functionality down into modules or think about how services will communicate with each other. The process of development naturally flows from one feature to another, keeping all components united.

However, in the later stages, a monolithic application becomes hard to control. As the codebase grows, more features need to be updated. Making changes to a single code element becomes problematic because it’s associated with too many functions. 

Microservices are challenging to develop in the first stages. Not only a team needs to think about decomposing the functionality, but they also need to make crucial shifts in team’ structures. 

As the project scales, however, the team is rewarded for initial struggles. Comparing monolithic application vs microservices, microservices are easily tested and updated. Developers can add a new piece of functionality at any moment. They are free to experiment with tech stacks and choose technologies that fit particular features the best. 

Costs

A monolithic architecture is a cheaper solution in the short run. You don’t need many units to get the project running. The initial stages of the project are faster than with microservices, and you end up saving a lot of time. When it comes to building a small tool, a monolith is a more cost-efficient approach.

Microservices, however, are undoubtedly better at the enterprise level. Sure, there’s no need to decouple a small application, but if you are building an ambitious platform, decomposition is a must. Large platforms are made up of thousands of features, and handling them in a single codebase will be problematic. With their isolation and flexibility, microservices allow speeding up the project’s scaling and development even after multiple iterations. 

Time expenses

With a monolithic architecture, a project is faster in the first stages. Developers need to do less research and planning, and there’s no need to plan out the communication between individual services or isolate each component. What does monolithic mean for bigger projects? Usually, difficulties in scaling and growth: when the number of features grows, each next update takes more time.  

Microservices represent the opposite time distribution curve. The first stages take more time due to necessary organizational changes and analysis, but in the long run, big microservice platforms are faster than monoliths of the same size. 

Development skills

Building a monolith is difficult because an entire team heavily depends on the expertise of individual members. Everybody needs to understand exactly how the entire codebase works, which is why replacing a developer can be problematic. The main challenges of monolith development derive from a united monolithic structure.

• Finding a team of expert developers with a corresponding skillset. Monolith requires a single tech stack, which is why all developers have to be experts in a particular technology;
• On-boarding new developers: familiarizing a new team member with the complexities of the architecture will take a lot of time;
• Maintaining documentation: recording all the dependencies and integration will take a lot of time and might become a distraction. 

Microservices’ main difficulties are associated with the process of combining standalone services into a single process. The independence that the architecture grants to the development team is great – at first – but later on, some challenges might arise. 

• Having a bigger picture: developers need to check their product requirements regularly and test microservices, both standalone and together. Otherwise, they risk ending up with a list of services that work well independently but together perform poorly.
• Navigating conflicts: Independent approaches, chosen by different units, might contradict with the overall application logic. If a project manager doesn’t catch these differences early on, everything could end with an incohesive project and internal conflicts. 
• Securing microservices: setting up fast and safe data transfers should be a continuous priority. Developers should always check the safety of each service individually as well as their integrations. 

Transition

It’s not common for microservice teams to switch to the monolithic architecture. Usually, this approach is chosen right at the beginning of development. The opposite scenario, however, is quite common.

Companies shift to microservices when they need to scale their platforms. For Netflix, the decision to move to microservices was determined by a serious mistake that led to prolonged downtime. The company moved to AWS Cloud and restricted their entire platform as microservices.

Now, the team managers more than 700 services, where each one is responsible for a narrow task. This allowed the company to be more flexible in innovation adoption and testing. 

Maintenance 

When you maintain a monolithic structure, you need to focus on keeping the entire codebase clean and tech-debt free. Developers need to ensure that all features work well and see if there aren’t any hidden bugs from previous updates. The goal is to make sure that changes in one feature didn’t impact the product negatively.

With microservices, developers are focused on managing containers (Docker, Kubernetes). Both microservices and monoliths can use continuous deployment and integration tools. 

Data storage

Monolithic architecture handles data storage and processing at the level of a data layer. Developers build a single data layer for the entire application. It’s faster than configuring separate storage but has a crucial downside. If a database fails, the entire software will experience performance issues. 

In microservices, each service is responsible for managing its data. Two components cannot share data storage. Services cannot have direct access to each others’ private information. This approach allows developers to avoid unintentional dependencies between services: if two components were to work with the same storage, they would inevitably end up affecting each other. 

This way, even if data storage of one service is broken, all the others are intact and can work smoothly. If one component fails, others can fill it, using their own database.

Use cases

Monolithic applications are a go-to solution for small teams who work under time constraints and a limited budget. Monolith, with its fast first stages, allows accomplishing a lot early on, even though its; no always a sustainable decision long-term. Here is the list of projects that fit the concepts of monoliths. 

• Small services: if you are building a small app, there’s hardly a relevant reason to break it down into even smaller components;
• Minimal viable products: developers can build their proof of concepts as monoliths because it’s faster and cheaper. 
• Enterprise sites: web pages with a sole purpose of providing information about the company don’t require a sophisticated set of features. They can be easily developed as a monolith with no future scaling issues. 

Microservices, on the other hand, tend to be more demanding in terms of costs and time at the first development stages. They represent a long-term investment: companies who have adopted microservices tend to save a lot of money and time once the project scales. This leads to the following use cases for the architecture. 

• Scalable platforms: if you are building a complex web or mobile application that covers multiple niches, works with many markets, and will host millions of users, microservices will provide you an opportunity to scale. 
• You have a big team at your disposal. If you are not limited to using only a small in-house team but can hire new people or bring in outsourcing experts, you will easily implement microservices. 
• Cross-platform apps. If your solution is designed to support web, desktop, mobile, you need a reusable codebase. For cross-platform solutions, microservice architecture is a more efficient choice. 
• Real-time applications. If the software handles a lot of data and has to process tens of thousands of concurrent user requests, microservices might be better suited for the task. 
• Large management platform. If you are building a complex custom business platform, like CRM or ERP, microservices will allow you to accommodate large functionality in isolated containers. 

Companies using monolith architecture

Despite the growing trend of stitching to microservices, many companies prefer scaling their monolith architecture. They also have a solid motivation to do so. Let’s take a look at the most popular examples. 

Facebook

Facebook chooses to maintain its unified infrastructure instead of breaking the functionality down into modules. Such a solution allows the team to simplify their business logic and have a bigger picture of pf platform functionality. The team uses a lot of custom developed tools in its development, so there’s no need to use different tech stacks. 

Also, Facebook has to prioritize safety due to high data breach risks. Transferring information between microservices can potentially jeopardize the user’s sensitive information. So, Facebook held on to its PHP monolithic platform rather than going through with refactoring. 

Segment

Segment, a company that creates big data and data-driven analytical software, isn’t well known outside the data analytics industry. However, we included them on the list because they represent an interesting case of moving from microservice to a monolith. 

The data analytics industry needs to handle a lot of sensitive information and process multiple requests. Safety and reliability is a priority. When a product consisted of 140 services, the overhead of communication and management was getting too big.

Each service needed to handle a separate queue of requests, which landed a hit of application performance. The team switched to monoliths to build a unified product and bypass the necessity of constant back-and-forth communication. 

Reddit

A website was created in the early days of the Internet when microservices weren’t a thing yet. The company has been using its old codebase up to now with updates of interface and functionality, but refrain from refactoring its architecture completely.

Reddit’s strategy is to make changes one step and time without making radical investments. It’s a good example of smart updates that can let teams maintain their old architecture while remaining intuitive for modern users. 

Companies using microservices

Switching from monolithic to microservices is a lot more popular than vice versa. The reason is simple: monolith is a well-known and mainstream architecture, while monoliths are fairly new.

Also, how businesses grow at an incredibly fast pace, and a traditional development approach just can’t keep up. Let’s take a look at the transitions that paved the way for architecture adoption and analyze teams’ motivations. 

Amazon

Amazon switched to microservices to accommodate its large technological infrastructure. The company has been at the forefront of IT innovations, especially with its Amazon Web Services. It wouldn’t make sense for such a progressive team to stick to an outdated architecture. A transition to microservices was done together with a switch to the Cloud.

The team cleaned up the codebase and moved it to the decentralized servers. They also built Amazon Web Services and started actively adopting open source tools. For Amazon, the adoption of microservices was the start of embracing a new approach to development. 

Uber

In the beginning, Uber’s core features were the search for drivers, basic communications, order processing, and payments. It only served a small community of users – the app was available only in San Francisco. However, when the company started expanding to other cities, the number of features and requests grew quickly. 

Why microservices? Uber’s team needed to release new updates at an incredibly fast pace, and a monolith, with its strategy of all-at-once development, couldn’t be sustainable. In microservices, you only need to deploy an edited service. 

Switching to microservices allowed the team to quickly release new updates and more changes, and reduce the number of bugs. Other advantages of microservices were cutting costs on development services and decreasing computing power. 

eBay

eBay switched to microservices in 2011. At that point, the company was already a leader on the market, with 87 million active users and 250 billion daily searches. The change to microservices was a bold move because the stakes were high.

The first step of adopting microservices was to decouple the functionality and divide the database. Even the search functionality had to be decomposed into separate services. The application created new function tiers and changed its approach to building new features.

In order to update the functionality, the company now only has to connect a new function to an appropriate tier. There’s no need to re-update the entire large codebase. 

Similarly to Amazon, eBay combined its transition to microservice with an overall reevaluation of the development method. The company made a move towards embracing open source solutions and Cloud computing. 

Comparative table

Conclusion

Monolithic architecture is a suitable choice for smaller projects that need to be delivered quickly and on a budget. It can be easily created and maintained on a small team, and the intuitiveness of the architecture allows accomplishing a lot early on. 

Microservice architecture is built with scalability in mind. It’s a great fit for big platforms, complex enterprise applications, and evolving businesses. If we are talking about an ambitious product with rapid growth in mind, this architecture will simplify the growth process. 

To choose between the two architectures, contact an expert development team who will analyze your concept and pick the best-fitting solution. Our developers work with both architectures and are well aware of the complexities of both. There’s no obvious winner – everything depends on the project.

You can leave us your project’s concept on our Contact page and our developers will discuss with you the most suitable architecture and development approach for your product.