Monolithic applications are applications where all of the database and business logic is tied together and packaged as a single system. Since, in general, monolithic applications are deployed as a single package, deployments are somewhat simple but painful due to the following reasons:
- Deployment and release as a single concept: There is no differentiation between deploying build artifacts and actually making features available to the end user. More often, releases are coupled to their environment. This increases the risk of deploying new features.
- All or nothing deployment: All or nothing deployment increases the risk of application downtime and failure. In the case of rollbacks, teams fail to deliver expected new features and hotfixes or service packs have to be released to deliver the right kind of functionality.
A Hotfix, also known as a Quickfix, is a single or cumulative package (generally called a patch). It contains fixes for issues/bugs found in production that must be fixed before the next major release.
- Central databases as a single point of failure: In monolithic applications, a big, centralized database is a single point of failure. This database is often quite large and difficult to break down. This results in an increase in mean time to recover (MTTR) and mean time between failures (MTBF).
- Deployment and releases are big events: Due to small changes in the application, the entire application could get deployed. This comes with a huge time and energy investment for developers and ops teams. Needless to say, a collaboration between the various teams involved is the key to a successful release. This becomes even harder when many teams spread globally are working on the development and release. These kinds of deployments/releases need a lot of hand-holding and manual steps. This impacts end customers who have to face application downtime. If you are familiar with these kinds of deployments, then you'll also be familiar with marathon sessions in the so-called war rooms and endless sessions of defect triage on conference bridges.
- Time to market: Carrying out any changes to the system in such cases becomes harder. In such environments, executing any business change takes time. This makes responding to market forces difficult—the business can also lose its market share. With microservice architecture, we are addressing some of these challenges. This architecture provides greater flexibility and isolation for service deployment. It has proven to deliver much faster turnaround time and much-needed business agility.