Drupal in a MACH world

A little while ago, I gave a talk about “Drupal in a MACH world” at the DrupalJam, a yearly event in the Dutch Drupal community. This year with a much broader audience because anyone in the world could attend sessions for free online! You can (re)watch the talk here; the slides are also available.

What is MACH?

MACH is an acronym that stands for Microservices, API-first, Cloud-native and Headless. It is used to describe a standard for modern online enterprises. It is an architecture which prefers a layered ecosystem composed of best-of-breed technologies.

In its core, MACH is all about interoperability and flexibility. Pick the best solutions for your problems and use it as a decoupled service in your architecture. Each application should expose all functionality through API’s so it can be controlled and scalable in a cloud environment.

The benefits of MACH

This offers a lot of benefits. For example: you can build a much more tailored customer journey and pick the best tools for the job. It is also easier to prevent vendor lock-in and provide vertical or horizontal scaling because of the benefits of the cloud.

This new vision is also advocated by the MACH alliance, a relatively new organisation which promotes this new paradigm and also tries to help with vendor selection. Check out their blog section for a lot of very useful insights.

(How) does Drupal fit in?

In my talk, I was interested in how Drupal fits in this new brave world because it is an evolving project which isn’t designed as a cloud-native application in its current shape.

Looking at developments in the Drupal community, headless (or decoupled) Drupal seems to be the first step. The API-first initiative and GraphQL have matured enough for many companies to use Drupal as a CMS only and build the interaction layer in the preferred frontend framework.

But as mentioned before, each application in a microservice in a MACH architecture should expose an API to fully control the application. And while the API’s for content (headless) are available, we still lack many other API’s to fully control the application. Some of these can be worked around by using Drush (like installing a new site) but it is important to have this level of control in a Kubernetes cloud environment.

Checking compatibility with the 12-Factor App

Which brings us to other requirements we need to meet in order to have an application which behaves and scales nicely on a modern cloud platform. Luckily, there is a methodology available for us to help us: using the 12-Factor App, we can check our compatibility with a cloud native application.

Looking at these requirements, we see  other challenges in the way Drupal operates. For example, a 12-Factor App should be stateless. But Drupal (and any application that uses a database for storing its active state) is very stateful. Storing data in a database container would mean all data is lost when that container is destroyed. In this case we have solutions available from modern cloud providers using managed databases or we can roll our own with Kubernetes PersistentVolume.

Another issue are credential settings which are typically stored in settings.php. These need to be provisioned using language- and OS-agnostic environment variables.

Monolith to microservices

When we look at a typical Drupal project, the application often performs a lot of different tasks besides content management. For example, sending mails, queuing and batch processing tasks, processing webforms). In such a scenario it can quickly become a monolithic application. But the namespaced modular approach does offer the opportunity to peel off functionality and create separate microservices for it, which could be a viable approach from a technical perspective. Sam Newman talks about this in his book “Monolith To Microservices”. Although you can argue whether separating them in another Drupal instance would fit the concept of microservices, since we would be creating another CMS/CMF with a lot of overhead for each service this way.

Conclusion: Drupal in MACH architecture

The developments in cloud technologies like Kubernetes and the possibilities they offer have been high-paced for the last five years, and adaptation and support of more traditional applications, not only Drupal, is lagging a bit behind.

But all this doesn’t mean you can’t have a MACH architecture and still use Drupal as it stands. The full benefits of cloud-native applications can only be unleashed with full API driven functionality and for that Drupal needs work, but you can still mix in Drupal as it stands now in a MACH architecture if that is the functionality your business needs.