🤖 Judoscale News: Introducing Judo, The Ninja! 🥷 (July 2024)
July-ke a good neighbor, Judoscale is there.
Howdy, Judoscalers! Hope everyone here in the US had a great 4th 🎆, all in Canada had a lovely Canada Day, and everyone else everywhere is enjoying the warm weather! ☀️
Our New Branding
The keen-eyed among you might’ve noticed our new logo! After more iterations than we care to mention, we finally settled on a recognizable little character to represent the Judoscale name 😎
But we do still have one avenue to pursue... what shall we name our new friend?! If you have any ideas, please let us know! Simply naming it “Judo, the autoscaling ninja” feels.. lackluster! We’ll consider the top responses and make a poll in next month’s newsletter to settle the matter 😁
Anyway, you’ll see this new branding all over our site, app, and other assets! After settling into the name “Judoscale” over the last couple of years, we felt like we wanted to add a little personality to our brand.
We also took a bit of time in the last few weeks to redesign our blog:
Where we now highlight a few impactful posts we’ve written over the years and are trialing some side-by-side scrolling. Sparkly ✨
Maximizing Performance with Judoscale
Judoscale works great out-of-the-box; we’ve always taken the batteries-included approach... but how do you really dial Judoscale’s controls in for your specific app? Our now-finished 3-part series is here to answer that question!
This last edition covers all the details and strategies for tuning your app’s upscale jump count, upscale frequency, and downscale delay. All three being vital tools in the Judoscaler’s tool-belt!
Give all three a read and maximize your app’s performance with Judoscale:
Speaking of Scheduled Scaling...
Honest moment here: we don’t love our current scaling schedule UI. It’s not intuitive... which is perhaps the worst thing one could say about a UI 😮💨. But I bring it up here because I have good news: we’re rebuilding it. We’re starting from scratch, prioritizing intuitive understanding as the most important metric for its success (as far as UI success goes), and demoing different patterns right now. Here’s an example of a hover-over calendar-style UI:
And we may or may not land with something similar to that (TBD!) but, if you’re interested in being one of the first beta-users for this feature, we’d love to expose it for you! We’re hoping to make scheduling autoscaling a breeze.
All The Queues!
One more quick feature update that you may be interested in... especially if you’re spinning up new / smaller projects, or just have a background job architecture that’s all-things-everywhere! You can now set your background job processes to monitor “All queues” for autoscaling:
So you no longer need to go through a potentially-long list and click all the queue names. It’s a small thing, but this will be a big quality-of-life improvement for several of our users!
Bull and BullMQ Join The Party!
We added a few new supported frameworks back in May, but we’re excited to announce another: Bull and BullMQ. The Bull ecosystem is now fully queue-time-autoscalable with Judoscale. We can’t wait for our Javascript clients to start taking advantage of this!
BullMQ is a rewrite of the popular Bull library by the same authors, but with a new API and a more modern codebase written in Typescript and with a bunch of new features and performance improvements.
Run all the jobs!
Rails World and Chill?
We mentioned it a couple months ago, but the Judoscale team will be at Rails World this coming September! If many of you are also planning on attending, we’d love to put together a Judoscale-sponsored Happy Hour. Any takers??
And that’s our wrap-up for July 2024! Hope you all are having a great summer and enjoying time with family, time outside, or any other way you find fulfillment and enjoyment in your days! ☀️ Catch you next time!
Cheers!
— Jon & The Judoscale Team
P.S. We decided to let our opinions out into the world (yikes)... and wrote “Planning Your Sidekiq Queues” — a blog post all about how to setup your Sidekiq architecture and logical structure (queues), opinions included! We sought to give opinionated, but time-tested, answers to:
- “How should our team structure our Sidekiq queues?”
- ”How should I think about spreading queues across Sidekiq processes?”
- “How do I avoid queue back-ups or over-provisioned resources?”
Give it a read!