written by
Phill Duffy

Breaking down a Monolith Application

Insight 2 min read, November 6, 2019

I wanted to start a series of articles about data but from an Organisation/Business point of view. I will try to keep it free from jargon or explain my way through it the best I can. Most applications are a way to create, store, move or manipulate data - that's my angle here. A monolith application is something which is hopefully easy to understand and hopefully demonstrates how solutions are changing in some areas.

What is a Monolith Application?

Wikipedia's page on what a 'Monolithic Application' defines it as

In software engineering, a monolithic application describes a software application which is designed without modularity. Modularity is desirable, in general, as it supports reuse of parts of the application logic and also facilitates maintenance by allowing repair or replacement of parts of the application without requiring wholesale replacement. - Wikipedia

In essence, a monolith application is self-contained.

Monolith Metaphor

I do like a metaphor, so let's try and think about this another way.

The mobile phone in your pocket is most likely a monolith. If you want more megapixels in that camera, or you want your battery life to last days rather than the hours it has dwindled down too... you quite likely need to swap it.

Phone Monolith

Compare that to the good old car - you can change the engine, re-paint it, replace the tyres. There are many modules to the car which can be repaired, improved or swapped out as desired.

Modular or Monolith?

The metaphor breaks down a little bit when we think about a core benefit if IT solutions - they can be upgraded. Unless it's a Tesla (Tesla software update: did your car just get faster?) most cars don't have regular releases that all customers get automatically, or patches released to improve the handling. Updates are usually in the form of a new update to the model every few years, and people buy a whole new car.

CMS Monolith Example

I am going to look at a specific IT Solution example of a Content Management System (CMS), but much of the thinking can be more widely applied.

A CMS has many different tasks that it can do. If we boil it down to the core components, it comes out something like

Create Content -> Store Content -> Display Content

We can think of having three main modules to the CMS - create, store and display.

There are definite pros and cons to a Monolith Application for this scenario. The system has control over each aspect and can optimise to provide the most value for content creators, efficient storage and consumption of the content. Tools like Sitecore or SharePoint can do this exceptionally well. The tools need to be generalist by nature to meet the demands of many usages. The tools will be very good at core functionality and provide extension points so that customisations can be developed by third-party providers or by internal development teams to meet more specific demands.

The challenge comes when a Monolith Application needs to be maintained and extended. As soon as customisations are made, the Total Cost of Ownership (TCO) rockets, not only are you supporting the usage - you are now in charge of making sure you keep yourself on the core upgrade path and that you don't spend more time supporting your custom code than providing value to your business!

In the next article, I will dig a bit deeper into the flow of data, and other ways to create, store and consume data.