Serverless Drupal in a microservices environment

Serverless architectures are all the rage with Amazon, Google and even old Microsoft providing platforms for running services in Java, JavaScript and Python. Hell, even PHP is now supported natively by Microsoft and also possible via the Zeit serverless platform. Serverless is obviously somewhat early in the Gartner hype cycle and thus it's hard to say how succesful and valid it will be.

Regardless of what happens to the hype, it's a good time to consider how an old monolithic application like Drupal can survive in the future. Drupal is known for being very extensible through the module system, this leads to it being easily used for quite a few things at once. Everything from user management to email list management to content production can be done with Drupal.

This massive accumulation of features is the antithesis of the serverless movement. In these cases you simply build microservices that do a very specific thing and then send it to the cloud and forget about it. The provider will do all the software updates and handle the infrastructure and this is reliable as the functionality is very simple.

With Drupal you'll have more complexity and upgrades are manual and can be somewhat of a risky business when done fully automated. Even though Drupal 8 adopts semantic versioning, the scheme does not guarantee that all the modules actually adhere to the rules of it. This is inherently shown in the example where it took a PaaS provider 540 days to create a Drupal 8 install guide because of random issues.

A lot of the architectural changes made in Drupal 8 enable the adoption of a microservice based deployment strategy using Docker and other methods, but this does not change the fact that Drupal is used for too many things at once to be carelessly deployed and maintained by a 3rd party. In addition the added overhead in Drupal 8 results in worse performance, which is not good if you're doing a single thing and doing it very well.

If you wish to use Drupal 8 in a microservices environment you'll need to cut it down to smaller pieces which can be more easily maintained and understood. But because Drupal itself is a complex system it will never achieve the elegance of a lightweight JavaScript framework like Express or KOA. In addition you'll loose a lot of the benefit of Drupal as you'll need to orchestrate individual Drupal instances to work together instead of having a single integrated instance.

All in all it seems like nothing is one size fits all and expanding Drupal to microservices is likely not the ideal solution. It can function as one piece of the puzzle, providing a content field. But for a complete solution, using Drupal is no longer as attractive as it was in the age of the monolith.