Headless Rises: A Field Guide to the CMS Apocalypse

Headless content management systems—a.k.a decoupled, microservices architectures—are all the bleeding-edge rage in the content world. Remember about five years ago when everyone in IT started chanting, “Move to cloud,” and it was kind of funny because the “cloud” was ambiguous but we all migrated to the cloud anyway (because it was better)? 

Well, like it or not, that start-of-the-cloud-fanaticism phase is where we are with decoupled CMS today. And if you’re on the fence about it, you might consider heeding this great advice from Warren Buffett,” If you don’t like something you can’t change, you might as well learn to enjoy it.”

Once you decide to adopt a microservices-driven architecture, you’ll have to navigate a bewildering new world of platforms, technologies, considerations, and approaches, many of which do not exist in the monolithic CMS world.

It’s a lot to take in, but don’t panic—this field guide is meant to be your trusty resource to help you navigate this new world. Think of this guide as the indispensable towel Arthur took everywhere in The Hitchhiker’s Guide to the Galaxy. The good news is that there are no Vogons to deal with!

Here’s what we’ll cover:

1. What is headless?

2. Why go headless?

3. When should you go headless?

4. Four layers of headless implementation

5. Is headless ready for the limelight?

 

What is headless?

Broadly speaking, every website using a CMS has two components: 

1. The content editor experience (where you write articles and build pages)

2. The experience layer (what a website visitor sees)

Put more simply, there is a  backend and a frontend to every website. A traditional CMS solution—think WordPress, Drupal, Sitecore, or Adobe Experience Manager—is a monolithic technology in the sense that it provides both of those two components in a single, tightly -coupled system. A decoupled approach breaks this apart and allows an organization to use different systems for each component.

It doesn’t matter which backend or frontend you choose, because they simply exchange data via an API. On the backend, you can still use the monolithic leaders—Drupal, Sitecore, Adobe Experience Manager, and WordPress—or you can use new headless cloud CMS offers (more on that later). But the key to understanding headless CMS is that you are breaking what used to be one system of two tightly-coupled components into two systems.

Before we go any further, a reminder that headless and decoupled mean the same thing. There are some who say they are different, but headless/decoupled have the same use cases and implementation, so why not just make it easier for everyone? Tomato, tomahto, right?

Why go headless?

In general, the drawbacks of a monolithic CMS are:

1. Tight component coupling that limits the flexibility of what is possible on the front end, with constraints built into the backend. 

2. Lack of interoperability with other channels that need the content stored on the site, like custom web applications, mobile apps, internet-connected devices, and social sites.

3. Intense resource requirements that are not optimized for modern digital infrastructures, where server-side computing power is only necessary to power the editorial experience and not the front end experience.

4. Decreased developer velocity, as back end considerations must be taken into account for front end only refinements.

5. Talent pipeline concerns, as new engineers entering the workforce do not want to learn monolithic CMS platforms and instead are drawn toward Javascript frameworks.

Going headless offers a variety of compelling benefits:

1.  A new world of JavaScript talent: By going headless you are investing in a technology infrastructure built on modern best practices, an approach enthusiastically supported by a vast community of developers.

2. Faster development turnaround: The approaches to traditional CMS theming layers are over a decade old, designed in a world where smartphones did not exist. Embracing a headless approach means taking a quantum leap forward to the best practices of today. 

3. Reduced attack surface: A decoupled site is largely composed of static code, so it can be hosted directly on the edge layer. That means a smaller server footprint and less dynamic surface is exposed to the public internet. Less attack surface means fewer opportunities for malicious users to cause issues. 

However, as with any approach, there are important limitations that are crucial to understand, including:

1. A lack of page building capabilities: If you go decoupled, you lose out on your CMS platform’s functionality for building page layouts in a WYSIWYG experience that is useful for marketing users. This is a technical limitation that is unlikely to be solved in the next 12-to-24 months.

2. Limitations with plugins: When you go decoupled with a monolithic CMS like Drupal, WordPress, or AEM, inevitably, you will break compatibility with a variety of plugins in that platform’s ecosystem. Certain plugins for these platforms will assume that the CMS is building the front end and that the site is not decoupled, and thus, their functionality will not work. The only workaround to this limitation is likely custom development, which is often not ideal.

3. Debugging complexity: A decoupled site has the same number of moving parts as a coupled approach, but uses two different platforms (frontend and backend), so debugging is more nuanced. One way to mitigate this risk is to ensure developers on both sides of the stack know the limitations of their knowledge and where the over stack starts and stops. This will facilitate better cooperation with the development team and speed up debugging.

