Migrating my personal website to an event-driven serverless architecture

Date: 2023-07-15

Over the past two years, my personal website (i.e. this site) was hosted on a self-managed cloud server running a traditional LAMP stack (Linux, Apache, MySQL, PHP) with neither elasticity nor redundancy, functioning solely as a stub for redirecting all requests to my GitHub profile. Despite this functionality being as trivial as it could possibly get, the underlying infrastructure was fragile, rigid, costly and difficult to properly manage due to the grossly suboptimal architecture.

Despite the glaring shortcomings of the above architecture, the website was basically functioning as expected so there was little incentive to improve it - after all, “if it ain’t broke, don’t fix it” - until I finally decided to re-design the entire infrastructure this week following inspiration from the excellent AWS Technical Essentials course, this time adopting a fully serverless event-driven architecture.

The current architecture is resilient, secure, elastically scalable, cost-effective and requires no maintenance of infrastructure whatsoever - a complete overhaul of the previous one. So what were some of the motivations and considerations surrounding the adoption of the previous and current architectures? Perhaps a detailed review and analysis of the historical evolution of my personal website is in order.

2015: my personal website was born

I was introduced to programming in 2015 through an extra-curricular activity (ECA) offered at my high school by BSD Academy (now BSD Education) on frontend web development with HTML5+CSS3+JS, for which I also picked up PHP as my first server-side programming language shortly thereafter. At the time, I only had a very basic understanding of fundamental programming concepts and had virtually no concept of IT infrastructure - to me, a server was just some machine hosted in a remote location over the Internet as far as I was concerned.

When I decided to show off demonstrate my newfound programming skills by developing my very own website back in 2015, web hosting through the likes of GoDaddy was all the rage and the go-to option for individual users and small businesses, due to the ease of getting a website up and running without having to manage servers by oneself. Furthermore, the main offering by GoDaddy back then was a LAMP stack where the developer was only responsible for uploading HTML5+CSS3+JS code and static web assets, possibly along with PHP scripts for generating dynamic content and optionally interacting with a MySQL database managed by GoDaddy, all via a user-friendly web interface such as cPanel.

While this was the most sensible option at the time given my ability and interests back then, there are a few key disadvantages to this model:

• The software stack is determined entirely by the vendor and developers are limited to the framework(s) and programming language(s) provided therein
• The architecture is rigid and non-scalable - during a sudden surge in traffic, the server would be overwhelmed. Furthermore, to handle possible spikes in traffic, a larger server needs to be rented and the program code + data may need to be migrated to the new server automatically or manually, depending on whether the vendor supports automatic migration of code + data between servers
• The rigidity of the architecture implies that over-provisioning is necessary - a sufficiently large server capable of handling peak traffic needs to be rented upfront for a fixed period of time, e.g. 1 year, which is a waste of both money and resources

Nevertheless, my website would be hosted on GoDaddy for the years to come, until a course offered at my university opened me to the world of cloud computing and I decided to migrate my website to the cloud.

2021: migrating to the cloud

My professional interest shifted from software development to primarily operations and maintenance of IT infrastructure when I was first introduced to Linux mid-2020 through an internship at M-Labs for which I swiftly developed a strong passion towards and earned my first professional LFCS certification shortly thereafter in July 2020, now set to expire in July 2023. This enabled me to properly understand the underlying technology stack and infrastructure powering my website on GoDaddy for the first time, though my website still remained on GoDaddy with lack of a better hosting alternative due to a missing piece of the puzzle - cloud computing.

After my internship ended in late 2020, I returned to HKUST for the final semester of my Computer Science degree where I took a course on cloud computing offered by Prof. Wei WANG which opened me to a whole new world of possibilities - in particular, the concept of spinning up an EC2 instance on AWS and getting a full-blown Linux system up and running in minutes was what really intrigued me at the time. What could possibly be better than getting a Linux system up and running in minutes, then getting my hands dirty by installing, configuring and setting up everything myself?

With the operational flexibility offered by Amazon EC2 (later migrated to Alibaba Cloud ECS in early 2022 due to non-technical reasons), I was no longer limited to the software stack offered by GoDaddy - instead, I could develop my website using the framework and programming language of my choice, install and manage the necessary dependencies myself, and manage OS and software updates at my own pace as well as SSL certificates using Let’s Encrypt and Certbot at no additional cost. So I stumbled upon Spring Framework written in Java and decided to give that a try.

