Trade-Offs for Monoliths and Microservices

Applications can be designed using both, monolithic or microservice-based architectures. So far, we have looked at how the structure of an application is contoured by functional requirements and available resources. However, each architecture has a set of trade-offs, and these need to be thoroughly examined before deciding on the final structure of the application.

These trade-offs cover;

• development complexity
• scalability
• time to deploy
• flexibility
• reliability, and
• operational cost

Let's examine each trade-off in more detail!

Development Complexity#

Development complexity entails the efforts required to deploy and manage your application.

• Monoliths require one programming language; one repository; and this enables sequential development.
• Microservices on the other hand require multiple programming languages; multiple repositories; and this calls for enables concurrent development.

Scalability#

Scalability deals with how your application scales up and down, based on the incoming traffic. The capacity for your application to handle incoming traffic has to grow as your traffic grows.

• Monoliths require replication of the entire stack; hence it's heavy on resource consumption.
• Microservices on the other hand require replication of a single unit, providing on-demand consumption of resources.

Time to deploy#

Time to deploy encapsulates the build of a delivery pipeline that is used to ship different features of your application.

• Monoliths require one delivery pipeline that deploys the entire stack; more risk with each deployment leading to a lower velocity rate.
• Microservices require multiple delivery pipelines that deploy separate units; less risk with each deployment leading to a higher feature development rate.

Flexibility#

Flexibility implies the ability to adapt to new technologies and introduce new functionalities to your application.

• Monoliths give you low rates of flexibility, since the entire application stack might need restructuring to incorporate new functionalities.
• Microservice give you higher rates of flexibility, since changing an independent unit is straightforward.

Reliability#

Reliability captures practices for your application to recover from failure and tools to monitor your application.

• When monoliths are in a failure scenario, the entire stack needs to be recovered. Also, the visibility into each functionality is low, since all the logs and metrics are aggregated together.
• On the other hand, when microservices are in a failure scenario, only the failed unit needs to be recovered. Also, there is high visibility into the logs and metrics for each unit.

Operational cost#

With the above factors in consideration, operational cost captures the cost of necessary resources to release a product.

• Monoliths tend to have a low initial cost, since one code base and one pipeline is managed. However, the cost increases exponentially when the application needs to operate at scale and needs to be reliable.
• On the other hand microservices tend to have a high initial cost, since multiple repositories and pipelines require management. However, at scale, the cost remains proportional to the consumed resources then.

Each application architecture has a set of trade-offs that need to be considered at the genesis of a project. But more importantly, it is paramount to understand how the application will be maintained in the future e.g. at scale, under load, supporting multiple releases a day, etc.