BT

Monoliths from a Microservices Perspective

| by Jan Stenberg Follow 34 Followers on Dec 18, 2014. Estimated reading time: 2 minutes |

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 Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT