An ambitious first attempt
Back in 2019, I created my first personal website to go along with my resume while applying to jobs and internships.
To say I knew nothing about websites and web hosting back then would be an understatement. Armed with only my persistent will to learn, I set out to create and host my very own website.
Graphic design is (not) my passion…
“Graphic design is my passion” is a quote usually said by people who have no graphic design capabilities whatsoever but try anyways. It’s a phrase I have used to describe myself many times when I have drawn a picture, let alone design a website. The idea of designing the full HTML and CSS from scratch was out of the question from the very beginning. However, I refuse to use a point and click service such as Squarespace. So what solution should I go with then?
An HTML and CSS template was the solution that I went with. I found a template that was licensed to be re-used and got to work. With a template, I already had all the files needed for a static website, I just needed to edit the text in the HTML and replace it with my own. The template that I chose had a very modern looking design with some bootstrap for fancy effects. In hindsight, I should not have went with the fancy modern looking template. The second I started to replace the filler text with my own, the entire site started to fall apart. The amount of time spent trying to get the elements on the page to align is time I will never get back. By the end though, I had a webpage that looked decent with my information on it.
Cloud hosting
At this point in time, my homelab was still growing and was a learning tool rather than a production environment. While I could have hosted the website on my homelab, uptime and availability was not a guarantee. Since this website was going on my resume, uptime and availability was a priority. This was the perfect opportunity to learn hosting something in the cloud.
I chose AWS as my cloud of choice since it appeared to be the dominate cloud platform at the time. My public DNS was already hosted in Route53, but I had no prior cloud experience otherwise.
Using my Google-fu, I learned about my different options for hosting a website in a cloud environment. My website is static, so there was no need for a fully virtualized webserver or EC2 instance. Not to even mention that I couldn’t cover the cost of running a fully virtualized cloud server on a college student’s non-existent salary.
I decided to use an S3 storage bucket to host the static files instead. The S3 bucket worked well and it was dirt cheap. My AWS bill was a whooping $0.78 per month. I could have done multiple things better with the initial deployment, but these are items I’ll get into with the new website.
First (and final) version is live!
After a week of learning and working on the site, it was live. I was proud of what I did with my capabilities at the time.
Now that I have my own website, I can easily update it with all my achievements and projects… or so that is what I thought. The act of updating anything on the HTML caused the entire page to become un-aligned, reactive elements to break, and any other issue that could be imagined. After my initial publish, I never updated the original site again…
Burn it down and start over
My old site served me fine for the first few years. Thankfully, it was a low maintenance set and forget website. So that is exactly what I did, I honestly forgot about it for a few years.
Even though the site stayed exactly the same, I was progressing in my career and becoming more skilled. Everyday, that old website became more out of date with my current abilities. Eventually I decided that enough was enough, I need to not only update my website, but completely rebuild from the ground up.
Using the lessons learned from building the original site and the experience I have over time, I once again set out to make a website. This time however, the site would be done properly, where I can easily edit, update, publish, and revert if needed.
Improving on past mistakes
Having already built my old website, I had some goals in mind for what I want to achieve with the new site. My goals for the new site can be broken down into a simple list.
- The capability creating and modifying content without editing raw HTML files.
- A framework to standardize and build pages from simple configuration files.
- Publish changes without manually moving files in out and of the S3 bucket.
- Version control to easily track edits and be able to roll back to previous versions.
- Web server caching to prevent duplicate requests causing multiple S3 bucket transactions.
With these goals laid out, I began to look for a the be all and end all solution to all of them.
Hugo saves the day
While I have improved on many skills since my old website was built, one skill that remained unchanged was my graphic design ability. Once again I need a solution for a website that isn’t Squarespace, but a static HTML template will not be used again. During my research, I learned about static website generators. A static website generator can generate a single page or an entire website using a template and configuration files. I’m not sure why I didn’t learn about these on my first attempt, but I’m glad I know about them now.
There are a few big static website generators to choose from. Next.js seems to be one of the biggest with the most features. While impressive, there is a lot of features that I don’t need from Next.js. I would like to continue with the very cheap static hosting model that I’ve been using. Hugo was next on my list. Hugo is a relatively young static website generator compared to other options, but it appears that many sites have been moving to it.
Hugo’s biggest strength is the ability to generate fully themed HTML webpage with just a single markdown document. While I can write HTML and understand it, I am no master at it. When compared to HTML, Markdown is very easy to write and I have already utilized it many times writing technical documents. This alone was enough to make me choose Hugo for my static website generator. Hugo also has the ability to run a local webserver and show live changes with each file change. Lastly, I can use hugo and the AWS api to deploy a fully built site to my S3 bucket in a single command.
I needed a theme to use with Hugo, as on it’s own, there is no CSS or HTML layout. Thankfully there are very awesome people out there who are amazing at graphic design and have published some amazing Hugo themes. I decided to go with Hugo-Profile by gurusabarish on github. It is a great looking theme with a resume style homepage that is easy to edit.
I can’t overstate how much easier using Hugo is compared to manually editing HTML files. This was the tool I wish I had back in the beginning. If I want to create a new page or new blog post, it is as easy as creating a new markdown file and deploying.
Commit to having SCM
Over the years, I’ve learned to initialize a git repository for any ongoing project I am working on. While git repos are most optimal for code, any living project with plaintext can benefit from a git repo. I would even do a git repo for cookbook recipes if I was working on one.
Having the ability to manage changes, see the difference between changes, and roll back to a previous version is a must have requirement for the new website. I am always working on multiple different projects at a time, and this website is only one of many. I will not remember what I have changed in the past and a git repo will keep track of that for me.
Using a git repository for change control also allows me utilize cloud git repositories such GitHub. I am only one person working on my own website, so I don’t expect any contributors to be submitting PRs for my website. What I gain is an easy to use interface to see the repo for my website and another backup location.
My current workflow for commits uses git hooks to ensure the website is always in sync with the main repository. When I push the latest commit to the main repository, a script is run to also push the committed files to the S3 bucket and clears the cache in Cloudfront (getting ahead of myself). This ensures that every time I commit to the main repository, the website is updated.
At the time of writing, the GitHub repo for my website is private. I do plan to make it public after I do some additional clean up and sanitization.
Cloud hosting: Part 2
Out of the many mistakes learning opertunites from original site, hosting the content in an S3 bucket is a decision I don’t regret and plan to continue on utilizing for the new site. I was heading in the right direction with my original attempt, but I fell short in a few area and still made some mistakes… I mean learning opertunites.
The first mistake I made was exposing the S3 bucket directly to the internet. While you absolutely can expose a S3 bucket to the inetnet and have users load the files directly from the bucket, I don’t recommend it. Thankfully my original approach did not compromise security, everything was read only and all the files in the bucket were expected to be publicly accessible. The big issue occurred when the old website ever saw a spike in traffic. If you are not familiar with how a cloud storage bucket works, you pay per transaction to the bucket. Every file uploaded and downloaded from the bucket is a transaction. That means, every page load from a web browser was about 5-7 transactions getting the HTML, CSS, JavaScript, and images. These transaction cost a fraction of a cent, but a a traffic spike can add up quickly. The biggest price increase I saw to to high transactions was only a few dollars, but that was a few more than I wanted to pay. A cache in front of the bucket was needed to prevent redundant bucket transactions.
To stay in the AWS ecosystem for ease and cost, I decided to put Cloudfront CDN in front of the S3 bucket. I by no means need a full CDN server for my website, but Cloudfront adds some much needed web server features that isn’t provided from just exposing an S3 bucket.
The biggest benefit and main reason for using Cloudfront is caching. Cloudfront will act as a load balancer to my S3 bucket and cache the most accessed pages. With the most accessed pages cached in Cloudfront, it will not have to pull the content from the S3 bucket, and thus avoid unnecessary transactions on the bucket.
But that’s not all folks. Cloudfront also enables me to much more than just caching. I own multiple domains that are variations of my name. While zachstabile.com is my current primary domain, I would like to also have other domains such as zacharystabile.com redirect to the primary. With cloudfront, I can setup multiple domains with CNAMEs pointed to the cloudfront edge and redirect them to my primary domain.
Can’t forget about error handling either. Cloud front allows me to define how to handle certain web requests and responses. I can set customs html pages and responses codes for 403, 404, and etc.
To summarize why I use cloudfront? I get webserver benefits without having to host an entire webserver. While my average AWS costs did got from $0.78 to $1.64 per month (One less Costco Hotdog per month), the benefits I gained are worth every penny.
The website today
We’ve now made it to the site as you see it today. I’m sure to a professional web developer, my site is a mediocre shell of what a full website should be. But that is okay. I’ve made it very clear the purpose of this is to not show off my non-existent web dev skills. This is just a place on the internet to host my personal accomplishments. I can finally say that this website is what I wanted it to be way back when I made my first attempt all those years ago.