Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Modular Monolithic Architecture, Microservices and Architectural Drivers

Modular Monolithic Architecture, Microservices and Architectural Drivers

From observing what is currently happening in the IT community, Kamil Grzybek concluded in a recent article that most new projects are implemented using the microservices architecture. He believed that the IT industry at large is making a mistake adopting microservices just because they believe this will solve all of the problems with monolithic applications. Instead, Grzybek recommended we focus on architectural drivers, and he emphasized that every architecture has its pros and cons – it will solve some problems but also create new problems. In a series of articles, he has started to describe the basic concepts and properties of a modular monolith and the drivers leading to a specific architecture.

Grzybek, architect and team leader at ITSG Global in Warsaw, started by pointing out that the terms monolith system and monolithic architecture commonly describe a system where all parts form one deployment unit, but they are often also assumed to be interwoven rather than containing architecturally separate components, and both interconnected and interdependent rather than loosely coupled. He thinks this a very negative characterization and not the ultimate attribute of a monolith. He instead defines a monolith only as a system that has exactly one deployment unit.

To achieve modularity, and hence a modular architecture, Grzybek notes that you must have modules that are independent and interchangeable, and each module must have a defined interface and implement everything necessary to provide the functionality the interface describes. A module is never totally independent; it’s always depending on something else. But the dependencies should be kept to a minimum matching the principles: Loose Coupling, Strong Cohesion. To determine how independent and interchangeable a module is, we must look at three factors: the number of dependencies, the strength of these dependencies, and the stability of the modules it depends on.

Changes in a system more often target business functionality rather than technical parts. A module should therefore provide a complete set of features from a business perspective in order to be more autonomous and independent. It should also have a well-defined interface – a contract that defines what the module can do and hides or encapsulates how it is done. Grzybek notes that encapsulation is an inseparable element of modularity.

Architectural drivers are the set of requirements that have a significant influence over an architecture, and Grzybek refers to Michael Keeling for this definition. Grzybek classifies drivers into four main categories: Functional requirements define what problems a system solves, and how. Quality attributes determine qualities like maintainability and scalability. Technical constraints are about tool limitations, team experience and technology standards. Finally, business constraints relate to things like budget and hard deadlines.

Grzybek emphasizes that all architectural drivers are connected to each other; a focus on one of them often causes a loss for another driver. The software architecture of a system is for him a continuous choice between different drivers, and he notes that there is no predefined right solution – there is no silver bullet.

One common architectural driver discussed when comparing a modular monolith with a microservices architecture is level of complexity. Grzybek finds the modular monolith less complex than that of a distributed system. High complexity reduces maintainability, readability and observability. It also requires a more experienced team, an advanced infrastructure, and a specific organizational culture. If simplicity is a key architectural driver, he therefore strongly recommends a team to first  consider a monolith and refers to an article by Martin Fowler: Monolith First.

In his article, Grzybek also discusses other drivers including productivity, deployability, performance, failure impact, and heterogeneous technology, and for each he gives an example and the driver's impact on different types of architectures.

Grzybek concludes by emphasizing that:

the shape of the architecture of our system is influenced by many factors and everything depends on our context

Late last year Grzybek published a project where he designed, implemented, and described in detail a monolithic application that was built using a Domain-Driven Design (DDD) approach. His goal with this project was to show how a monolithic application can be designed and implemented in a modular way.

At the microXchg 2019 conference in Berlin, Jan de Vries argued for building a monolith before going for microservices.

In a presentation at the Reactive Summit 2018 conference, Randy Shoup described an incremental architecture approach to building systems, and claimed that we should start with a simple architecture and evolve it as needs arise.

In a blog post 2015, Stefan Tilkov argued that the main benefit of microservices is creating clear and strict boundaries between different parts of a system. He also argued against the idea that a microservices architecture always should start with a monolith, and claimed that building a well-structured monolith, with cleanly separated modules that later may be moved out as microservices, is in most cases extremely hard, if not impossible.

Rate this Article