In the beginning, there was the Monolith... 😀
Building a monolith has always been the default Architectural Style. I mean, in the very beginning we had one file per application, then we started having applications with several files, and only since the 1990s we started to see applications composed of other applications (although the first experimentations were during the 1980s).
The monolith itself evolved. When applications started to be built using multiple files, there wasn't much reasoning about them, nor there was a big need for that reasoning because the applications were relatively simple. As the applications got bigger and more complex, there was a need for some reasoning behind what files to create and how to relate them.
Modular Programming was the solution proposed in the late 1960s and during the 1970s. It was an evolution from classes to a more coarse-grained explicit definition of code units. Programming languages implemented modularity with different grades of explicitness.
For example, JAVA has class level visibility of default and public, where default level means that a class is only visible in its package (module), and public means that the class is visible in and outside of its package (module). This allows us to define what classes should be used by the clients of a package.
Another style of modularity are the Components. As explained in one of my previous posts, Components are modules created with a domain concept in mind. They are ideally standalone "applications" that can be used to create composite applications. A recurrent example of this style if the pipes and filters architecture, extensively used in Unix systems and that allows us to do something like "ps -ef | grep php". Another example is the usage of microservices as components of composite applications, like Netflix.
This style of code organisation also has been around for a long time, going back to the late 1960s, just like modular software development.
Nowadays, having a monolithic Architectural Style simply means that all of the application code is deployed and run as a single process on a single node . We assume, it is using modules and components, although it is in fact often not the case.
It's important to understand why the key words here are "deployed" and "node". Regarding the first one, deployed, it means that it doesn't matter where the code is physically stored if it is organised in one or several repositories, but how it is organised at runtime. Regarding the second keyword, node, it means that it is still a monolith if we deploy the application to several servers, as in a horizontal scaling context.
In a single node server, all of the modules in a monolith are assembled to the same memory image, which is run as a single process on a single node. Communication is done through standard procedure calls through the same stack and heap. It's the single memory image makes the application monolithic. If you are running modules in different processes, you're doing IPC. Because modules fall into different process boundaries, you'll start facing distributed computing challenges. That's getting into microservice territory. (Thank you for your feedback, _dban_)
This style, although with very bad reputation, can work very well even for large applications. It only stops being good enough when we need:
- Independent scalability of different domain components;
- Different components or modules to be written in different programming languages ;
- Independent deployability, maybe because we have a release rate higher than the deployment pipeline can handle for one code base, causing the deployment of a release to be slow because it needs to wait for the deployment of other releases, or even causing the deployment queue to grow faster than it is consumed.
At that point, we need to segregate our monolith into different applications, in an SOA Architectural Style (more on that in a followup post).
The "big ball of mud", AKA Spaghetti Architecture, is the anti-pattern for this style, where the packages structure and relations are not explicit, structural cohesion and encapsulation does not exist or is minimal, dependencies follow no rules and it is very difficult to reason about subsystems, to make changes and to refactor. The system is opaque, viscous, fragile and rigid : A Big Ball of Mud!
1997 -- Brian Foote, Joseph Yoder -- Big Ball of Mud
2012 -- Len Bass, Paul Clements, Rick Kazman -- Software Architecture in Practice
2017 -- Herberto Graça -- Microservices architecture: What the gurus say about it
2017 -- Herberto Graca -- Software Architecture Premises
2017* -- Wikipedia -- Modular programming
2017* -- Wikipedia -- Component-based software engineering