I’ve been playing around with AWS S3 backed static websites for a while now and have mixed feelings about whether or not I like the static way of creating and deploying websites. Static website hosting definitely has its merits but how they are deployed requires a different way of thinking if you aren’t used to doing Infrastructure as Code. Here are some random thoughts on my experience learning how to deploy static websites using Hugo with AWS S3.

As I was researching how to create and deploy static websites using Hugo the first thing that came to mind was, “Wow, what an incredible pain in the ass!” I’d been a faithful WordPress user for many years, having deployed countless installs and associated infrastructure from scratch as well as numerous themes so this static website stuff felt foreign and odd. Going from the comfort of an established platform to having to use (and learn) Git was the first hurdle followed by actually having to know my way around HTML, CSS, and JS was the second. It’s not that those hurdles were difficult per se, it just felt like a lot to have to know just to get a basic website up and working. “Why the fudge would anyone want to do it this way?” was the question that I kept asking myself. I almost gave up completely because it felt like an incredible waste of time when you can just shell out a nominal, monthly fee for a managed WordPress or Ghost service that includes decent themes and a plethora of plugins to get you up and running relatively quickly.

I remember going to the Hugo Quick Start mothership and feeling a surge of confusion. The idea of running a server locally on my laptop while I write posts seemed so foreign and stupid. I played around with some of the really good Hugo themes and finally got something working—hurray! But I still didn’t understand how Hugo was actually generating the pages much less how the pages, themes—specifically exampleSite, and my site were supposed to work.

After a few days of playing around with a few different themes I finally got my site setup—locally. The next step was deploying to AWS which fortunately I’m pretty familiar with. Feeling a bit adventurous I decided to play in unfamiliar territory, namely AWS Lambda and AWS CodePipeline using Eric Hammond’s Git-backed static website powered entirely by AWS CloudFormation template. I immediately learned that I was out of my skill set but was able to get my site live on AWS after a lot of messing things up and some help from Eric himself.

While I could keep going and provide a play-by-play of my experience, I don’t want to bore you with the details of how many things I realized I didn’t know crap about and all the things I screwed up. What I will say is that the experience was an eye opener to say the least. But before I knew it, I was using Git like a boss, pushing changes to AWS CodeCommit and Github, and even running my own pipelines for other projects. I learned so much without realizing that I was learning.

Now that I’m a seasoned “pro” you’d think that I’ve converted to a static website evangelist but unfortunately, I still think running a static website is an incredible pain in the rear—for most people. If you have paying customers (especially the non-technical ones) that need a basic company website there is a good chance that a traditional CMS (Content Management System) like WordPress will be the better choice. However there are use cases where static websites will save you time and hassle so learning how to deploy them are akin to adding a new tool to your IT toolbox.

I come from an InfoSec / Infrastructure background and didn’t really need to focus (i.e. didn’t get paid) on building applications. Terms like CI (Continuous Integration), CD (Continuous Development), DevOps, containers, etc. just sounded like buzz words that would be gone tomorrow. Fast forward to today and those terms are now actually well paid skills that you’d better be proficient in or else become an IT dinosaur. I didn’t want to become an IT dinosaur and was starting feel a lack of understanding in application security so I got onboard and started learning—creating and deploying a static website for my blog seemed like a great place to start which in hindsight was a smart move.

What’s been most interesting about running static websites compared to the traditional methods (eg. server, LAMP stack, etc.) is that both are a pain but in completely different ways. In my case, automating the infrastructure deployment for WordPress was easy but creating or even modifying the CSS, HTML, and JS for a responsive website wasn’t. Of course I knew how HTML and CSS works in theory but in practice it’s a whole different story when you have to figure out how to make what seems like the simplest changes (e.g. center a box) work on a desktop, tablet, and smart phone browser. I imagine it’s the opposite for folks (i.e. developers) that have had limited to no exposure to IT infrastructure and live and breathe in code everyday.

So why do I have mixed feelings about static websites despite the new level of IT enlightenment that I’ve obtained? The most popular value proposition of S3 backed static websites is that they are cheap. I’m talking cheap as in almost free. Did I mention that you don’t have to manage servers either? While there is always a server somewhere, you don’t have to worry about installing, maintaining, and securing one. But while these are obviously pretty awesome merits, once you start needing functionality outside of basic webpages and blogs, you’re going to start needing to purchase or build extra functionality assuming it can even be done on a static website. For example, need CMS functionality? You’ll have to either buy it from a SaaS provider or have it built; the cost for either one might give you sticker shock. If you aren’t careful, the cost savings of not having to manage infrastructure will more than likely be replaced or even exceeded with development costs depending on your use case. There’s also some gotchas—for example S3 website endpoints do not support HTTPS as an origin and that might be a show stopper depending on your industry.

I’m not surprised by the shortcomings of static websites but I’m starting to notice a trend on how AWS S3 backed static websites are going to be the answer to “legacy” platforms like WordPress. While I probably will cry in my champagne glass when I never have to maintain some of the legacy platforms, I don’t see it happening anytime soon. WordPress has well over 50% market share in the CMS space and PHP (the server side language that powers WordPress) has over 80% according to W3Techs. Working in IT involves using technology to gain speed, improve quality, and lower costs for your organization but the catch is that you can generally only have two at the same time and static websites are no exception. My prediction is that AWS will expand on the S3 static web hosting functionality once they sort out the current S3 bucket naming challenges and DNS constraints but its unlikely to be a priority anytime soon unless customers start screaming and yelling for it. For now though, it’s an excellent alternative to create and host websites on a budget while learning some new skills—at least for people like me.

If you liked this post please click Follow @virtualjj and say hello!