Judoscale’s 2024 Year-End Review

Jon Sully headshot

Jon Sully

@jon-sully

Greetings, Judoscale readers! As we get ready to close out 2024 with some holidays and much-needed rest time, we wanted to take a few minutes to reflect on this year! As a small team of just two (and-a-half!) passionate devs, we often get lost in the development sauce and forget to take time to reflect. So, if you’ll allow us, we’d love to reflect here in public!

👀 Note

Some context for those who’ve never seen Judoscale before — Judoscale is an autoscaling service for developers and development teams that want to get fewer production alerts, have their app automatically scaled up to meet their traffic loads, and want to use tools made specifically for their application stack. Judoscale was created by Adam in 2016 and expanded to add a second developer in 2021. It’s been a two-dev shop since! We read all of our emails ourselves, handle support and integration questions personally, and keep our calendar open for a call any time.

If you want to learn more about autoscaling, we recommend this ultimate guide, and otherwise recommend our blog, where we’ve spent hundreds of hours personally researching and hand-crafting each post from scratch. No AI here!

So how’s our 2024 been? Let’s dive into some numbers!

The Autoscaling

First and foremost, it’s a neat statistic to hear: we executed over 17 million autoscale events this year (so far!). That is, we identified (in real time) a particular process or service that was outside of its ‘happy’ metric ranges and issued an upscale or downscale directive to fix that. Seventeen million! And each one either alleviated growing pressure from traffic hitting that app (upscale) or saved someone money by lowering the number of provisioned services when current traffic didn’t need the extra capacity (downscale).

Fun fact: our largest single autoscale event this year was upscaling by 80 Heroku dynos at once! This was for one of our customer’s background-job processes aptly named backfill_worker. Sounds like a ton of back-fill data to churn through!

While our autoscaling algorithms run in background services (constantly), our web servers also did quite a bit of work this year! Whether it was receiving real-time metrics from applications, serving API requests/responses, displaying dashboard information to our users, or any other types of things, we received and handled over 64 billion requests this year.

We’re also really excited to say that our autoscaling reaction time across the board has been extremely optimized and we’re excited to share the numbers. For customers using the adapter packages we offer (which 90+% do), we can execute an autoscale event within 20 seconds of a slowdown occurring, and only up to 30 seconds in the worst case. In almost all cases, that means applications are autoscaled up before enough slowdown has occurred that users begin to notice. Talk about autoscaling! ⚡️

We’ve also seen growth in the number of teams on board! In fact, we now have over 1,000 teams actively depending on Judoscale to autoscale their applications. So know that you’re in good company. Also, two devs running an application that supports thousands of production services? Pretty good ratio!

A graphic with Judoscale’s 2024 autoscaling stats as noted above

The Architecture

We’re excited to share that we’ve had tremendous uptime this year. While we can’t account for the platforms themselves having API outages (and thus preventing our ability to execute auto-scales on that platform), we’re proud to say that Judoscale has accomplished four-9’s this year: 99.99% uptime. That equates to roughly one hour of total downtime this year. And that hour was actually a single event on May 11th from roughly 9am EDT to 10am EDT. Judoscale has been online and available every moment of 2024 before and after that outage! 🎉

With that, Judoscale has also remained incredibly fast. Our average total response time for the web UI and API is under 20ms 🔥. And our average response time for receiving metrics from customer applications running our adapters is consistently under 10ms 🏎️💨!

We’ve also grown and added multiple new supported autoscaling platforms this year! Judoscale can now autoscale your applications on both Railway and Fly.io! We’ve taken a significant amount of time to carefully refactor and extract out the common autoscaling logic in Judoscale so that adding new target platforms is easier moving forward, too!

A graphic with Judoscale’s 2024 autoscaling stats as noted above

The Blog

We’ve written a lot in 2024! No AI writers here, either 🤖 — each of our posts is hand-crafted, personally researched, and takes hours to produce. We’re proud of our blog! We don’t do much in terms of browser-side analytics for the sake of privacy, but our lightweight analytics (thanks, Plausible!) show that our most popular article this year was “The Post-JAMstack Era: Just Use Rails.” from back in September! The spicy 🌶️ takes really do take off, huh? Second place goes to one of our helpful guides: “An Opinionated Guide to Planning Your Sidekiq Queues”.

OpenGraph Share image of the Jamstack article

Particulars aside, we’ve published 26 new articles in 2024 (this one included). The presses are on fire! From a whole series on Maximizing Judoscale Performance, to a long guide on How to Roll Your Own Autoscaling, to an exposé on how rough Shared Hardware on Heroku can be… we’ve spent a great deal of this year researching, testing, and writing!

OpenGraph share image of the ‘maximizing performance with Judoscale’ article

OpenGraph share image of the ‘how to roll your own autoscaling’ article

The Team

Finally, the Judoscale team changed a bit this year! While it’d been Adam and Jon for a couple of years, Jon (👋) transitioned into a more writing-centric role and Carlos came on board! You might recognize Carlos from the Rails core team, or perhaps from his contributions to Heartcombo’s open source tools (e.g. Devise). Nonetheless, Carlos is a phenomenal developer and thinker, and we’ve been thrilled to have him on board since! We’d been a two-dev shop for a good little while, but now we consider ourselves a two-and-a-half dev shop 😅.

Lastly, we can’t talk about the team without determining the most important metric of all — the favorite team-lunch location! The clear winner is The Cheesecake Factory… but that’s not entirely fair. It’s next-door to the co-working space we meet at. All this really means is that we’re very lazy… 🤷‍♂️

THANK YOU

It’s been fun to take a few hours and reflect on these numbers. These are database queries, system lookups, and metrics assessments we so rarely pull. But they leave us feeling pretty good when we do! Is “17 million autoscales this year” totally arbitrary? Absolutely. But it has a ring to it! “1,000+ teams trusting us”, on the other hand, feels pretty fulfilling. And “99.99% uptime” feels reflective of the many hours of hard work we’ve poured into Judoscale for years.

All of that to say, we’re honored to support our customers and provide a service that folks both rely on and genuinely appreciate.

So, with that, a big thank you for your patronage and being our customers, colleagues, and friends. We love running Judoscale and hearing success stories of costs saved, performance gained, and alerts quashed. We’re looking forward to 2025!

A ‘thank you’ from the team here at Judoscale, for a great 2024