Building my first website

Introduction

Hello and welcome to my blog. My name is Adrian, and I’m a 10-year IT industry veteran. I’ve worked from humble origins, starting in help desk and working my way all the way to IT System Engineer roles at various startups.

During all this time, I’ve invested little in website development, both professionally and even less personally. I remember, and still loathe, writing HTML/CSS. My only experience with it was Myspace profile edits and an extremely bare-bones company landing page that was quickly replaced by a Squarespace template.

While web dev is not at all the focus of this blog, this post is a great (I think) introductory piece where I begin to document my journey shifting careers from IT to DevOps** while learning relevant skills along the way. How else could I let you, dear reader, know any of this without creating a website first?

Domain names and a registrar

Why didn’t anyone tell me how difficult choosing a personal domain name would be?

As soon as I decided to “show my work” and create a space to show off projects, musings, ramblings, and how-tos, I stood frozen wondering what I would even name such a thing. I went through multiple iterations only to find out that nearly everything I wanted was taken. I had anticipated this and settled on adriancreates.dev because I thought it was thematically correct. I’m creating and stumbling along the way, and honestly, .dev just looks neat.

Now that I had the domain name settled, I hit another block: what registrar would I use to purchase my domain name? This will be a recurring theme throughout these related posts: the sheer number of options available and ways to go about any step, and how I stop myself from “analysis paralysis”. Though I am exaggerating a bit, this process took quite a bit, and I ultimately decided on Porkbun. I’ve purchased domains from them before, it’s cheap, and has .dev domains available, unlike AWS Route 53 (this becomes relevant later). I don’t need to reinvent the wheel here.

Hosting and creating a website

Now that I purchased and secured my domain, I had to decide on the method I would build and host my website. The only concrete idea I had was that I needed a way to blog. I could use an existing platform like Ghost, WordPress, or the numerous free blogging sites available. I could self-host and purchase a VPS, but which VPS? Should I create a website from absolute scratch and learn a stack? I’ve read the occasional medium post on things like Spring Boot or Tailwind CSS. but the absolute surface-level knowledge I have of these wouldn’t really help me. I’d embark on some sort of web development path, a direction far from my initial goal to learn more about AWS, CI/CD—you know, DevOps-related services and skills. I also did not want something that abstracted nearly everything away—like a WordPress-hosted solution where I need only click “create post” to, well, do that. I wanted something that had to be built and configured, to force me to use a terminal and follow documentation.

After researching hours’ worth of ways to host a website, I decided to simply use AWS for everything. After all, it’s the cloud provider I want to further entrench myself in, and I’ve completed some certifications in it already. I don’t regret the time I spent reading about the alternatives; I learned a lot, no harm done. Though now that the host was chosen, I set myself to actually build the website.

S3 Static Website Hosting

Initially I created the first version of this website using the S3 static hosting option in AWS. You could build a simple static website on AWS’s flat object storage system. Essentially, and heavily summarized, you could host your website inside a folder that lives on the internet. You can dump an index.html and 404.html, and you had a working website that displays barebones content. In order to do this, and this is definitely not a tutorial, a hosted zone in Route 53 is required. Once created, you are supplied with four name servers, servers that tell you with authority that whatever website they are referencing is the website you are trying to reach and not a derivative. Knowing this, Porkbun needs to have the original name servers it gave you replaced with the Route 53 name servers. All this so you can control the domain within AWS.

After configuring the required records in order to make adriancreates.dev forward to www.adriancreates.dev, I wrote some basic HTML and attempted to load my website. Much to my chagrin, I could not get the website to load. It was then that I quickly realized that the .dev domain can only be used with HTTPS, which is great, but I had to find a way to configure TLS. CloudFront was then incorporated into the architecture to achieve this, and more records were created to point my website to the CloudFront distributions. Finally, the TLS certificate that comes with CloudFront was associated with my domain. At long last, version 2 of my website was born, and typing out its URL actually loaded the website. Mission accomplished.

Final Thoughts

It would be nice to say that after all that effort, I ended up choosing Hugo as my static website generator, and you’re now reading this on version 2 of the website. Yeah, no.

I ended up reconfiguring the website a third time and then completely deleting it and using a completely different way to host. My next post will be what I chose and why I do not recommend S3 static website hosting at all. Funny enough, AWS also doesn’t recommend it. There is a banner when you attempt to turn on static hosting; it reads: “Hey, the new recommended way to host static websites is through AWS Amplify.” Can you guess what I went with?

Thank you for reading.