• Table of Contents

Monolithic Architecture

Everything we've designed up until now can be considered as a monolithic architecture. At the core, it is a single, indivisible unit, depicted below.

Figure 7.1 A sample taxi-hailing application.

For example, in our taxi-hailing application, all of the components — such as passenger management, billing, notification, and etc. — are all packaged and deployed as a single software system at the end.

• With everything being in one software, monolithic architecture is extremely common.
• They are simple to develop since our IDEs and other tools are focused on building a single application.
• As a result, these applications becomes easier to test, since all of the components of the application are contained within a single codebase.

However, as we will discuss next, monolithic architectures has huge limitations.

Monolithic Approach Limitations

Monolithic architecture works well in the early stages of a project, but as applications grow over time and eventually become huge, it becomes difficult to scale and maintain.

Figure 7.2 A monstrous, incomprehensible big ball of mud.

Once your application has become a large, complex monolith, the codebase becomes overwhelmingly complex to understand — in turn, fixing bugs and implementing new features correctly becomes difficult and time consuming. In additional, it faces several problems:

1. With a large, complex monolithic application is that it is an obstacle to continuous deployment.
   • Software as a Service (SaaS) applications are typically expected to push changes into production many times a day.
   • Updating any one part of a complex monolith requires redeploying the entire application.
   • Lengthy start-up times and extensive manual testing make continuous deployment next to impossible.
2. Monolithic applications can also be difficult to scale when different modules have conflicting resource requirements.
   • Suppose one module requires CPU-intensive image processing and would ideally be deployed in Compute Optimized instances, while another module is an in-memory database best suited for Memory-optimized instances.
   • When these modules are deployed together in a monolith, it can be challenging to choose the optimal hardware configuration for both modules.
3. Another problem with monolithic applications is reliability.
   • Bugs in any module, such as memory leaks, can potentially bring down the entire process.
   • All instances of the application are identical, which means a bug can impact the availability of the entire application.
4. Monolithic applications make it extremely difficult to adopt new frameworks and languages.
   • For example, let’s imagine that you have 2 million lines of code written using the XYZ framework.
   • It would be extremely expensive (in both time and cost) to rewrite the entire application to use the newer ABC framework, even if that framework was considerably better.

A solution to these problem is adopting what is now known as the microservices architecture pattern.

Microservices Introduction