Written by Mia Villasenor Personal Infrastructure

How I Built This Site

Blogging can be hard. For me, I sometimes feel like it is too big of a task to fit in between other things I’m doing. The solution, of course, is to be flexible, and do a little bit here and there until you achieve a final product. Actually writing the blog needs to be a low-friction activity. With all of that in mind, I started drafting various blogging architectures I could use for this site.

The primary criteria was: Use a system that allows me to customize the site and do whatever I want, but when it comes time to write and publish, that should literally be one click away. Most importantly, I should be able to draft and publish from anywhere, on any device.

There are a lot of great platforms out there for blogging – but I’ve always had a soft spot for WordPress. It has a vibrant community, and as a project it has years of baked-in learnings on optimal blogging user journeys. I know you’re probably thinking “WordPress!? It’s a security nightmare and it’s written in PHP!”. I know. It can also be really bloated by default. That’s why what you are reading was generated by WordPress originally, but the server you got this page from is not WordPress. You’re not even connecting to the same server that generated this page.

Wow. That’s a lot of dependencies! Seems like a maintenance nightmare right? Not quite. My day job and home lab might involve more powerful infrastructure stacks like Google Kubernetes Engine, but I don’t want to stress about management for a personal blog that needs to stay up. I’m using a managed WordPress install that sits on top of a cloud provider that gets automatic updates, it’s only accessible via secure channels, it triggers CI in a managed provider (GitLab), and serves from a managed PaaS (Firebase Hosting). Once it is all set up, there really isn’t much to do. If one of the providers changes the way they do something, I can just swap that component out with little to no code changes (rsync works anywhere I can get a shell, for example)

The benefits of WordPress are also worth it – being able to pull my phone out and draft or publish a post is the perfect scenario, and now I can have that while still maintaining security and performance 🙂

Now that the site is finished, how do I feel? Well, it’s not finished 🙂 In an attempt to cut down on scope creep I didn’t implement a few features that would have made this even better, but I’m already planning a v2. Things I’m thinking about for the next iteration:

  • Switching to a mostly Roots.io WordPress stack such as:
    • Using Bedrock so that I can better manage dependencies and get as close as possible to Infrastructure as Code for WordPress internals. By default, WordPress is a mess in this regard, and repeatability is not guaranteed unless you do a full “snapshot style” backup/restore (https://github.com/roots/bedrock)
    • Rebuilding the theme in Sage to take advantage of Tailwind CSS, hot reloading, and the use of Webpack (https://github.com/roots/sage)

Maybe in a few months I’ll get to v2, but for now – welcome to v1, and thanks for reading the first post on my new blog! Expect regular content on all things cloud, software and systems engineering, and whatever else I’m excited about.

Last modified: March 7, 2024