Judoscale: One-Click Autoscaling for any hosting platform ✨

Greetings, Judoscalers! And a very happy Turkey-week to all of you. As winter looms ahead and the warm summer days seem to be behind us, the Judoscale team hopes that you have a lovely Thanksgiving with family, friends, and at least one tryptophan-induced nap 🦃

For our non-US-based friends, we still hope that you have a wonderful week and get some time with family and friends 😅

In the meantime, we’ve got some great updates and insights for you to slowly ponder while you relax 🙂. Check it out:

• 📝 Scaling Sideways: Why You Might Want To Run Two Production Apps
• 🤫 Heroku Direct Coming Soon
• 📝 Process Utilization In Rails: How We Actually Track That
• 🎙️ Podcast: Adam on the Ruby on Rails Pod
• 📝 (ICYMI) Dealing With Heroku Memory Limits and Background Jobs
• 🔢 Judoscale’s Database Connection Calculator

Let’s dive in!

📝 Scaling Sideways: Why You Might Want To Run Two Production Apps

Judoscale is the best autoscaler around, but we can’t magically split your production app in two! Thing is, you might actually want to consider doing that... we laid this idea out in a phrasing we dubbed “Scaling Sideways” and enumerated through the many upsides it brings! Frankly, there are few reasons to not take this approach if your application meets any of the criteria described within (and, realistically, almost all apps do). This one’s worth some serious consideration! Check it out here:

🤫 Heroku Direct Coming Soon

An early heads up for our newsletter subscribers... we’re currently building out support for “Heroku Direct” accounts / teams. That is, running Judoscale for your Heroku-based application(s) but doing so outside of the Heroku Add-On and paying via direct-billing rather than Heroku’s aggregate invoicing.

If that sounds like something you’d be interested in or would like to hear more about, let us know by just replying to this email! We’d love to get you connected early and saving even more money with Judoscale!

📝 Process Utilization In Rails: How We Actually Track That

The third edition of our three part series has finally landed on the blog! Where part one (“Autoscaling: Proactive vs. Reactive”) covered the high level ground-work of when an app might prefer to use utilization-based (proactive) autoscaling, and part two (“How Judoscale's Utilization-Based Autoscaling Works”) covers some fundamentals around what idle-time is, part three is here with some real code! We top off the saga by walking through the actual applied algorithms we tested and iterated on to accurately assess your processes’ busy-times. Complete with real-world code samples, excellent visuals, and occasional wit 😉. Check it out here:

P.S. We mentioned it last month, but utilization-based autoscaling is fully live and ready for anybody to activate. Just make sure you’re running a current version of our client-packages and a new option will be available to you in the Judoscale UI. Check out the docs here.

🎙️ Podcast: Adam on the Ruby on Rails Pod

Adam was on another podcast recently (really making the rounds there, Adam!) talking all about Judoscale from a business standpoint — how he bootstrapped Judoscale from the ground-up as a solo dev shepherding a burgeoning SaaS outfit... while still working a full-time job! It’s both a great primer if you’re curious about starting your own SaaS while also being a great nod toward the love and joy of the Rails stack upon which Judoscale is built. Check it out and give it a listen here:

📝 Dealing With Heroku Memory Limits and Background Jobs

Your app hums along fine on Standard dynos…until you add video encoding, giant imports, or some other memory‑hungry job. Suddenly your worker needs a bigger box, and upgrading every worker to Performance dynos feels like buying a school bus because you might carpool once.... Sound familiar?

Luckily Adam took some time to write out a guide and strategy to having your cake and eating it, too: not forking over hundreds of dollars to run memory intensive background jobs while still successfully running those jobs! Inspired by Justin Searls’ need to process video, Adam takes us through a pathway for paying merely pennies while using GIGs of RAM 😎 check it out here:

🔢 Judoscale’s Database Connection Calculator

Ever run into this one?

PG::ConnectionBad: remaining connection slots are reserved for non-replication superuser connections

Because we have. And if you haven’t (um, wow), you probably will at some point! The reality of modern applications, with their autoscaling and background jobs and versatile infrastructure, is that they all still eat up database connections! While you have a little downtime during this holiday season, we hereby recommend that you take a stroll through our Database Connection Calculator and make sure that your database supports the number of connections that your app, across all of its containers/dynos and processes will need! It’s a 10 minute exercise that could save you hours of downtime in the future. Check it out here:

And that’ll do it for this month, friends! Once again all of us here at Judoscale (the whole three of us 😜) hope that you have a lovely Thanksgiving, some good downtime and rest, and a peaceful #production-alerts Slack channel for the next week 😉. Cheers!

— Jon & The Judoscale Team