The Judoscale Newsletter - June 2023 Edition
In this issue, we’ll cover some Judoscale updates, the future of Heroku, and the best load-balancing article we’ve ever read.
Happy June!
A long time ago, you signed up for my “Mastering Heroku” newsletter, which sadly never got the attention it deserved. So much has changed since then!
- Heroku shut down their free plans 😲
- Fly, Render, and others came onto the scene as viable Heroku alternatives 👀
- Rails Autoscale (our autoscaling service) rebranded to Judoscale 😎
With all this change, we’ve decided to revive the newsletter and drop the Heroku focus. This is now The Judoscale Newsletter—a monthly(ish) rundown of what we’re excited about at Judoscale and in the land of PaaS hosting (which still includes Heroku).
In this issue, we’ll cover some Judoscale updates, the future of Heroku, and the best load-balancing article we’ve ever read.
Judoscale updates
The past year for us has been focused on our rebrand, redesign, and a rebuild of our backend architecture. Most recently, we’ve given our website a complete overhaul.
As we expand beyond Heroku (more on this below), we needed a platform-agnostic home page. We also built platform-specific pages for each of the platforms we support (or will soon support).
Protip: During our website overhaul, we started with the footer. This was a great way for us to envision the site at a high level, and it effectively gave us a task list to go through and knock out each page.
We’ve also been hard at work on integrations. Not just other hosting platforms, but also other languages and frameworks. Our Ruby gems have been completely rewritten to be more modular, which made it a breeze to add support for Good Job. On the Python side, we’ve added support for Flask, FastAPI, Celery, and RQ!
Judoscale beyond Heroku
We hear a lot of chatter about the future of Heroku, especially since they discontinued their free plans last year. At the time, many folks (especially on Twitter) seemed to be bracing for a Heroku Mass Exodus as everyone left the platform.
It didn't happen, or at least it hasn't yet. Heroku doesn’t publish numbers, but as owners of a popular Heroku add-on, we can say with some confidence that Heroku is doing okay.
Sure, we’ve lost a few customers who have been frustrated with recent changes at Heroku, but overall we’re still growing, and we’re not seeing customers leave en masse.
And we’re still huge fans of Heroku here at Judoscale. Despite our complaints (disappointing customer service, widespread downtime, and the lack of a dyno size between Std-2X and Perf-M, just to name a few), Heroku is still the easiest way to launch and scale a web app in 2023. It’s a bit more expensive than the competition, but as long as you’re using your dynos efficiently, it’s less expensive than many people make it out to be.
Just as an example, here’s a screenshot of our Heroku dynos as I write this email. We happen to be at minimum scale right now (of course we’re autoscaling), but we’re still handling over 1,000 reqs/sec and 10k jobs/minute.
All that said, we’re still not thrilled to have our entire business tied to Heroku. Our customers who have left Heroku for other platforms all want to take Judoscale with them, and we want to make that possible.
We’ve spent the last few months building our integration with Render, which is now live for early-access customers. It’s already cut one customer’s Render bill in half! We’re in the research phase for integrating with Fly and AWS—not yet sure which one we’ll tackle first.
If you’re not on Heroku and need a queue-based autoscaler for web and worker processes, reply to this email and let us know!
The best load-balancing article on the Internet
We didn’t realize load-balancing could be so fascinating until we read this article from Sam Rose. Have you ever seen such a perfect visual representation of the problems with random routing and request queues?
This is why it's so important to have concurrency within each dyno or server instance. The simulation above is limited by each instance being single-threaded. For a Rails application, this means running several Puma workers (corresponding to the number of CPU available) so a single slow request doesn't cause request queueing.
Sam has set the bar for infographics as far as we’re concerned, and it’s a bar we’ll be striving to hit with our own guides.
He goes into much more depth beyond random routing, so definitely read the whole thing.
That's all for now. Have a great month!
—Adam & the Judoscale team