How This Blog Works: A Peek Behind the Curtain

Building a blog can be as simple as choosing a hosted platform, selecting a theme, and beginning to write.

That is not quite how this one works.

Over the first six months of operating this site, the publishing process has gradually evolved into something that looks less like a traditional blogging platform and more like a small cloud application deployment.

The individual components are not exotic. Microsoft Azure, GitHub, Cloudflare, Microsoft Word, RSS, XML sitemaps, and LinkedIn all play a role. What makes the environment interesting is how those pieces have been assembled into a relatively lightweight publishing pipeline.

After spending six months writing about technology, perhaps it is time for a peek behind the curtain at some of the technology running the blog itself.

It Starts as a Document

Perhaps appropriately for someone who has spent a career around Microsoft technology, posts generally begin in Microsoft Word.

Word is where the initial writing, editing, restructuring, and proofreading occurs. It is much easier to concentrate on the content without simultaneously thinking about HTML markup and web formatting.

Once the written content is ready, it is converted into HTML using a baseline template that defines the common structure and appearance of the site.

Word is the authoring environment. HTML is the publishing format.

It keeps writing and site development as two distinct steps.

A Static Site Running in Azure

The site itself is hosted using Azure Static Web Apps.

That model is a good match for what this site actually needs. Most pages are static HTML, CSS, images, and supporting files. There is no need to maintain a traditional web server simply to deliver that content.

That simplicity also creates an interesting distinction from traditional blogging platforms.

There really is not a “Publish” button. Publishing is deployment.

GitHub Becomes the Deployment Pipeline

GitHub provides the source repository and deployment workflow. Changes pushed through the repository ultimately become changes to the production site through GitHub Actions.

A typical publication includes several pieces:

• The new HTML article
• Any images associated with it
• Updates to the main blog page
• The RSS feed
• The XML sitemap

Those changes are committed together and then deployed to Azure.

There are other ways this could have been designed, including a pipeline based around Azure DevOps, but GitHub provides a straightforward model for this particular project.

For a personal site, that might sound slightly excessive. For someone who works with cloud technology, however, it makes the site considerably more interesting.

DNS and the Edge

The public domain is handled through Cloudflare, which provides the DNS layer and proxies web traffic before it reaches the site hosted in Azure. The design also handles the relationship between the root domain and the blog address.

Cloudflare's DNS capabilities are particularly useful for connecting the apex domain into the Azure-hosted environment without designing the site around a static public IP address.

This is also an area where I would intentionally stop explaining the implementation.

There is a meaningful difference between documenting an architectural pattern and publishing every DNS record, verification record, redirect configuration, security rule, or origin setting associated with a production site. The former can be educational. The latter usually is not necessary.

Certificates Without Becoming a PKI Project

The Azure-hosted application also uses a Microsoft-provided certificate for the site.

That is a small detail, but it illustrates another design objective: use managed platform capabilities when they eliminate infrastructure that provides little additional value to the workload.

There would be little benefit in turning a personal blog into a certificate-management exercise merely for the sake of doing it. The cloud platform can handle that responsibility. Let it.

Publishing a Post Changes More Than One File

This is probably the part visitors never see. Publishing an article does not merely add another HTML page. The site's supporting content must also be updated.

Blog Page

Depending on the article, the primary blog page may receive a new Featured card, Most Recent entry, and Archive entry. That keeps navigation and historical content organized as the number of articles continues to grow.

RSS

The site's rss.xml is updated so subscribers and RSS readers can discover the new article.

The main reason the site has an RSS feed is quite practical: engineers at my previous employer asked for a way to keep up with the blog after I left, since they would no longer receive my Teams updates. The feed gives them a way to follow new posts without relying on those updates.

RSS may be old technology, but that does not make it obsolete technology. For a site deliberately independent of a social platform or proprietary publishing service, RSS remains an extremely useful distribution mechanism.

Sitemap

The XML sitemap is also updated for search indexing. The site has been registered and verified with both Microsoft and Google indexing services.

Again, this is invisible to someone reading an article. But it is part of publishing that article.

And Then Comes LinkedIn

Once deployment is complete, the workflow changes from publishing to distribution.

That generally means creating a LinkedIn teaser introducing the article and giving readers a reason to click through to the complete post.

The blog is the permanent home for the content. LinkedIn is one of the mechanisms for introducing that content to readers. Owning the publishing destination means the articles are not dependent on the lifecycle, formatting limitations, or discovery algorithms of a particular social platform.

The Entire Workflow

Taken together, the primary publishing path is:

Alongside that path is the distribution loop: New Article → LinkedIn → Reader → Blog.

It is not an enterprise publishing architecture. Nor should it be. It is a deliberately lightweight cloud architecture appropriate for the workload.

The Blog Has Quietly Become a Lab

One unexpected consequence of building the site this way is that the blog itself has become part of the learning environment.

Changes have an actual outcome. HTML errors are visible. Deployment problems matter. DNS matters. Search indexing matters. Automation matters. Even seemingly small decisions about file structures and templates matter once dozens of articles depend upon them.

That makes the environment surprisingly useful because it occupies the space between a disposable technology lab and a production business workload. It is real enough that things need to work, but small enough to experiment with.

What I Would Not Publish

There is one other lesson worth mentioning when opening the curtain on an environment like this: not everything needs to be documented publicly.

Those private details add little educational value while creating unnecessary information disclosure. There is a perfectly good view from behind the curtain without opening every door backstage.

Six Months Later

When this site began, the primary objective was straightforward: create a home for technical writing, professional observations, experiments, and occasionally some less technical subjects.

Six months later, the site has become something else as well.

• It is a small application.
• It is a CI/CD exercise.
• It is a cloud workload.
• It is an HTML project.
• It is a publishing pipeline.
• Most importantly, it continues to be a useful lab.

There are certainly easier ways to publish a blog. But sometimes how something is built becomes part of what makes building it worthwhile.