Does a ‘classic’ CMS like AEM fit in a modern MACH architecture?

What is a MACH architecture?

MACH is an abbreviation for Microservices based, API first, Cloud native and Headless. These four terms are modern software principles. A brief explanation of what they are, and what they offer:

Microservices based

Microservices-based applications are modular, meaning that every piece of functionality built is deployed as a separate module. The upside of this approach is that it's very flexible (modules can be exchanged independently) and very scalable. If numerous searches executed declines its performance, simply start up another instance of the search microservice.

API first

Applications should offer their functionality via an Application Programmers Interface (API), to make them flexible and easy to re-use. It is an open and simplified way to integrate with the product from another piece of software. Usually, this is a web based Restful API. Because the API is accessible over a network, the underlying technology is not relevant any more, and the integration of applications becomes easier. This approach gets especially powerful when the aim of the designed API is to be flexible, for example by using the query-based GraphQL standard.

Cloud native

Cloud native is more than just “running in the cloud” – the application should exploit the advantages of cloud computing. It should be scalable, redundant, with high available and always up-to-date. Commonly, this means containerization technology (similar to Docker) is being used.

Headless

A headless CMS is fundamentally a content repository that displays its content via API’s. There is no application server rendering the frontend of a website. This provides a lot of flexibility, since the content can be used in various channels (for example web, apps, voice, screens) independently of the technology used.

The whole idea behind the MACH approach is to create a modular application landscape that is composed out of “best of class” products. Products that easily integrate via their APIs, having the advantages of the cloud and freedom of choice for its frontend.

And how does AEM fit in?

While having started its life as a classic monolithic CMS running on-premise, AEM has advanced a lot recently. Adobe first offered a hosted version (“managed services”) of the CMS, but nowadays, a cloud native version of the CMS is available—AEM as a Cloud Service. This offers scalability, redundancy and is fully managed, allowing IT to focus on adding features and business value instead of performing operational tasks. Moreover, with this approach the CMS is always on the latest version, removing the need to do upgrades regularly, allowing the focus to be placed on delivering value.

Secondly, the pricing model has changed. Instead of having to buy licences, there is now a “pay per use” like pricing model that includes hosting and is calculated based on page views. This makes the product appealing to scale-ups or organizations that don’t have the marketing budget that the average enterprise has.

The hybrid approach

Many newcomers to the CMS market use a fully “content based” model. This means that instead of editing pages, the author edits a single piece of content. Like a product or vacancy. The whole idea behind this is to allow for maximal content re-use, even across channels.

From an architectural perspective, this is a great idea, however there is a downside. The authoring experience is not always optimal. Mainly because the context of the content is missing. It's not always clear where or how the content is utilized. Perhaps it’s too long or too short, or doesn’t fit the context well.

AEM offers a hybrid approach. It has always been a possibility to use page-based editing (an author is editing a page that looks like what the visitor would see). However, there is also the possibility to create centrally managed content fragments that are part of a structure. These fragments can be exposed individually or used on a page if and when desired.

A New GraphQL-based API is the latest addition made to the products in 2022 is, making it effortless to re-use content fragments on any platform. By modifying the query sent to the API, the consumer has full control of the data returned, and can request exactly what is required.

Allowing this kind of flexibility offers the best of both worlds – maximum content re-use by working with fragments, but also user-friendly “in context” page editing simplicity.