4. Site builds suddenly become crucial: To make decoupled stacks really work for content-driven experiences (traditional marketing sites), you need to move from the idea of updating a site to the idea of building a site. Without an intuitive build system, a decoupled project will fail when the site goes live. Be sure to understand why a build system is necessary, how it fits into your caching and distribution strategy, and how it will integrate with your development workflow.

Do the benefits outweigh the tradeoffs? Despite the drawbacks, for a variety of use cases going headless offers a compelling set of benefits that improve the customer experience layer. However, it is important to remember that no architectural decision in technology is free; everything has a cost. The most important consideration to ensure success is to dispassionately focus on what will drive real value to your business and what really helps you achieve your business objectives, and work backward from there.  

When should you go headless?

In our article on indicators that you should go headless, we talked about the use cases that are typically solved by going headless. Here’s a quick recap:

1. You have true multi-channel content marketing operations

2. Your developers are bottlenecked

3. You want to be on the bleeding edge

4. You are experiencing brand consistency issues across business units or divisions

5. You use microcopy in your customer journey

If any of these indicators sound familiar, you are probably making the right choice. Here are a few examples when going headless makes sense:

1. You have a traditional marketing site, but you are building a choose-your-own-adventure-style multi-step flow to guide different visitors to the right information service category. You want the experience to work lightening-fast on all devices, and flawlessly on mobile to push conversion of visitors as high as possible. You can keep your overall site on a traditional front end, but the user flow should be decoupled.

2. You are building an online store but will only ever have 10-15 products for sale. You do need a cart and checkout flow, and will have promotions, but your product detail page experience is unique. If you make your entire site decoupled, you will enjoy fast developer velocity, enabling you to inexpensively and continuously adapt and iterate on refinements to boost your custom buyer journey conversion.

3. You want a section of your site to power a specific experience that will be embedded into an internet-connected device.Decoupling will allow you to leverage the existing content in your CMS, allowing the marketing team to manage it in one place while building an experience that will feel as fast as using an app on a smartphone.

As much potential as decoupling offers, there are use cases that are often not a great fit:

1. You have a traditional marketing site where a few content changes are made daily. Front end performance is important for you, but as a standard “browse-and-snack” experience (clicking around, reading snippets, following information scent), you can achieve a fast experience simply by using a content delivery network and properly configuring your caching layers.

2. You have an online store with dozens or hundreds of SKUs, and need a standard browse-and-buy experience, complete with promotions and a standard product details page experience. You won’t achieve the lightning-fast end user experience of a decoupled site, but you will benefit from being able to leverage all of the plugins available for your commerce platform that going headless would make impossible to use.

Four layers of headless implementation

The infrastructure needs for a headless CMS approach are different than the needs for monolithic CMS platforms, and it is important to understand that difference to avoid problems later in the migration.

A decoupled CMS architecture has four distinct layers:

1. Editorial layer - where your content lives

2. Build layer - turns your dynamic content into static assets that can be served to the end user

3. Static file storage layer - where the output of the build lives

4. Customer experience layer - content delivery network that caches and serves the files to your website visitors

For each layer, we will take a look at what it is, why it is important, and which platform options are available. Let’s start with the editorial layer.

Editorial Layer

The editorial layer is the foundation of your decoupled, microservices CMS architecture. It is the place where your content will be stored, and where the marketing team will go to edit content. The editorial layer is the headless CMS in a headless CMS approach.

Broadly, there are two kinds of providers: cloud versus custom code control. Here are the major options:

Platform	Description	Type
Contentful	The leading cloud headless CMS on the market. With extensive funding, a robust product, and Silicon Valley pedigree, Contentful is the platform to beat.	Cloud
Kentico	A well established all-in-one marketing solution that is investing heavily in their headless approach. With a strong headcount, they are a viable organization, but growth has been stalled for more than two years.	Cloud
Contentstack	Recently spun out of Built.io, Contentstack has less momentum and headcount than Contentful, but sports a terrific set of enterprise logos.	Cloud
Acquia Drupal	The latest version of Drupal has strong support for headless CMS built into the core product. While generally more effort to implement than WordPress, Drupal offers a robust internal API, strong security, and proven enterprise credibility. If you want custom code control, Drupal is your best option.	Custom code control
WordPress	The dominant website CMS platform in the world has reluctant support for headless experiences. WordPress works well at all traffic and content levels.	Custom code control

 

Runners-up include Zesty.io, ButterCMS, and Prismic.io, all of which are doing interesting work in this rapidly growing space. However, these organizations are not (yet?) of sufficient size to be a wise choice for mid-market and enterprise customers to build on.  

