Monolith, Headless, Composable, Microservices

I’m hoping this document can serve as the definitive guide to these three terms, what they mean, and their best practices.

Section 1: Monolith

Definition (dictionary.com):

1. An obelisk, column, large statue, etc., formed of a single block of stone.
2. A single block or piece of stone of considerable size, especially when used in architecture or sculpture.
3. Something having a uniform, massive, redoubtable, or inflexible quality or character.

The term monolith comes from Greek monolithos, broken down as monos (single) + lithos (stone).

Monolith is not a technical term, its origins come from architecture and the physical world, but the term has evolved to allow its use as a descriptor for other items. It’s this third definition we need to pay attention to, as it’s this definition being used in digital commerce when people talk about a monolith.

This creates a lot of confusion as monolith is used as the opposite of other terms. Monolith will be used as the opposite of composable, headless, AND microservices even though all three are separate and distinct concepts. As a result, the definition of a monolith in ecommerce has to be derived through the context.

Section 2: Headless

Definition:

1. Without a head.
2. Having the head cut off; beheaded
3. Having no leader or chief; leaderless
4. Foolish; stupid: a headless argument.

In technology headless matches 1 or 2, and the head is the user interface (UI) of that item. A headless computer is designed to operate without a monitor, keyboard, or mouse. A headless browser has no UI, and is executed via command to run tests, scrape websites, or handle automated processes. So, in the sense of computing, headless has been used to describe a system where the UI does not exist, a solution where having no UI allows for a different use-case and the removal of the UI provides a better experience. This definition has been widely used since the 1980’s.

You would expect that a headless commerce solution would have no UI, that the solution would be designed for specific tasks where the removal of the UI provides a better experience. Unfortunately, this is not the case. A UI is required for customers to transact, making a UI a requirement of any headless commerce solution.

It could be argued that you have two pieces, the backend and the UI, and only the backend represents headless commerce, not the entire solution. That may have been true when the term headless commerce was first coined, but language evolved, and the most common definition today is that headless commerce is when the front-end and back-end is decoupled.

Given the mismatch between other headless technologies and headless commerce, it’s better to use the term API-Commerce, to alleviate confusion.

So API-Commerce or Headless Commerce always consists of at least two pieces of software. A back-end that handles data storage, processing, etc. exposing the functionality through APIs and a front-end that calls those APIs and acts as a UI for the customer. This front-end is most often a website but can represent any touchpoint such as mobile apps or voice drive assistants. Given this solution requires a minimum of two pieces, the term monolith is often used to define non-headless solutions, where the back-end and front-end are combined into a single item.

Section 3: Composable

Definition:

Composable is not a recognized word on dictionary.com and Merriam-Webster has the definition: “capable of being set to music” which is completely unrelated.

This is a new term and can vary depending on context. You may hear Composable Enterprise, Composable Architecture, Composable ERP, Composable Application, and more. Here we will only discuss Composable Commerce.

Composable Commerce is a term coined by Gartner in June 2020 in their report Composable Commerce Must Be Adopted for the Future of Applications. It is worth downloading the report and understanding the origin of the term.

Composable Commerce boils down to selecting best-of-breed components and combining (or composing) them to create the final commerce solution. Parts have been expanded on, for example instead of best-of-breed you may see best-for-me indicating that best is subjective, but the underlying concept remains the same. Buy multiple pieces from different companies.

After you have finished choosing and buying the components, the next hurdle is to determine the best way to combine them and design the required architecture to make these components act as a streamlined experience for customers.

Composable Commerce involves multiple components and multiple vendors. As a result, the term monolith is often used to describe the alternate approach of buying everything from a single company.

Section 4: Microservices

Definition:

Composable is not a recognized word on dictionary.com or Merriam-Webster. It is a relatively new technical term having been coined somewhere between 2005-2011 depending how specific we want to get.

Microservices.io provides the definition: Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of services that are:

• Independently deployable
• Loosely coupled.
• Organized around business capabilities.
• Owned by a small team.
• Highly maintainable and testable.

This may feel similar to Composable Commerce with a slight naming change of components to services, and people do try to use them interchangeably, but they are different concepts. Microservices are an architectural decision on how to build an application. When buying software from a vendor it may be impossible to determine if that vendor leveraged microservices by using the software. So while Composable Commerce is a user buying software from multiple vendors, microservices represent breaking an application up into multiple services often built by a single vendor.

Since Microservices involves multiple services, you probably know what is coming… the term monolith is used to describe the alternate approach of keeping everything as a single service.

Section 5: Questions

Can you combine a monolith with X?

I hear these questions often, can you have a headless solution built on a monolith, or can a monolith be composable? The fact is, monolith does not have a single definition but represents something that is:

• Not Headless
• Not Composable
• Not Microservices
• Any combination of the above.

As a result, it doesn’t make sense to talk about combining a monolith with one of these terms. Instead, we need to discuss the three items themselves and how they combine.

Can you have a headless solution not using composable?

Absolutely. You can buy both a back-end and a front-end from a single vendor. This will provide a decoupled back-end and front-end without having to look for best-of-breed components.

Can you have a headless solution without using microservices?

Yes. The back-end can be built as a single application.

Can you have a composable solution without using headless?

Maybe. This one is a bit tougher. Combining the components of a composable commerce solution requires the use of APIs. It’s not possible to have a composable solution without vendors that offer a robust and preferably API-First solution.

However, if you define back-end as Server-Side and front-end as Client-Side, you could combine these APIs with a server-side technology like Ruby or Java. This would mean all code is server-side. The application driving the UI would still be decoupled from the different API-First components, so this becomes a grey area.

I will say that this is purely a hypothetical question. Modern techniques including transitional apps and edge computing provide a massive increase in performance for ecommerce applications, so it makes sense to choose a JavaScript powered front-end with client-side code. Choosing full server-side negates most of the benefits of going API-First / headless.

Can you have a composable solution without using microservices?

Yes. There is no requirement to leverage microservices with composable. If you ultimately buy more than one component from a single vendor, microservices will ensure a clear separation so they can be decoupled and replaced individually if desired. So there are benefits to looking for microservices-based solutions, but it is not a requirement.

Can you have a microservices solution that is not headless?

Yes. The services can produce a UI without exposing any APIs.

Can you have a microservices solution that is not composable?

Yes. A single vendor can sell you all the pieces of a solution and enforce lock-in. They can build that entire solution on microservices. Microservices do not prevent vendor lock-in.

Can I have all three?

Yes! You can decouple the front-end from back-end with APIs and modern JavaScript frameworks to get a headless solution. The back-end APIs can be built using microservices. Best-of-breed components can be purchased from individual vendors and composed into the ideal bespoke experience.

This creates the best of all worlds.