BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Monoliths from a Microservices Perspective

Monoliths from a Microservices Perspective

This item in japanese

Bookmarks

Instead of trying to minimize the misunderstandings about exactly what a Monolith is, it is increasingly being used as a generic insult in the same way that Legacy is, Robert Annett explains trying to clarify the characteristics of a monolith.

Robert, working in financial services, sees a strong trend for microservice based architectures and frequent discussions comparing them to monoliths, but also a great deal of different views on what a monolith really is and some fights between proponents of the two paradigms, fights that sometimes refers to ETSY who claims to be successful in deploying a monolith more than 50 times a day.

For Robert a monolith is an architectural style or a pattern and he defines three basic viewtypes to characterize a monolith.

With a Module Monolith all of the code for a system is in a single codebase which is compiled and deployed as a single artefact. The code may be well structured with coherent and decoupled packages but it still is one single module.

With an Allocation Monolith all of the code is deployed at the same time. All the code may be compiled at once into one artefact or several artefacts may be created, still a single version is deployed with all nodes running the same version.

A Runtime Monolith will have a single application or process performing the work for the system, a common way of building systems. With one main deployed component this often implies an allocation monolith, one exception being when new versions are rolled out across regions, resulting in multiple versions running concurrently.

Robert concludes by emphasizing that we should be careful when arguing about Microservices vs Monoliths. He believes that a direct comparison is only possible when discussing runtime viewtypes and their properties. Moving away from a Module or Allocation monolith may help but it will not magically enable a Microservices architecture. When moving to such an architecture Robert’s advice is to consider all viewtypes and align the boundaries across them, not to build and distribute a monolith over a set of nodes.

Chris F Carroll in another blog post claims that a single deployment unit is not a monolith and emphasizes that we have to separate the logical and physical views, referring to the 4 +1 architecture view model, a view that both Udi Dahan and Jeppe Cramon advocated at their respective presentation at the recent Microservices Conference.

Rate this Article

Adoption
Style

BT