The Monolithic Architecture

The word “monolith” was originally used by Ancient Greeks to describe a single, mountain-sized block of stone. Though the word is used more broadly today, the idea remains the same – a monolithic software product is a single, indivisible unit that will generally grow to a large size.

In a typical client-server architecture, a monolithic product lives on the server, where it handles HTTP requests, executes logic, and interacts with the database. It contains a single executable that performs all of the server-side functions for an application.

For example, to update the behavior of a product page, a developer would access the same code base as they would to add a new customer service feature, or change the functionality of a promotional carousel. In a monolith, everything is managed and served from the same place. The size and simplicity of monolithic software products are both their strengths and their weaknesses.

Having all the components tightly coupled poses another challenge: whenever we execute or compile such software, all the components should be available or the build will fail. The process of upgrading them would be more complex, as we would have to consider other components that require code changes too. This would result in more development time than is required for the actual change.

Deploying such an application would become another challenge. During deployment, we would have to make sure that every component was deployed properly. If we didn’t do this, we may end up facing a lot of issues in our production environments.

Challenges with Monolithic Architecture

  1. Large code base: This is a scenario where the code lines outnumber the comments by a great margin. As components are interconnected, we would have to deal with a repetitive code base.
  2. Too many business modules: This is in regard to modules within the same system.
  3. Complex code deployment: You may come across minor changes that would require whole system deployment.
  4. Code base complexity: This results in a higher chance of code breaking due to the fix required in other modules or services.
  5. One module failure affecting the whole system: This is with regard to modules that depend on each other.
  6. Scalability: This is required for the entire system and not just the modules in it.
  7. Inter module dependency: This is due to tight coupling. This results in heavy changes if required for an operation of any of the modules.
  8. Increased development time: This is due to code complexity and interdependence.
  9. Inability to easily adapt to new technology: In this case, the entire system would need to be upgraded.

It isn’t a bad idea to build a monolithic application, but it is a bad idea to let a monolithic application grow out of control.

Monoliths are agile at the start, allowing a business to get a product off the ground quickly. However, more consideration should be given to the architecture of the application when more time is being spent fixing existing code rather than building new features.

In the next lesson let’s look at how SOA tries to address these issues.

This lesson is part of the course Microservices with C#, .NET Core and Azure. Use navigation on the right.