I have been thinking about different hosting options for this blog for some time, even just to stop my friends from joking about the fact that I have been so vocal about Serverless technologies and yet, my personal blog runs on WordPress!
However, as someone who enjoys writing and have little interest in fiddling with web servers or static site generators, WordPress is actually a very attractive option. It comes with a lot of tools to make your life easy, and has a rich plugin ecosystem to help you go beyond the basic WordPress features. And not to mention the fact that I have over 700 posts in circulation and I don’t want to break them.
So there is a lot of reasons for me to stick with WordPress, but the runtime performance is so… meh. I have worked with my host (I have gone through a couple, the last of which was InMotion) to do some optimization – using the SuperCache plugin, updating the .htaccess file with magic strings, etc. All these effort yielded marginal gains, if at all.
And then, on the 4th March, 2018… my old APL post from 2015 made it to no. 5 spot on HackerNews, and that extra traffic took my old WordPress site down for a good 24 hours.
Of the thousands of people who flooded onto the site – to read about APL, believe it or not! – I have no idea what percentage of them managed to get through. Those that did get through probably found a pretty damn sluggish site that’s not worth hanging around any longer than is absolutely necessary.
That was the final straw that broke the camel’s back.
So I decided to give Shifter a try, which I remember reading about on the Serverless framework’s blog a while back. After some trial-and-error, I have managed to put both this blog as well as the homepage for my Production-Ready Serverless course onto Shifter and the overall experience was pretty great.
And man, the performance of the new site is superb. It perfectly combines the convenience of WordPress with the performance of a statically generated site, and I get to migrate all my 700+ old posts over and give this site a complete new look and feel in the process.
Overall, I’m a very happy customer so far, and thanks a lot to Daniel from Shifter for helping me out through the migration process!
How it works
Essentially, Shifter lets you start a Docker container running WordPress, so you can create new posts and update the blog using the same WordPress tooling that you’re familiar with.
When you’re done editing, stop the container, generate a deployable artifact (which kicks off an automated process to statically generator the pages, posts, feeds and archives for your WordPress site) and then deploy the generated artifact to the CDN.
Of course, you can assign your custom domain to the generated site as well.
Pros and Cons
As you can imagine, some WordPress features don’t work anymore since the site is statically generated – comments, contact forms, search, etc. Also, some plugins are not compatible with this setup. But you can use 3rd party services such as Disqus or Google Forms instead. Give this post a read to see a few other alternatives you could consider.
Depending on the size of the site, the generate step might take a little while to complete. This blog for instance, takes roughly 40 mins* to generate each time. Thankfully, it’s not a problem for my workflow as I create 2-3 blog posts per month at best, so the long generation time is a fair tradeoff for the runtime performance.
- After a helpful tip from Dan at Shifter, this is now down to about 15 mins. The trick is to tell Shifter to skip generating media pages, which by default there is one for every media file…
Also, another nice benefit of this approach is that I can almost treat my WordPress site like a staging environment. I can make all kinds of wholesale changes, and experiment with things without impact live users until I generate and deploy the artifact.
What’s more, the WordPress installation itself is no longer sacred. Even if I make a royal screw up to the WordPress installation, I can easily create a new container with a fresh WordPress installation and restore from the last good backup. Right now, this backup has to be created manually, but it’s entirely possible the platform would start providing some form of automated backup in the future.
Kudos, and keep up the good work Shifter!
Anyways, I just wanted to take this opportunity to give credit where credit is due, and give a shout out to the folks at Shifter for a job well started.
As an engineer, I also think it’s a fantastic use of technologies like Docker and Lambda.
As a blogger, it gives me the performance and scalability I’m after, at a price point that is much cheaper compared to other hosting options (based on what I will have to pay for the same level of performance and scalability).
Now, I just need to write another HackerNews-worthy post!
I specialise in rapidly transitioning teams to serverless and building production-ready services on AWS.
Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.
Check out my new course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. Including basic concepts, HTTP and event triggers, activities, callbacks, nested workflows, design patterns and best practices.
Come learn about operational BEST PRACTICES for AWS Lambda: CI/CD, testing & debugging functions locally, logging, monitoring, distributed tracing, canary deployments, config management, authentication & authorization, VPC, security, error handling, and more.
You can also get 40% off the face price with the code ytcui.
Here is a complete list of all my posts on serverless and AWS Lambda. In the meantime, here are a few of my most popular blog posts.
- Lambda optimization tip – enable HTTP keep-alive
- You are thinking about serverless costs all wrong
- Many faced threats to Serverless security
- We can do better than percentile latencies
- I’m afraid you’re thinking about AWS Lambda cold starts all wrong
- Yubl’s road to Serverless
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- AWS Lambda – compare coldstart time with different languages, memory and code sizes
- Guys, we’re doing pagination wrong