Monolithic vs Microservices: The pros, cons, and everything else
In a sea of software architecture patterns, two stand out above the rest when it comes to building modern digital experiences: monolithic architectures for their long-standing popularity and microservice architectures for their flexibility and scalability.
While both are very much in play today, fast-growing, highly competitive, and successful companies are taking the microservices approach with increasing frequency.
In this post we get into the “why” behind such software development preferences by offering an overview of both architectures and then comparing their core capabilities.
An overview of each architecture
What is a monolithic architecture?
Often considered the more traditional of the two architectures, monolithic architectures package a series of business capabilities — or functions — into one. With business logic and data tightly coupled, applications supported by such architectures have large codebases and are therefore less agile. A point of attraction for this type of architecture is that many applications have been around for some time and are well trusted. They also come ready out of the box, which means they might be more suitable for startups or companies with small teams, understaffed to curate and connect a technology stack.
What is a microservices architecture?
Microservice architectures (sometimes called composable architecture, modular architecture, or MACH architecture) exist in opposition to monolithic architectures. Instead of existing as a suite of preselected tools, microservice architectures assume a more modular approach to building applications. Teams mix and match the tools and independent services (i.e., microservices) needed to carry out a specific project, or meet individual and team preferences. These tools are considered loosely coupled, with communication between each occurring via application programming interfaces (APIs). It’s also worth noting that each microservice has its own database, unlike monolithic architectures which share a single database.
Comparing core capabilities across each architecture
Development
Microservices: While microservices play well with each other, they have no problem doing their own thing. To get more technical, the individual services existing in such architectures are language- and framework-agnostic. This means you or your team can be dynamic in what you use, selecting the languages and frameworks which you’re either most well-versed in or cater to specific project needs. Similarly, microservice architectures can be managed on an individual basis by a smaller team, likely making the buy-in and onboarding process more streamlined and less likely to be met with blockers.
Monoliths: Monolithic applications, on the other hand, are more rigid. They often require developers to use a single programming language and framework for the entire application. This can present a learning curve for developers on the team who may be less well-versed in the language and framework selected. Furthermore, because there is a loose coupling between the components (i.e., capabilities) of the application, they cannot be easily managed independently. Instead, they must be managed by individuals or a team of individuals who understand their entire scope. Depending on how large the application is, retaining this information and being responsible for maintaining the whole system can be taxing.
Deployment and delivery
Microservices: For organizations keen on making quick updates, a microservice architecture is the preferable architecture pattern. With this type of architecture, independent deployment is possible. This means just the service or piece of the application being updated is redeployed, rather than the entire suite of services. Release cycles can therefore be spontaneous (i.e., continuous integration and continuous delivery), and occur with the frequency demanded by modern changes in the marketplace, high levels of competition, and new customer demands.
Monoliths: The deployment and development process for monolithic applications are often more complex and drawn out. Instead of small-scale, incremental deployments, monolithic applications must be deployed in their entirety every time an update or change is made, often on a web server. Because this process is lengthy, monolithic deployments are tied to a schedule, making overall business processes less agile — a drawback should your company wish to go to market more quickly. Here, the application is treated as a project rather than an easily and often iterated product.
Integration
Microservices: This type of architecture opens its arms to adding new business capabilities and new features. These new technologies can be custom-built or third-party individual services. As an example of how significantly companies can build up their microservices, Amazon has anywhere between 100 and 150 microservices in use at a given time, extending the efficiency and capabilities of internal teams.
Monoliths: Because monolithic architectures usually include a suite of tools and business capabilities offered by the software provider or vendor, it can be difficult to add new ones, especially if they are third-party or custom-built. Development teams may have to create workarounds to patch in these types of tools, which can add complexity to your architecture or open it up to security issues. Similarly, they might be locked into add-ons offered by the vendor. Such options might not be the best on the market or entirely satisfy the needs of the application being built. Integrating data across systems can also prove challenging.
Scaling
Microservices: Because each of the services within this type of architecture are separate and loosely coupled, they can be managed and scaled independently of one another. From a financial perspective, this can be a huge benefit as you’re only paying for the scaling you need.
Monoliths: With monolithic applications and their large, single codebases, scaling becomes more complex. When greater capacity and bandwidth is needed, developers must scale the whole system — which can be time-consuming and both cost- and labor-intensive.
Reliability
Microservices: Microservices are inherently more resilient than their traditional counterparts. When one service fails, only the capability or aspect of the application it supports goes down — not the entire application. While the application might be less complete, a majority of it is still accessible to the user. Best-case scenario, teams use automation when testing — a capability made possible with microservices — to prevent the odds of failure entirely.
Monoliths: When an error occurs in an application built using a monolithic architecture, it often takes the whole application down. While debugging is relatively straightforward as there is only one codebase, DevOps must redeploy the whole application, which, depending on its size, can take considerable time. This can affect the end user experience to a larger and more lasting extent than that of a microservice application and lead to frustrations.
More resources to help you select the right architecture
If you’ve been keeping track of which architecture performs better in each category, you’ve likely deduced that there are a few disadvantages of microservices. This might compel you to adopt the architecture right here and now for your next application — whether it be for web, mobile, or another channel all together.
Before you do so, here are some additional resources to consult:
White paper: How to access the performance of your composable architecture
Checklist: Find the right solution for your scaling business
Blog: Composable commerce: An intro to ecommerce microservices architecture
And keep in mind — the technology architecture you choose doesn’t have to be an either-or situation. There’s always the option to adopt a microservice architecture and integrate monolithic tools to fill a specific need. Pro-bono customer CodeDay’s microservice tech stack is proof enough, including Contentful. Read the case study.
