Monolithic vs Microservices: Key Differences & Trade-Offs

First, let’s compare microservices vs monolithic architecture. A monolithic application is built as a single unit. Enterprise applications are built in three parts:

• A database — consisting of many tables usually in a relational database management system
• A client-side user interface — consisting of HTML pages and/or JavaScript running in a browser)
• A server-side application — which will handle HTTP requests, execute domain-specific logic, retrieve and update data from the database, and populate the HTML views to be sent to the browser.

This is what makes a monolith architecture monolith — it is a single logical executable. To make any changes to the system, a developer must build and deploy an updated version of the server-side application.

In contrast to a monolithic architecture, microservices’ capabilities are expressed formally with business-oriented APIs. They encapsulate a core business capability and the implementation of the service — which may involve integrations with systems of record — is completely hidden as the interface is defined purely in business terms.

The positioning of services as valuable assets to the business implicitly promotes them as adaptable for use in multiple contexts. The same service can be reused in more than one business process or over different business channels or digital touchpoints.

Dependencies between services and their consumers are minimized by applying the principle of loose coupling. By standardizing on contracts expressed through business-oriented APIs, consumers are not impacted by changes in the implementation of the service. This allows service owners to change the implementation and modify the systems of record or service compositions — which may lie behind the interface and replace them without any downstream impact.

Traditional software development processes (waterfall, agile, etc) usually result in relatively large teams working on a single, monolithic deployment artifact. Project managers, developers, and operational staff can reach varying degrees of success with these models, releasing application candidates that can be verified by the business, particularly as they gain experience using a particular software and deployment stack. There are, however, some lurking issues traditional approaches:

• Monolithic applications can evolve into a “big ball of mud” — a situation where no single developer (or group of developers) understands the entirety of the application
• Limited reuse is realized across monolithic applications
• Scaling monolithic applications can often be a challenge
• It’s difficult to achieve operational agility in the repeated deployment of monolithic application artifacts.
• By definition, monolithic applications are implemented using a single development stack (ie, JEE or .NET), which can limit the availability of “the right tool for the job.”

A microservice architecture — in concert with cloud deployment technologies, API management, and integration technologies — provides a different approach to software development. The monolith is instead disassembled into a set of independent services that are developed, deployed and maintained separately. This has the following advantages:

• Services are encouraged to be small, ideally built by a handful of developers.
• Services can be consumed and reused by other services and applications without direct coupling through language bindings or shared libraries.
• Services exist as independent deployment artifacts and can be scaled independently of other services.
• Services that are developed discretely enable developers to use the appropriate development framework for the task at hand.

The tradeoff of this flexibility is complexity. Managing a multitude of distributed services at scale is difficult for two main reasons:

1. Project teams need to easily discover services as potential reuse candidates. These services should provide documentation, test consoles, etc so reusing is significantly easier than building from scratch
2. Interdependencies between services need to be closely monitored. Downtime of services, service outages, service upgrades, etc can all have cascading downstream effects and such impact should be proactively analyzed

It’s important to make sure that your microservices delivery is carefully managed and that the SDLC is automated as much as possible. A lack of DevOps-style team coordination and automation will mean that your microservices initiative will bring more pain than benefits.

Ready to get started with microservices? Read our guide on best practices for building microservices.