When I first started this blog I did so with the idea of trying to exemplify some of the DevOps principles I was excited about within the building and publishing of the website itself. Although neat in principle, this ran into a couple of major headaches in practice. Chief among them was the high maintenance burden and the high activation energy required for writing content.

Maintenance Burden

Over the past year I've ended up tinkering a great deal with the underlying deployment pattern of my website. This included:

• Migrating from Github Pages to Cloudflare Pages for content hosting

• Migrating my DNS configuration (and then separately my domain registration) from Google Domains to Cloudflare

• Setting up previews of development branches in Cloudflare

• Troubleshooting issues with all of the above.

These were all necessary and/or useful improvements, and I had a long list of additional things I wanted to improve further around setting up edge caching and improving load times, but none of these improvements resulted in me writing more content.

Activation Energy

Besides the maintenance burden I described above, the other reason that I didn't find myself writing a lot of content was the high-activation energy involved in adding new content. Each new article required:

• Creating a new branch in my Github repo

• Writing the content

• Making a commit

• Pushing the commit

• Creating a PR

• Previewing the PR build

• Merging the PR

While the version-control and CI/CD process provides substantial value within the context of building software, it felt like unnecessary overhead. And when I had an idea or thought I wanted to share, I would often get mentally blocked with all the little things that needed to happen.

In the end this high maintenance burden and high activation energy made it too hard to do the thing that my blog was intended to accomplish: provide a platform for me to share my ideas and interests.

Going with a Platform

In the end, I decided to replace my burdensome self-hosted publishing solution with a good commercial platform: Hashnode. I'm not going to do a breakdown of the features and rationale for choosing this platform in particular, but I do want to mention a bit of the "strategic" value of this decision because I think there are some valuable learnings here for teams building computational platforms in biopharma.

Choosing to use a good quality commercial platform to handle undifferentiated parts of your software stack can mean massive time savings from:

• building the features you need now

• building features that you don't know you need, but will need in the future

• visual tooling and an optimized user interface for routine tasks

That last bullet point is always particularly hard to justify building for an internal tool but can provide massive time savings when routine tasks become less burdensome, frustrating, or fully automated.

I've got a backlog of article ideas that I've been kicking around for the last year, and I expect this new platform-based approach makes it a lot easier to get those out into the world.