From Heroku to Railway

From Heroku to Railway [This post is a bit of a departure from the usual lofty prose you find here. I was recently forced into some "housekeeping" for a big chunk of my code examples and decided to make the update announcement here. We'll get back to the worldly bits in my next installment -- @mamund] TL;DR Since Heroku turned off their "free-tier" on short notice in November 2022, I've moved my 25+ workshop/book examples to the Railway platform. For attendees and readers using my published books, slides, and training materials, you can basically update any hard-coded URLs in my examples from *.herokuapp.com to *.up.railway.app and things should work just fine. The Full Story A few months ago, Salesforce/Heroku announced the end of their "free-mium" hosting tier. I was a bit miffed by the way SF/H handled this and said so in a socNet post (full thread here). I have lots of workshop students and readers of my books that kinda depend on these running examples. Yes, the source code is available in github but often people need access to a running version of the code w/o the need to download, install, and fire up the source themselves. Heroku was my "Go-To" Host For years (at least seven and likely more) I've been using "free dynos" on Heroku as my workshop/book hosting solution. I keep some paid dynos there to handle more extensive examples and persisted data but most of them are small CRUD-ly apps that carry little-to-no state. I have well over 25 of them just between my two last code-centric books "Design and Build Great Web APIs" and "RESTful Web Clients". I used Heroku for most than just passive hosting, too. In all my API training sessions, I covered the process of not just coding but also deploying solutions to the web and took advantage of Heroku's git-based deployment platform in my classes. Attendees created Heroku accounts and fired up their deployments all in a single lesson. And I've lead hundreds of attendees through this process; in many cases introducing them to Heroku for the first time. The Gravy Train has Left the Station But, alas, SF/H decided to shut down that gravy train late last year. I can understand the challenge, when "free-mium" is no longer a good lead-generation option, companies need to move to other solutions. I get it. What I don't get is SF/H giving users 90 days notice before shutting down the product. For most people (me included) 90 days it not enough time to find new solutions, run tests, and implement migrations. Lucky for me, none of my work is "mission critical" stuff. But I am pretty sure there were a handful of not-for-profits and other generous solutions that depended on Heroku. And a production-level migration in 90 days is a challenge for anyone. A Reasonable Deprecation Process As I pointed out in my rant/thread this past fall, a reasonable approach for closing a product/service on the open web is to provide adequate advanced notice and supply multiple options from which you users can select their solution. In the case of SF/H, I suggest: Freeze the current service offering for one year (no new endpoints) Include support for updating existing projects for at least six months (IOW, you can mod existing projects for a while but eventually, they will be frozen in place, too If possible, provide an open-source solution that someone else can host. That means publishing your code, architect diagrams, etc. so that someone else can pick up where you are stopping. If you can't give away your code (for lots of good reasons), you should at least publish your API interface (via OpenAPI or some other format). This protects your existing internal code but openly publishes the public interface to allow others to build their own version of the back-end from scratch while supporting the establihed interface (API). Finally, you should point your customers to other existing offerings (commercial competitors and/or open source alternatives). Even better, you should provide migration tools that make it easy to hoist code and/or data storage from your platform to the target alternate platform. For those offering hosting options, you should alo provide free HTTP forwarding for at least one year after shuttering your service. This makes it easier for existing customers to arrange a solution at a new location and still support those who are still using the "old" URLs. Yes, that's a "big ask". You asked customers to trust you with their code and data when you invited them to sign up. You owe those customers more than a brusk 90 day notice without so much as a “by your leave”. The Effects of Local vs. Hosted Affect Customers The effects of canceling support on a self-hosted product (e.g. a local text editor) are not the same as canceling support on a hosted solution (e.g. a hosted text editor). In the first case, customers can continue to use the last released version on their own machines for as long as they need it. In the second case (the hosted solution), customers will have the rug pulled out from under them the day you shut down your service When you volunteer to mount a hosted product, you take on a responsibility for your customers. The responsibility lasts beyond the day you lose interest in your product. It last until your customers are no longer in need of your product/service. Being a good host means you don't kick your guests to the curb once you're no longer enjoying the party. Back on Track with Railway After I got the 90-day notice from SF/H, I spent a sevral weeks looking at Heroku alternatives and, after some experiments, decided to go with Railway. It was easy to migrate my existing projects, they have a solid git-based deployment option, and their "free-mium" starter package is easy to upgrade when needed without redeploying my existing examples. In fact, their project model (e.g. multiple services in a single project) is a great fit for the kind of things I do for my workshops and books. It took my a while to work through my 25+ examples (minor updates to code and docs, re-testing, and deployment) and now most all my existing examples are available on the Railway platform. In fact, because of the way I arrangd my deployments, existing users of my example apps can use replace *.herokuapp.com in any hard-coded URLs with *.up.railway.app and things should work as expected. For example, the old sample app at http://rwcbook12.herokuapp.com is now up and running at http://rwcbook12.up.railway.app. This means I also need to change some book content (e.g. my “Deploying” chapter in “Design and Build Great Web APIs”) to reflect the new hosting locations, too. I also need to update my API deployment lessons to reflect the new option of using Railway instead of Heroku. That will take a bit more time. But overall, I'm quite happy with my choice and look forward to working on the Railway platform going forward. Thanks, Railway!