Reactive Microsystems

Chapter 2. Slaying the Monolith

Only with absolute fearlessness can we slay the dragons of mediocrity that invade our gardens.

John Maynard Keynes

Before we take on the task of slaying the monolith, let’s try to understand why its architecture is problematic, why we need to “slay the monolith” and move to a decoupled architecture using microservices.

Suppose that we have a monolithic Java Platform, Enterprise Edition (Java EE) application with a classic three-tier architecture that uses Servlets, Enterprise Java Beans (EJBs) or Spring, and Java Persistence API (JPA), and an Oracle SQL database. Figure 2-1 depicts this application.

The problem with this design is that it introduces strong coupling between the components within each service and between services. Workflow logic based on deep nested call chains of synchronous method calls, following the thread of the request, leads to strong coupling and entanglement of the services, making it difficult to understand the system at large and to let services evolve independently. The caller is held hostage until the methods have executed all their logic.

Figure 2-1. A monolithic application with a classic three-tier architecture

Because all these services are tightly coupled, you need to upgrade all of them at once. Their strong coupling also makes it difficult to deal with failure in isolation. Exceptions—possibly blowing the entire ...