It was fun and exciting developing my own website using the framework and programming language of my choice and deploying it to a cloud server fully managed and maintained by myself, while the novelty lasted. Once the novelty wore off, it became a pain, a maintenance nightmare:

• Both Spring Framework and Java itself were verbose and cumbersome, and I found it difficult to learn beyond the very basics, so I quickly lost interest in it and subsequently the continued development of my website
• The way I decided to package and distribute my website using Snap meant that every time I updated my website, even if just for updating the static HTML content, I had to re-run all the commands for building the Snap package on my local workstation, upload it to the Snap Store and wait for automatic Snap updates to pull the updated website to the cloud server - a tedious and time-consuming process which further reduced my interest in continued development of my website
• I had to log into the server every once in a while to apply OS and software patches and updates, or write a cron job to perform updates automatically and reboot the server on a fixed schedule, the latter of which eventually proved to be fragile and lead to manual updates ending up broken for some unknown reason
• Every once in a while, I would re-install the OS on my laptop (typical of a new Linux user (-: ) without backing up my SSH keys, so I would need to generate a new SSH key pair … and get locked out of my cloud server. This meant that I had to replace the cloud server and repeat the entire setup process manually every time this happened
• Since my personal website doesn’t receive traffic all that often, the cloud server was idle some 99% of the time, yet I had to keep paying for resources such as CPU, memory and elastic IP address occupied by my cloud server, a serious waste of both money and resources

Before long, I decided to ditch my website written in Spring entirely, and replaced it with an Apache web server acting solely as a stub for redirecting all HTTP and HTTPS request to my GitHub profile. Stuff that I might as well have achieved using GoDaddy, but with increased operational and monetary overhead. So at best, I was back to square 1:

• A traditional LAMP stack
• High operational and maintenance effort required
• Rigid architecture difficult to scale automatically
• Tremendous waste of computing resources
• High operation expenses (OpEx), i.e. wasted money, despite not really doing anything useful

Nevertheless, I stuck with this grossly suboptimal architecture for way longer than I should have due to inertia, despite having learned about the various potential benefits of managed cloud services such as elastic scalability, built-in fault tolerance and automatic security patching by going through a series of cloud-related courses and certifications since early 2022.

2023: embracing serverless

That was until I revisited the concept of serverless functions near the end of the excellent AWS Technical Essentials course just last week. All of a sudden, everything clicked into place - for a personal website with a low average visit rate and possible unexpected spikes in traffic that only needs to respond to stateless, short-lived web requests and doesn’t warrant ongoing maintenance of infrastructure, wouldn’t an event-driven serverless architecture using functions be a perfect fit for this use case?

So now I have an architecture that is excellent from the development, operational and financial perspective, which also happens to be extensible and future-proof:

• From a development perspective, developing and maintaining each feature in separate functions promotes modularity and separation of concerns, easing the development and iteration process
• From an operational perspective, the current architecture is automatically fault-tolerant, secure, elastically scalable and requires no maintenance of infrastructure whatsoever, which is exactly how a personal website should be
• From a financial perspective, I can finally take complete advantage of managed cloud services by paying only for CPU, memory and network traffic my website uses when serving requests to visitors and only pay for a negligible additional fee for the continued storage of my static web assets the rest of the time

Also, by utilizing Python-Markdown to convert Markdown templates to HTML on the fly, I can place complete focus on content when authoring long, technical blog posts like this one by writing them in Markdown and uploading them directly to Alibaba Cloud OSS when ready, instead of wasting time wrestling with HTML tags, CSS styling and page layout.

Another major advantage of utilizing Alibaba Cloud Function Compute (with OSS) as the backend and placing them behind an API Gateway is extensibility - it is simple to implement and expose new functionality for my website whenever desired by writing a new function and attaching it to the gateway via a new API, or even attaching a completely different set of cloud services to the gateway as a new API if required.

Concluding remarks

So this was an architectural overview of my personal website and how it was designed to leverage the advantages of modern managed cloud services, but we haven’t really touched on the development perspective in this article.

I hope you liked this article and stay tuned for my next article focusing on the development aspect of my personal website re-design which should be out in a day or two :-)

Subscribe:

Return to homepage