Our websites are IF’s main presence on the internet. They’re what potential clients and new hires see. They are also where we celebrate some of our work and keep and public history of what we’re thinking about. Building, improving, and maintaining these sites is an important part of the technical work we do at IF.
Our previous setup
Previously, IF hosted our websites on DigitalOcean. All our sites, including our main website, were hosted across two ‘droplets’ (virtual machines running on DigitalOcean’s servers). This set-up provided lots of control over the underlying infrastructure, allowing us to customise everything from the operating system up.
However, maintaining two servers takes time and consistent effort. We recognised that the majority of our sites could be converted to static web pages with no loss in functionality. Building them as web applications was a legacy of earlier workflows, rather than the best solution for right now. We wanted to spend less time on server maintenance and more time on our work.
‘Serverless computing’ is a bit of a misnomer: websites are still hosted and run on servers. The difference is that provisioning and maintaining the server is abstracted away from the developer and handled by the vendor.
There are plenty of serverless computing providers, including large, feature-rich platforms from Amazon, Google and Microsoft. For the majority of our sites, however, it was more important to have a process that would allow us to migrate all 28 of our sites quickly and securely.
Netlify as a platform also offered some key features that we were looking for: continuous deployment from GitHub, automatic TLS certificates with LetsEncrypt, and handy extras like deploy previews built for pull requests, displaying the site as it would be once the changes are merged in.
Our process for migration
We trialled a few approaches before settling on a process for migrating our sites to Netlify. This was important to ensure minimal downtime when we actually migrated our sites.
The first step was rewriting the index.js file as a kind of mini-static site generator (you can see an example of how we did this in this repo). We then created a new site from the GitHub repo on Netlify and assigned it a custom Netlify domain. Next, we changed our DNS records by adding a CNAME record for the new Netlify site. To keep track of where we were at in the process, we created a GitHub issue with a list of steps in each of the repositories we were updating and migrating (here’s an example).
In addition to reducing the amount of time we spend on server maintenance, our new set-up opens up some opportunities for how we build and manage our sites. For example, by using a headless content management system (CMS), we could store frequently used content in one place and reuse it across several sites. Handily, Netlify has built an open-source CMS for static sites that we’re going to try out.
Migrating our sites to Netlify has helped us reduce the amount of time we spend on server maintenance. It’s also been a great opportunity for us to think differently about how we build our sites and explore new technologies that can make the process of communicating our work easier.
Edited by Grace Annan-Callcott. Thanks to Ella Fitzsimmons and Dave King for their input.
If you’d like to hear more about our work, email us at firstname.lastname@example.org.
Come work at IF! Our open roles are here: https://projectsbyif.workable.com/