Monolithic vs Microservices Architectures
The software industry is demanding that development companies become more agile, more flexible, and increase the velocity of their development efforts. To meet these demands, many companies are turning to microservices as an architectural design choice. No longer are software monoliths able to meet the fast pace and competitive nature of the industry.
While microservices can transform and accelerate the way companies approach development, they are not the best fit for every application, or organization. Microservices shine in scenarios where companies have embraced agile, DevOps, and CICD, and are able to decentralize decision making to help empower small development teams. Each company needs to evaluate their architectural design choices to determine which would be the best fit for their needs.
Through this article, we hope to provide you with ample information to help inform and guide your decision-making process. While we provide a monolithic vs microservices comparison here, a more thorough understanding of microservices architecture is recommended. As such, if this is your first time delving into distributed architectures, we suggest you start at this thorough overview of microservices.
What is a Monolithic Application?
A monolithic is an application that utilizes a monolithic architecture and is the traditional model for designing and developing software. The monolithic application consists of a single self-contained unit in which all code exists in a single codebase, and in which modules are interconnected. At deployment time, the entire codebase is deployed, and scaling is achieved by adding additional nodes.
Why Are Companies Turning Their Backs on the Software Monolith?
The truth is, not all companies are. In fact, in some situations a monolithic application is the best choice. When applications are small, adopting a distributed architecture like microservices can result in an unnecessary increase in complexity and overhead. When companies are setting out to build an application, or provide a proof of concept, it is important for them to evaluate which architectural design style will best meet their needs. While small, monolithic architectures are simple to develop and deploy, easy to understand, and simple to scale, test, and debug. It is not until monoliths grow large, that the case for microservices is made.
As a monolithic application grows, its lack of flexibility and modularity become its Achilles heel. The issues of monoliths that drive organizations to microservices are:
Utilize a Single Development Stack
Because of a monolithic applications tight coupling, they can only utilize a single technology stack. This creates issues with flexibility, as developers are not free to choose the best programming language or data store that features the functionality that best suits the need of a given process. As monolithic applications grow, the data that is stored can be very heterogonous with varied processing requirements.
Difficult to Understand
Tight coupling and the many interconnections between modules in a monolithic application can result in a codebase and interdependencies that are difficult to understand in full. New developers will need to have a good understanding of how the entire application fits together. This can make the on-boarding of new talent a daunting task.
Resiliency, Fault Tolerance and Isolation
One of the major disadvantages of a monolithic application again is the result of tight coupling and low cohesion. Changes to the application present a high-risk situation. Because a monolith is a single unit with many inter-dependencies, a bug in one part of the application can cause issues in another part of the application, or even bring the entire application down. Due to the possible chain of faults that can occur, it is also difficult to isolate the source of the issue. As a result, developers need to be sure to test each module, because it may be impossible to predict the outcome of even minor changes to the codebase. Recovering from failures is also not an easy task. Once a bug is isolated and corrected, the entire application needs to be rebuilt and re-deployed.
Large monolithic applications can take very long to develop and deploy, oftentimes in the range of months, or years. A slow deployment velocity can result in a long timeline for users to receive new features, product hitting market late, or falling behind competitors that have embraced a nimbler development approach such as microservices.
These are just some of the issues that organizations encounter with monolithic architectures. There are many more issues related to their lack of scalability, declining quality of code, and lack of flexibility that arises from large development teams, and traditional development methodologies like waterfall that are commonplace with monolithic applications.
What Are Microservices?
Before we dive into how microservices address the issues of monolithic architectures, we need a solid understanding of what microservices are. Microservices are relatively new, and there is no agreed upon definition as to what makes a microservice. However, all microservices share some commonalities:
- Services should communicate over a network with lightweight technology agnostic protocols.
- Each service must be independently deployable.
- Services should be small in scope and focus on a single business goal.
- Each service can leverage a different technology stack.
- Microservices should be failure resistant and fault tolerant.
Many people first introduced to microservices confuse with a service-oriented architecture (SOA). While they do share some similarities, they differ on some fundamental levels. If you are interested in learning more about microservices and SOA, read our article on the differences between microservices and SOA.
Microservices Solve Monolithic Issues
Now that you have a good understanding of what microservices are, let us dive into what issues they address and how they differ from monolithic applications. Earlier we discussed many of the issues that develop as monolithic applications increase in size and scope. We will revisit the same pain points and highlight the features of microservices that mitigate these issues:
Because microservices are loosely coupled and independently deployed, developers are free to choose a different technology stack for each service. This provides an enormous amount of flexibility, enabling the best programming language and data store to be selected for the functionality required by the service.
On-boarding of New Talent
Microservices are much smaller in size and scope than an entire monolithic application. Each service can be managed by a small cross-functional team whose sole focus is on that service. Also, services do feature interdependencies, so there is no need to understand the scope of the application in full. As a result, on-boarding new talent is easy since services are much easier to understand.
Resiliency, Fault Tolerance and Isolation
Microservices do not share the same issues with monolithic applications related to resiliency, fault tolerance, and fault isolation. Because microservices possess loose coupling, it is not likely that a bug in one service, will cause an issue elsewhere in the application. This also provides the benefit of making it simple to isolate faults to a single service. Once the bug is fixed, developers are free to redeploy just the service where the issue occurred.
Microservices are can be deployed very quickly. Small dedicated teams can focus on making changes to a service and deploy without having to worry about changes effecting other parts of the application. Companies benefit further, when they apply agile, DevOps, and CI/CD to their microservices initiative, and automate functions such as testing, monitoring and deployment.
Microservices vs SOA in a Nutshell
|Size||Single self-contained unit||Very small function-oriented independent services|
|Granularity||Tightly coupled with low cohesion||Loosely coupled with high cohesion|
|Ease of Deployment||Requires recreating and redeploying entire application||Each service can be built and deployed independently|
|Remote Call Overhead||Low/None||High communication overhead due to increase in remote calls|
|Speed of Deployment||Very slow deployment speeds||Rapid and continuous deployment|
|Persistence||All services in a monolithic application share data storage||Each service is free to choose its own data storage|
|Ease of On-Boarding||Can be difficult to on-board new developers||Easy to on-board new developers|
|Polyglot Programming||Utilize a single technology stack||Can utilize a different technology stack per service|
|Communication Method||Language-level or procedure calls||Communicates via API layer with lightweight protocols like REST|
|Scalability||Horizontally scalable, can be very challenging to scale as application becomes larger||Vertically and horizontally scalable through use of containers and the cloud|
Should You Choose a Monolithic or Microservices Architecture?
Each company needs to make its own assessment in order to answer this question. As we have mentioned before, in some cases a monolithic application is still a great choice. Microservices do not align with every company’s culture, processes, and application. Nor are they some magical fix-all that can be adopted without careful planning and consideration.
Whether you are trying to plan the design of a new application, or looking to decouple a monolith, it is important to make an informed decision. To assist you in your endeavor, here are some additional resources on microservices:
- Why should I choose microservices?
- How do I get started with microservices?
- What are the advantages of a microservices architecture?
- What are the disadvantages of a microservices architecture?
- What microservice pattern should I choose?
If you are interested in learning more about microservices please download our 11 page white paper "Making Microservices Work for Your Organization."