When we install a web application such as Magento or WordPress, we expect it to provide everything we need to build our site or eCommerce store. The web server and the database are separate, but all the business logic – the code responsible for building web pages, responding to requests, processing data, and communicating with the database – is contained in a single package, the monolith.
Microservices are an alternative application architecture that has grown in popularity over the last few years. Instead of bundling all of an application’s functionality into a single unit, it is broken into small services, each of which has a well-defined role. The microservice architecture is particularly useful for software-as-a-service applications, but are microservices always the right choice?
In this article, we explore monoliths and microservices, examining the benefits and drawbacks of each.
What Is a Monolith?
Monoliths are what most non-developers think of as an “application.” A monolith is a piece of software with a broadly defined role: an eCommerce store, a content management system, a mapping application, a search engine. Each of these applications contains many different working parts, but, in a monolith, all the functionality is developed as a single unit in which the parts depend on each other to work.
What Are Microservices?
A microservice is a small service that has a single job. An eCommerce application might be built from microservices for inventory management, order processing, the product catalog, authentication and account management, and payment processing. Each microservice may have an independent database.
Microservices communicate via an API. Each microservice consumes API calls from other microservices. For example, an order processing microservice might communicate with the inventory management microservice to confirm that a product is available.
To a user, a monolithic application and one composed of microservices provide a similar experience. But, to the application’s developers and the company footing the bill, the choice of application architecture can make a big difference.
Monolith vs. Microservices - The Pros and Cons
There is no right answer that applies to all applications in all scenarios. Monoliths and microservices have advantages and disadvantages. Which is right for a particular project depends on the needs and experience of the development team, the type of application, and the goals of the business.
The Pros of Microservices
The main advantages of microservices are the result of decoupling: breaking applications into multiple services gives developers flexibility that is not possible with a monolith.
Decoupled services are easier to modify
Consider the eCommerce application mentioned earlier. If the developers wanted to change the inventory service, they could modify just that service. Provided the API didn’t change, the other components of the application are unaffected. Microservices are easier to understand and evolve than the application as a whole. The developers don’t need to test or redeploy the whole application. They don’t have to worry about hidden dependencies between modules.
Services scale independently
Monolithic applications can be difficult to scale horizontally, especially if the whole application depends on a single database. Microservices, on the other hand, can be scaled, duplicated, or load balanced depending on the needs of individual services.
Microservices can use different technology stacks
Because each service is self-sufficient and presents a consistent API, other services don’t care about how it does its job. Consequently, microservices can be built with different languages and libraries. If a development team wanted to give Haskell a try, they could implement a small service in Haskell without affecting the rest of the application.
This benefit can have a significant impact on developer productivity and application performance. No one (sane) wants to build an entire web application in C++, but if the application is architected around microservices, the majority of the application can be built with a high-level framework such as Ruby on Rails. If a particular service needs to be more efficient, it can be rewritten in a faster language like Go or C++.
The Cons of Microservices
Although microservices have many advantages, they don’t come for free.
Microservices can increase the complexity
Microservices can be a headache to develop and deploy. Instead of a single application, there might be a dozen or more services that require independent CI/CD pipelines and hosting infrastructure. For bigger teams with a DevOps professional that might not be a problem, but for smaller and solo teams, deployment and infrastructure management can soak up time that would otherwise be spent improving the application.
Microservices take longer to get into production
Because of their increased complexity, microservice-based applications need more up-front planning. Rather than throwing up a quick Rails app to test an idea, developers have to engineer multiple smaller apps and decide how they will communicate.
Cross-cutting concerns can complicate development
What is the best way to divide an application into microservices? It may not be apparent at the beginning of a project. The decisions made in the early days of a project often prove incorrect as the application matures, requiring the addition of service layers and extra services that complicate development. It’s possible – and not uncommon – to end up with a rat’s nest of services that are nowhere near as independent as they should be.
The Pros of Monoliths
The benefits of monoliths can be summed up in one word: simplicity.
Monoliths are easier to build and deploy
Deploying a monolithic application can be as simple as copying the code to a folder on the server. Developers can focus on building features that meet business goals rather than building complex deployment and testing pipelines.
Faster initial setup
Microservices have upfront costs in money and time that monoliths do not. It might be argued that the investment is worthwhile because the application will be easier to modify and understand in the future, but, with limited resources and short runways, microservice architectures may be premature optimization.
The Cons Of Monoliths
Monolithic applications are easier to get up and running than microservices, but problems tend to present themselves as the application grows and matures.
Modification becomes increasingly difficult
Large monoliths can be ferociously complicated and hard for even the most talented developer to understand in their entirety. There are multi-million dollar businesses that rely entirely on decades-old monoliths that they are afraid to change in case the whole house of cards comes tumbling down.
Monoliths are a single point of failure
When part of a monolithic application breaks, the whole app is likely to go down. If a microservice breaks, then only part of the application stops working. For example, if the cart service for an eCommerce store contains a fatal bug, customers won’t be able to place an order.
But they will still be able to log in to manage their current orders. Microservices are more resilient than brittle monoliths.
Conclusion
As you can see, although both monoliths and microservices have benefits, neither is the perfect choice for every scenario. Each organization should consider which fits their team and project best. There are, however, some generally applicable guidelines:
- For proof-of-concept and minimum viable product projects, a monolithic application will allow a development team to get code into production more quickly.
- Established organizations with larger teams may benefit from a microservices approach that divides the application between development teams, each responsible for a single encapsulated service.
Finally, monoliths and microservices are not exclusive categories, and most applications exist somewhere on a spectrum between the two extremes. It’s common for applications to start as monoliths and gradually transition to microservices as developers identify functions that are well suited to a stand-alone service.