Serverless Website Architecture -- a deeper look

About 10 years ago a realized I could build a “Serverless website” on an AWS S3 bucket. I finally got around to it and wrote up my quick overview (This is my Bullet Proof Website) and I want to go into a little more detail around the how and the why.

So, what do I mean by a “serverless website?” First, let’s define a “server”-- everything on the internet runs on a server of some sort. There are a lot of modern microservice models that let us build compute that is more resilient, but it still means we need to spin up compute units with memory and storage.

I know, “compute units with memory and storage” is a mouthful, but basically it’s a computer. And computers have a lot of things that can fail. You need all the libraries that let your code run, and you need to make sure those libraries are up to date with all the security updates to help keep the hacker out.

What we forget is that we have servers on top of servers. Your typical Wordpress stack has this matryoshka doll stack of servers:

• Operating System: The server itself needs an OS – most of the internet runs on various flavors of Linux but there are still a ton of Microsoft windows based servers. 
• Database Server: Quite often mysql, the dataase is where all your dynamic content lives – blogs, indexes of blogs, tags, etc. The database server runs queries which may be delivered from your programming (see code server) or might be stored in libraries that 
• Code Server: In Wordpress it’s PHP, on Wix it’s node.js, but this layer is what takes the data and makes it usable to the front end. You usually need extra libraries and integrations on top of this to make it available to the frontend.
• Web Server: The web server is the window into this huge stack of servers. It displays the code from the code server which pulls data from the database server, and they all run on that operating system.
• Front End Code: While your browser isn’t really a server, it has compute and memory. Our browsers (Chrome, Safari, Edge, etc.) can do simple data handling and display using javascript, and even when using a big stack of servers like a Wordpress blog, we do a lot of finishing touches using javascript in the browser. 

Now keep in mind there are a bunch of libraries that tie all this together. There are dev tools used to install some components, there are OS configs to relaunch services when they fail, there are user permissions to configure so services can talk to each other and write to the file system…

And it all needs to be kept up to date, sometimes breaking things because updating one system makes it incompatible with another system.

So, when I say “Serverless website” I mean getting rid of pretty much everything in that stack. I’m not saying there aren’t any servers in AWS’s S3 architecture, I’m saying I don’t have to worry about them. There’s a file system in the back, and there’s a webhost on the front, but it’s not a single server that’s going to fail. (AWS promises my data is so distributed it won’t be lost for 100 years…)

The architecture I built is simple:

• S3: Store my files. 
• Cloudfront: Add a custom domain name and secure certificate (also, cache the hell out of my content so I’m not reloading from S3 all the time)
• Front End Code: Do all my searches, dynamic menus and even formatting data using the client (browser). I have to keep my javascirpt up to date, but I don’t have to worry about your browser. 

Now, a quick technical overview:

By naming my S3 bucket ‘www.michaelbissell.com’ I can point a CNAME to www.michaelbisssell.com.s3-website-us-west-2.amazonaws.com and S3 will show the contents as a website as www.michaelbissell.com. This gives me basic web hosting without having to spin up a server. S3 unfortunately doesn't support a TLS (ssl) certificate, but we solve that by putting the whole thing behind a Cloudfront distribution. This provides even more resiliency as the content is now cached.

I’m basically using the filesystem on the S3 bucket as an API. The manifest.json file is an index of all the articles I have on the site. Currently with around 450 articles it runs about 250K – with modern systems (high speed even over mobile and plenty of memory and CPU on devices) this is probably fine for up to about 1-2MB which means I have a ways to go before this model fails.

The articles themselves are stored in markdown in much larger JSON objects, but we only have to access those when we display the article – and this is where exploiting a little trick on the S3 buckets lets me create what appears to be a dynamic site from static content. When I write a new article I post it as a file to the /blogs folder

S3 allows you to define an “error.html” page that is displayed when an object isn’t found. I wrote a javascript driven page that is displayed instead of a 404 page – it parses the URL, pulls the path variables from the URL and retrieves the /blog/{blogsID}.json from the static S3 bucket. If it doesn’t get a payload it writes a nice, friendly 404 error instead.

I don't want to return 404 errors for all my blog content, but Cloudfront allows me to rewrite the 404s to 200s. Yes… that means legitimate 404 errors are returned to the client as OK, but… that's ok with me.

Now, keep in mind, this is NOT new tech at all and I’m by no means the first to implement this, but even though this is tech that’s been around for at least 10 years, most of our web apps are still built on the huge stack of OS->Database Server->Code Server->Web Host.

It shouldn't be that hard to separate technically, but it seems to be really hard to do it mentally…. I'll write up my client-side content management system next (spoiler: it's a node server that reads a local copy of the same filesystem and manages the manifest and blog json objects) but by separating the editing and management of the data from the stack that delivers that content to end users allows me to dramatically reduce the security risk and management of an archaic, and unnecessary stack of servers.