This chapter is from the book
This chapter is from the book
This chapter is from the book
Are Monoliths Bad?
Over the past several years, the words Monolith and Monolithic as applied to software have come to have very negative connotations. Even so, just because the vast majority of Monolithic legacy systems have arrived at the Big Ball of Mud zone, that doesn’t mean it is a necessary destination. It’s not the Monolith that’s the problem—it’s the mud.
The term Monolith can simply mean that the software of an entire application or whole system is housed in a container that is designed to hold more than one subsystem. The Monolith container often holds all or most of the subsystems of an entire application or system. Because every part of the system is held in one container, it is described as self-contained.
The internal architecture of a Monolith can be designed to keep the components of different subsystems isolated from each other, but can also provide the means for communication and information exchange between subsystems. Figure 1.8 shows the same two subsystems from Figure 1.1, but with both subsystems inside a Monolithic container.
){kind=link}
)
Figure 1.8 A Monolithic container showing a portion of a whole system. Only two of possibly several subsystems that make up the whole are shown here.
In Figure 1.1, we assumed that the two subsystems were physically separated from each other in two processes, and that they communicated via a network. That diagram implies a distributed system. In Figure 1.8, the same two subsystems are physically together in the same process and perform their information exchange through simple in-process mechanisms such as programming language methods or functions.
Even if the ultimate system architecture is to be Microservices, there are advantages to the system starting out life as a Monolith. Not having a network between subsystems can prevent a lot of problems that are unnecessary to contend with early on and are quite counterproductive. Also, using a Monolith is a good way to demonstrate commitment to loose coupling between subsystems when it is easier to allow tight coupling. If transforming to a Microservices architecture is the plan, you will ultimately find out how loose the coupling actually is.
Although some oppose the approach of using a Monolithic architecture for early development where a distributed Microservices architecture is the target, please reserve judgment until this topic is discussed in Parts II and III of this book.