Right Sizing Tech

We live in an era of scale. Most things in software have to be large to be interesting. We’ve seen the explosion of microservices, pipelines, and all sorts of other things. Those things can be great. But I cannot help but feel that growth in the number and complexity of the tools we use lead to many of us being too separated from the problems we’re trying to solve.

Software, especially cloud-native software, has gotten to an amazing point where we can quickly build things in a weekend that would have taken months not too long ago. We have amazing web frameworks like Phoenix that are simple to use, scale well, and keep piling on incredibly functionality like LiveView every release. We have tools like SaltStack that let us manage and configure hordes of systems easily. But with these tools at our fingertips those often become the ones we reach for without thinking.

Last year I had the pleasure of leading up tech for A3C, in its 15th year it hosted 30,000 attendees from all over the world to celebrate Atlanta’s Music, Art, and Film. The conference had grown significantly in the past few years and the new ownership group was looking at continuing that trajectory. The tech stack was in an “ok” spot, but it was cobbled together and relied on quite a few outside vendors that added up to a serious part of the budget.

We needed to have a web app as well as mobile apps for both ios and android. I could have reached for Phoenix to handle our needs, both for the cloud API as well as the web app. But when I looked at what our needs actually boiled down to, and looked at how infrequently our data changed I was able to simplify things quite a bit.

Our data was mostly around speakers and artists, and the schedule of the conference, so it didn’t change very often. Our apps (written in react-native to for time savings and simplicity) also had little interaction with our servers. We also wanted to support offline mode anyway due to the way that cell networks can get overloaded and slow around a festival side.

With these things in mind I dusted off a Terraform script to bring up static sites, and turned to Hugo. Hugo is a delightful framework for building static pages. It is incredibly fast at rebuilding the site after changes and it has some great features, such as image resizing, baked right in. What most of its users don’t realize is that it can generate static “APIs” as well. We made the tradeoff to generate the JSON API responses ahead of time and host them along with our web content. This was served from simple S3 buckets with a cloudfront distribution in front of it. For less than $200, and most all of that bandwidth cost for serving our high resolution photos we were able to service all of our festival attendees with the minimal amount of tech necessary.

This setup also meant that I didn’t have much of anything to worry about regarding security or uptime. It was all just statically generated JSON and HTML. We were only going to have a problem with Amazon’s S3 service went down, and that is a gamble I was more than willing to take given our time, budget, and overall mental load savings. And as you can see from the Google pagespeed image in this post, pages server blazingly fast.

Don’t forgot about the tech that is underlying all the massive things we’re building. The folks who created the internet and the web gave us a lot to work with. We’re best off not forgetting how far we can stretch those before reaching for something else.