What is Monolith design?

• Single: In the case of an application, we are talking about a single piece of code or a deployable. An application that can and should be deployed on a single machine.
• Indivisible: We cannot break the application down; there is no easy way to divide the application code or deployable.
• Slow to change: This is more of an implication of monolith design. It is a wellknown fact that changing a small piece of code is easier than a big, monolith code, especially since you don't know what implications such a change will have.
• Huge code base: As we are developing the application as a single unit, everything is placed under a single code base. 
• Testing: As the application is managed as a single unit, we need to test the whole application, even if a small change is made, to make sure there are no integration or regression issues.
• Availability: Let's say that, while updating an employee data report, a developer introduced an error that caused the system to run out of memory, which will bring down the whole system. So a report that actually might not add too much value to the system and may be used rarely by users has the capability of bringing down the whole system.
• Scalability: The code is deployed as a single unit, hence we can only scale the application as a whole, making it a heavy operation. For example, if we just need to execute multiple instances of salary processing on pay day, we cannot do that in isolation; and we need to scale the whole application by providing more hardware firepower (vertical scaling) or make copies of the whole application on different machines (horizontal scaling).
• Inflexible: Say we need to create a special reporting feature and we know a tool or framework is available in a different language than we use. It is not possible in a monolith architecture to use different programming languages or technologies. We are stuck with the original choice, which might have been made years ago and is not relevant anymore.
• Difficult to upgrade: Even a small decision, such as moving from Java EE 6 to 8, would mean that the whole application, along with all the features, needs to be tested and even a small problem would hinder the upgrade, whereas if we were dealing with multiple small services, we could upgrade them independently and sequentially.
• Slow Development and time to market: For these reasons, it is difficult to make changes to an application with a monolith design. This approach does not fit well in today's agile world, where customers need to see changes and modifications as soon as possible, rather than waiting for a release that takes years.