Back to WordPress (but Serverless)

I started this blog back in 2004 using a blogging system that I programmed myself. At the time, Nokia 9500 Communicator was the latest Symbian smartphone. Facebook was still called The Facebook and was being used in universities. World of Warcraft hadn’t yet been released.

Since then, this blog has moved over to various technology platforms. They have been based on PHP, Python, Node.js and AWS Lambda. I’ve used at least Django, Drupal, WordPress and Contentful to manage the content. Contentful was the latest platform. It worked alright, but I never really enjoyed using it. To make it really comfortable, you need to build your own CMS user experience around Contentful.

Some time ago AWS released support for Lambda Layers. This made it possible to run PHP applications on Lambda. That, combined with faster VPC cold start times and EFS support, makes it possible to now run WordPress as a serverless application.

Here is the basic idea of my Serverless WordPress architecture:

As you can see, I’m not exposing WordPress directly to he Internet. Instead I’m exporting the content as static HTML and serving it through S3 and CloudFront. WordPress only works as a CMS management tool in this setup.

You might also notice that the architecture is not fully serverless. It still requires a MariaDB SQL server. AWS offers Aurora Serverless as a replacement, but I don’t appreciate its 30-second cold-start delay. It doesn’t work well with API Gateway’s maximum request timeout of 30 seconds. In practice you get an error whenever you try to use WordPress after being idle for long enough for Aurora to scale down to zero.

Everything else than MariaDB, however, scales down to zero quite cleanly. I won’t get charged unless I’m writing articles or someone actually reads the blog. CloudFront and S3 are billed by the number of HTTP requests and the amount of data transferred to the Internet. API gateway, Lambda and EFS are billed only when I’m actively writing articles. S3 and EFS are billed monthly for a tiny amount of data storage, but that’s counted in cents.

My experience so far is that WordPress works absolutely great as a Serverless application. Lambda adds a few hundred milliseconds to each request, but it’s not too much when you spend most of the time editing articles that are saved in the background. The user interface is great for quickly uploading images and experimenting with visual layouts.

In the long term I will need to update WordPress occasionally. It can’t update itself because the Lambda filesystem is read-only. This increases its security significantly as PHP files cannot be overwritten. I do have a deployment script that automatically downloads the latest WordPress package, configures WordPress, and deploys it as a Lambda function. The main risk, in my estimation, is that some WordPress bug allows malicious content to be injected into the SQL database before the bug is patched. Luckily that by itself does nothing until the malicious HTML is also exported to S3.

If you’d like to discuss this topic further, you can reach me on Twitter as @kennu.