Deconstructing the CMS

I first encountered Pace Layers around 02001 in Stewart Brand’s 01999 book The Clock of the Long Now. Brand, founder of The Whole Earth Catalog, first presented Pace Layering as a framework for understanding how a healthy society works. The six layers are in descending order from the highest and fastest to the lowest and slowest. In Brand’s words: “The order of civilization. The fast layers innovate; the slow layers stabilize. The whole combines learning with continuity.” I believe this framework also lends itself to software architecture.

The Monolithic CMS

Let’s take, for example, a content managed web site. With the more common monolithic CMS, content, templating, and publishing are tightly coupled. Typically, you’re rendering templates directly out of a database, and, without proper caching, the system will not scale. Further, should the database or cache go down, you are likely looking at downtime, particularly on high traffic sites. Often, as with Wordpress, the content modeling is so bare bones and tightly coupled to the navigation and templating that you have to contort complex content to make everything fit while likely introducing both administrative overhead for authors and database performance issues in the process. You will also likely have to make modifications to the base CMS installation via extensions which introduce additional complexity and risk, particularly when you’re upgrading the CMS. Overall, a site backed by a monolithic CMS is difficult to change incrementally, making redesigns risky, expensive, and nearly always late.

What if we applied Pace Layering to a CMS instead? Our objective is to refactor a monolithic CMS in such a way that the things that need to change the most often (e.g., content and the visual design) can be changed safely, inexpensively, and incrementally. To do that, we need to identify and decouple the key layers of the system.

Deconstructed

In this case, I see four keys layers: Content Repository, Content Mapping, Page Rendering, and Presentation. The Content Repository layer holds your content model and the content. I’ve put it as the innermost layer as it is unlikely to change often given the cost of migrating content and workflow from one repository to another. The Content Mapping layer transforms the content from the content repository into module and page data to be consumed by the Rendering layer. Again, this layer will evolve slowly in response to changes in the content model from below or the IA from above. The Rendering layer takes the transformed data and renders pages or modules to disk or to a cache. The top layer is the Presentation layer which could be an application or simply files on S3.

A Static Site Generator

As an example, the diagram above illustrates a simple static site generator built using Contentful as the content repository. Every time content is created or updated in Contentful, a payload is POSTed to an endpoint running on API Gateway. This triggers a Lambda function that transforms the payload into renderable content and stores that content to S3. Storing to S3 triggers another Lambda function that renders any HTML pages with the updated content to S3. Lastly, pages are presented from CloudFront backed by S3. Now, there are many use cases that this overly simplistic example doesn’t address — preview, content releases, and authentication come to mind. But what does this microservices approach to content management buy us?

Advantages

First off, the system is no longer dependent on a single content repository. The rendering process is general enough that we can introduce an arbitrary number of content sources independent of each other. Want to try out a new CMS without betting the farm? Now you can introduce it safely and inexpensively without having to migrate all of your existing content. It becomes easier and safer to experiment.

Second, the presentation layer is buffered against failures further down the stack. Instead of querying the content repository directly on each GET request, the expensive work of rendering content into templates is already done. And even if the content repository is down, any content already published will still be available. You also get read scalability for free.

Third, the designers and developers are no longer constrained by whatever templating system and content model a particular CMS has. One of the biggest constraints we had when we were executing the redesign of The Jewish Museum’s site was ExpressionEngine’s templating system. The Exhibitions section in particular has some fairly complex business logic, and it was far and away the most difficult to build and debug (and therefore the riskiest to change). In the architecture I sketched above, designers and developers are free to implement whatever their stakeholders need without the friction and incidental complexity of the underlying CMS coming into play.

Towards Antifragile

Where you draw the boxes matters. By paying attention to the pace of change at each layer of the system and the relative expense or risk involved in making changes in a particular layer, you will produce an architecture that is easier to manage, easier to scale, and easier to change.

If you find my work interesting, sign up for my mailing list so you don’t miss a thing.