Back in 2014, the company I work for – Linaro – was using WordPress to host its websites. WordPress is a very powerful piece of software and very flexible but it did present some challenges to us:
- Both WordPress and MySQL needed regular patching to minimise vulnerabilities.
- It could be quite a resource hog if you were trying to get an optimal end-user experience from it.
- It was difficult to make a WordPress site run across multiple servers (to avoid having single points of failure, resulting in an inaccessible site).
Towards the end of 2014, I attended the AWS re:Invent conference and happened to attend a session that would ultimately change how Linaro delivers its websites:
The basis of the idea presented in this session is to use a static site generator which takes your content, turns it into HTML pages and stores it in a S3 bucket from where it can be hosted/accessed by your customers.
By doing so, it eliminates the “retrieve the data from a database and convert it to a web page on the fly” process and thereby eliminates a database platform (e.g. MySQL) and the conversion software (e.g. WordPress). The up-front conversion is a one-off time hit, compared to the per-page time hit that a system like WordPress endures.
It is worth emphasising that although the session was at an Amazon conference, the underlying premise and the tools being discussed can be used on any cloud provider.
Earlier, I said that this session would ultimately change how Linaro delivers its websites because it took a bit of persuading … In fact, the following year, I shared this article with the staff who managed the content of the websites:
Why Static Site Generators Are The Next Big Thing
The challenge was that everyone was used to using WordPress and switching to a static site generator was going to be quite an upheaval in terms of workflow, content creation and management.
We got there, though.
We ended up choosing Jekyll as our static site generator. One of the reasons is because it is the technology used to drive GitHub Pages and, as such, gets a lot of use. For the rest of the infrastructure, we did use S3 and CloudFront to provide the hosting infrastructure and, as expected, this turned out to be a lot cheaper and a lot faster than using WordPress.
To migrate the websites to Jekyll, the Marketing team started by building out a Jekyll theme to manage the look and feel of the sites. Initially, this was kept in a private git repository on one of Linaro’s private git servers. The content was always managed as public git repositories on GitHub.
That split of repositories actually caused a couple of headaches for us:
- Building the site required both repositories to be retrieved from the git servers and the content merged.
- If we wanted to automate the building of the website, we’d need tools that could work with our private git server.
… but that will keep for another article 😊.
Index page: Tips, tricks and notes on building Jekyll-based websites