Back in the day, monolithic applications were built and used. That is just a fancy way of saying that all of the application features were bundled together into a single package.

If you look at the illustration below, you will see the following bundled as a single ugly application:

The web frontend

The authentication

The logging

The datastore

The reporting

They are also tightly coupled, which means that if you want to change one part, you will have to change everything.

Monolith application

As a quick example, if you want to patch or update the reporting feature of the application in the illustration above, you have to take the entire application down, and patch/upgrade the whole thing. Talk about a nightmare. Work like this requires painful amounts of planning, carries enormous risk and complexity, and is usually carried out over long boring weekends in the office consuming too much pizza and coffee.

But the hassle of working with monolithic applications does not stop there. You’ll encounter similar challenges regardless of what part you want to scale. ;Scaling any single part of the application means scaling the whole thing

Every application feature is bundled, deployed, upgraded, and scaled as a single unit. Needless to say, this is not ideal.

Note: This is an extreme example. Not all applications were shipped like this. However, it was the prevalent model for building, deploying, and managing applications.