The Evolution of a Website: From Monolith to Serverless in a Weekend

During a recent weekend, I rebuilt awsgeek.com, the website I use to share my popular hand-drawn diagrams and notes for AWS services. The rebuild was prompted by my desire to simplify both the website itself and its build process. I wanted to migrate the site from WordPress hosted on an Amazon Lightsail instance (love Lightsail BTW) to an Amazon S3 static website built entirely by AWS Lambda.

This isn’t the first time awsgeek.com has been hosted as a static website on S3. In a previous incarnation, I used the Hugo framework to generate the website and S3 to host it. The builds were triggered by GitHub repository events and automated with AWS CodePipeline and CodeBuild.

But this is the first time I’ve used Lambda to generate the entire site and not an external framework or web application. Given the simplicity of the site (more on that later), Lambda seemed appropriate.

Here’s how the build process works after the rebuild:

I drop a file into an S3 bucket, and a few seconds later, the website is updated and serving traffic. Through the magic of AWS events and Lambda functions, images are created and sized, HTML is generated, and the entire site refreshes, all without me having to so much as lift a finger. It’s lovely.

If you’ve seen the website, you’ll know it’s structured very simply and is really not much more than a common image gallery. It consists of a single landing page, index.html, and a page for each of the service diagrams. These pages include both HTML and the image files. There’s not much else to it.

The build infrastructure is also quite simple. It consists of a couple of AWS Lambda functions, CreatePage and CreateIndex, to build the site and Amazon S3 and DynamoDB to maintain state between builds.

The CreatePage function, aptly named, builds an HTML page for each diagram I create. The function is triggered when a PDF diagram is placed in an S3 bucket. It creates the HTML for the page and converts the PDF file into a PNG file, both full and thumbnail sizes. When done, the function stores metadata about the page, including image file locations and the page creation date, to an Amazon DynamoDB table.

The CreateIndex function is triggered when the DynamoDB table is modified. The function scans the DynamoDB table to collect page metadata, then builds the website’s landing page using that data. The CreateIndex function then uploads the completed landing page to the website’s S3 bucket and invalidates a CloudFront distribution that sits in front of the website.

I considered using AWS Step Functions to coordinate this process, instead of chaining it together, but really, this workflow is simple enough that Step Functions would have just complicated it.

These updates have simplified the workflow steps I follow when creating and publishing a new AWS diagram or notes. Where previously I had to follow several manual steps (and would have been lost without my bash history), I now have just a few simple steps:

1. Create a diagram with an iPad Pro and Apple Pencil using the @NotabilityApp.
2. Export a PDF file of the diagram from the Notability application.
3. Upload the PDF file to an S3 bucket.

I’m extremely happy with how simple the new build process is, how much time it saves me, and how little effort it took to implement. A win-win all around.