We recently shipped the most extensive update to Rails Autoscale since we launched in 2017. The star of the update is our complete UI redesign, but behind the scenes, we also have some huge backend changes. We moved our metrics data to a dedicated time-series database, and we rewrote our Ruby adapter gem to be more modular, easier to work with, and better-tested.
Let’s dive in!
The new Rails Autoscale web UI
Our web UI hadn’t changed much since its initial 2017 design. It always had that “designed by a developer” look to it, of course because that’s exactly what it was! I take all the blame for that initial design. 😬
We were ready—beyond ready!—for a truly “designed” UI that we could be proud of. To make that happen, we needed a great designer. Fortunately, I’ve worked with some amazingly talented designers in the past, and toward the end of 2021, we started collaborating on what a new Rails Autoscale might look like.
Here’s where we landed.
What we were previously calling a “dashboard” page, we’re now calling the “scaling” page. We still have the 24-hour overview chart with a zoomable window, but now the data in the focus area is integrated into a single, blended chart. We also added the throughput chart to provide more context to the scaling data.
We included the autoscaling toggle at the top so you can quickly turn autoscaling on or off without going into your settings.
Speaking of settings, we abandoned the separate settings page in favor of autoscale settings integrated into the same page as the scaling metrics.
This integration makes it easier to visualize changes as you’re making them. For example, as you manipulate your “target queue time range,” the highlighted area on the queue time chart is kept in sync.
We also don’t hide the sensitivity settings—“upscale jumps” and “downscale delay”—behind an “advanced settings” toggle as it was before. We’ve learned that these are essential settings that many—if not most—of our customers like to tweak, so it makes sense to treat them as first-class citizens.
Of course, those are just the functional changes to the design. The entire look is brand new. Check out the demo app an see for yourself!
A new home for metrics data
When I was building Rails Autoscale in 2016, I knew nothing about time-series databases. Heck, I’m not even sure what was available back then. So I did what you’d expect: I hand-rolled a solution using the technologies I knew best—Rails, Redis and Postgres.
This solution worked, but had a few scaling issues over the years—we needed to add table partitioning, and we needed to scale up our database several times. It always felt brittle, and it was never fast enough for us.
Last year we started exploring long-term solutions for our time-series data, and we landed on TimescaleDB. I love that it’s built on top of Postgres, that it’s open source, and that they constantly crank out insightful blog posts and videos.
A tremendous benefit of the TimescaleDB migration is how much code and infrastructure we could remove! Previously, we stored raw metrics in Redis, using Sidekiq jobs to perform aggregations, and storing the rollup data in Postgres. Timescale handles all of this for us, along with table partitioning and dropping old partitions—all things we were doing manually before.
But the best part of our new architecture is the speed. We can ingest and aggregate data much faster than before, which translates to better autoscaling responsiveness. We were already much faster than Heroku’s native autoscaler, and now we’ve cut our response time almost in half!
The new Rails Autoscale gems
The third component of this update is deprecating the rails_autoscale_agent gem in favor of a new collection of rails-autoscale-gems.
Our old gem just never got the attention it deserved. It was under-tested, so making changes was risky and stressful, and it bundled all of our background job support together, so we couldn’t have explicit version dependencies on our supported background job libraries.
Our new gems aren’t a complete rewrite, but they’re close. Most of the changes are structural, but we did introduce a few new features/fixes:
- Previously we could not support “worker-only” apps. A web dyno was required because all reporting happened on web dynos. This has been fixed.
- Previously the reporter wouldn’t start until the first web request was received, making it appear that the adapter wasn’t working on low-traffic apps (staging & test apps, in particular). Now, the reporter starts when the app boots.
- We now support long-running jobs (suppressing downscaling when jobs are running) for all job backends.
- We now offer complete control over which job queues are reported.
- Logging is way more configurable.
What’s next?
We’ve spent the last year rebuilding our foundation—our UI, backend, and integration library. We’re ready to start moving forward again, so where are we headed?
Obviously, we’ve bet big on Heroku. Until now, Rails Autoscale has only been available as a Heroku add-on. We still love Heroku and believe in the future of Heroku, but we want to be the autoscaler for every Rails app, no matter where you’re hosted.
Interested? Email me and let me know where you want to use Rails Autoscale!