When choosing a provider, here are the major considerations:

• Do you need user session management? If your digital experience will have logged-in experiences, you should likely consider one of the custom code control options like WordPress or Drupal.

• Do you have extensive, custom integrations? Each of the cloud platforms lets you build custom integrations, but if you have extensive needs, you might find the greater flexibility of a custom code control platform offers you the lack of constraints over cloud options.

• Do you want to heavily customize your editorial experience? For whatever reason, if an investment in heavily customizing the editing experience of your back end is a good use of resources, then you should look at one of the custom code control options like Drupal or WordPress. You can heavily customize the cloud options, but it will be the same amount of work for a less flexible infrastructure. In this case, go custom. 

Build Layer

The build layer is the newest, and least mature component to a headless approach, so there are fewer players. The platform to beat right now is GatsbyJS, a potent mix of wildly-popular open source library and funded, commercial startup. React-static, and next.js are two viable alternatives to GatsbyJS. Both require more configuration to get to work for a marketing site, while GatsbyJS takes a batteries-included approach, which reduces time-to-market and enforces emerging best practices.

A runner-up at the build layer is Hugo. However, Hugo is built on the Go language, so leveraging Hugo means a dramatic reduction in the available talent pool and partner ecosystem. Those who consider Hugo are wise to remember the favorite refrain of fans of JavaScript: There will always be more JavaScript developers. For an in-depth overview of Hugo versus Gatsby, check out Gatsby vs Hugo, a detailed comparison.

Static File Storage Layer

The static file storage layer is the simplest and least important layer because this is where your build system deposits the files that your customer experience layer picks up, caches, and serves globally. For the adventurous, you can use Dropbox. GitHub pages and Amazon S3 buckets are more common, stable approaches.

Customer Experience Layer

You have two broad choices to make here. The first choice is to use a content delivery network, like Fastly, Akamai, Cloudflare, or Cloudfront. These are well-established players in a well-established market that provide rock-solid platforms to statically cache and deliver assets from your build layer to the world. A headless approach doesn’t impact the criteria for selecting a CDN, so use traditional methods to do that (or just keep on using the one you have already).

Alternatively, there are emerging platforms that offer all of the benefits of a CDN, but wrap that around a system specifically designed to tie together the entire deployment flow of headless CMS sites. Netlify is a great example and the current leader in this emerging, bleeding-edge space.

Is headless ready for the limelight?

This is not a new trend in digital technologies—website hosting is a great example of how microservices has transformed into an established approach. Five years ago, you would set up some servers and install services on them to host your own web server, file server, database server, etc., but today you can spin up services from Amazon for individual parts of your hosting needs, sort of like how different utilities provide water, gas, and electricity to your house. 

This drive towards decoupling is now disrupting commerce platforms. You use independent services now for things like customer support, shipping options, tax calculations, search, and email campaigns, whereas the commerce platform used to do it all.

In several years, we will look back to 2018 as the year a headless CMS approach for marketing sites became production-ready. There were many factors that contributed to this moment. The first innovation was platform maturity of the backend CMS (like Contentful), both at the individual company level (headcount, investment, revenue, logos) and in the market itself (with several compelling platform providers from which to choose).

However, the crucial innovation came at the experience layer. One of the main limitations of going headless for a CMS was that a marketing site, even a dynamic one, is still a static site experience where serving static HTML files provides a better customer experience than an application experience. The engagement flow is fundamentally different compared to a web application. Essentially, for a web application, you want dynamic code at the edge, but for a marketing site, you want a dynamic build process that delivers a static experience you can put at the edge.

The tooling matured rapidly in 2018 by solving this exact problem. GatsbyJS is a great example of this: It is essentially a system to use React to build a headless CMS front-end designed for the needs of marketing sites, like an HTML build flow.

Just how popular is Gatsby? Here are the downloads of Gatsby for the last two years, courtesy of npm-stat:

 

Yes, you read that right. There are more than 50,000 downloads of GatsbyJS every day.

Here is a chart of how many stars GatsbyJS has on GitHub from przemeknowak.com:

With the backend players maturing and open source technologies providing the unique needs of marketing sites on the experience side, the stage was set for organizations to take full advantage of the many benefits of a decoupled architecture.

Seize the day

Until the middle of last year, moving to a headless CMS model was only for those with a sense of adventure and a high tolerance for risk. Those days are long gone. Today, a headless CMS approach offers compelling benefits over monolithic CMS platforms—like improved developer velocity, lightning-fast user experiences, and a wide talent pool of developers.  But careful choices have to be made to ensure your investment will provide a good ROI after launch.

And remember: don’t panic.