New year, new blog!
After 9 years of self-hosted WordPress on EC2, I'm finally converting my blog to Eleventy and deploying it to AWS serverless services with Ampt.
Happy New Year, everyone! πΎπ₯π
I've been blogging since early 2015 (almost 9 years now!), and like most folks, I started by deploying to WordPress. Being the AWS power user that I was, I thought it would be a great idea to host it myself on EC2, set up an RDS cluster, and be responsible for everything.
When I had a post end up on Hacker News, my little EC2 instance fell over very quickly. So I decided to add a load balancer and spin up multiple EC2 instances with auto-scaling configured just in case lightning struck again. This setup has saved me several times since, but at the cost of an inflated AWS bill and a tremendous amount of unnecessary complexity.
Static + Serverless is the way
Serverless was just becoming a thing back in 2015, so it wasn't really an option at the time. However, as it's matured over the years, I've been wanting to convert my blog into something much more serverless. There have been fits and starts over the years, but I always found myself worrying about the power I'd lose by moving away from something as mature as WordPress. The vast collection of plugins available in the WordPress ecosystem meant giving up features, manually connecting other third party services, or rebuilding them yourself. At the end of last year, I finally decided to make the leap.
Several years ago I discovered Eleventy. It's a "simpler static site generator" that's 100% JavaScript-based, incredibly flexible, and supported by a growing community. After playing around with it for a bit, it became my favorite go-to option. I used it to build sites for the Off-by-none newsletter, then the Serverless Chats Podcast, and most recently, Ampt and its documentation.
I get that static sites (SSG) can be a bit limited, but that is largely a function of where they're hosted. Both Off-by-none and Serverless Chats are currently hosted on AWS Amplify (the hosting service, not the framework). It's been a great option. Fast, reliable, and inexpensive. However, it's a bit limited when it comes to adding dynamic functionality without going all in on the Amplify Framework (which I don't want). I know there are plenty of PaaS providers out there, but I want my projects to be backed by the reliability and operational excellence of AWS.
When we built the new Ampt website, we decided to dog food our own service, and deploy the Ampt site to AWS with Ampt. Becoming our own customer was not only a great way to ensure service quality, but it also gave us the unique ability to remove all the unnecessary friction when deploying websites to AWS serverless services. And we did some pretty cool things!
Why Ampt?
Obviously I'm a bit biased, but my experience building and managing the Ampt website has convinced me that doing it any other way is simply a form of masochism. Ampt's goal has always been to deploy workloads to AWS using the best possible "patterns" available, and more importantly, to automatically select and manage those patterns on behalf of its users. Some patterns are easy to implement and manage, some are really hard.
The pattern we use for static asset routing falls into the latter category. We use a combination of Amazon CloudFront, Edge Functions, S3, Lambda Function URLs, and more, to allow dynamic routing to both static and on-demand resources. This means you can do really cool things like statically serve some pages while dynamically generating others. You can serve your API routes from the same domain as your static pages without needing to explicitly set origins in your CloudFront distributions. And you can do this without writing a single line of configuration.
If you want to use frameworks that support Server-Side Rendering (SSR), like Next.js, Nuxt, Astro, Remix, SvelteKit, and others, Ampt fully supports those as well. You can even mix your backend workloads into the same app, giving you all the power of AWS and Ampt running alongside your fullstack JavaScript application.
What's next?
If you're reading this in early January of 2024, you've probably noticed that this site is a bit of a mess. I wrote a script to convert all my old WordPress posts to markdown files, did some clean up, and put together a simple template layout. It needs a lot of work and is missing a number of things. I knew that if I waited until it was "perfect" that I'd never publish it. So I present it to you in all its messy glory.
"Perfect is the enemy of good"
I'll be working to polish this when I have time, but I'm much more interested in writing more, so no promises. I hope it's at least readable for now, and I look forward to sharing progress as I make it. Your feedback is always welcome and appreciated!