Heroku has been running a second copy of my scheduler instance
1–10 of 132 posts
Re: Heroku has been running a second copy of my scheduler instance
#2Similar thing happened to me. Took a long time to realize there was a zombie Heroku instance running jobs.
That horror when you delete code but it's still running, you're just so confused...
I've forgotten how I resolved it, but man it was a pain to diagnose.
Re: Heroku has been running a second copy of my scheduler instance
#3Everyone can relate to the sad demise of Heroku at this time. Sad, because they could've dominated this space which still has a lot of issues.
Yet-another-infrastructure-group nailed it in their graphic about "what your infrastructure says about you?"... "Heroku => "You are either negotiating the pricing or deplatforming" https://www.yaig.dev/
Re: Heroku has been running a second copy of my scheduler instance
#4This is why I use the git commit short hash as part of the identification of the service (eg: container name).
Allows for quick check of which is the running code version and identify problems like these.
Re: Heroku has been running a second copy of my scheduler instance
#5This is why I use the git commit short hash as part of the identification of the service (eg: container name). Allows for quick check of which is the running code version and identify problems like these.
That’s smart. I like it.
Re: Heroku has been running a second copy of my scheduler instance
#6If Heroku is running some zombie instance of your app, what if you were to just kill the instance you control and let Heroku run the zombie instance? When your service goes fully down, you'll know they've killed the zombie instance, so you can then run a clean copy.
Re: Heroku has been running a second copy of my scheduler instance
#7Author and me have so much in common. From journalism to software engineering and our formative career shift years were spent on home made music apps. Now I’m wondering just how many of us are out there.
Re: Heroku has been running a second copy of my scheduler instance
#8Clearly the author still hasn't learned his lesson: his "no more vendor lock" solution is another vendor(s) - which is always able to vendor-lock him, again.
It is truly mind blowing on how many people keep falling for one of the oldest trick in IT : vendor lock-in.
===
No more vendor lock In 2018 Heroku was pretty much the only option for a newbie like me to get started with web-development. The landscape is very different now with providers like Render, Railway, and more
Re: Heroku has been running a second copy of my scheduler instance
#9In case it's not clear from the article, Nixpacks build OCI (essentially, Docker) images, so they are perfectly vendor neutral as far as I know. The ending ambiguously implies that Nixpacks may be undesirable vs using Docker, but actually it's just another way to build an image. Fly.io supports Nixpacks out of the box too, I believe, which makes it even easier to use them with Fly (although, you can also just push an OCI image directly to the fly.io registry and deploy with that, which I have been experimenting with in spare time as an option for using Nix itself to build an OCI image for Fly. I'm sure there will be an even nicer way some day, but it works for now...)
I'm sure the author knew this, but I wanted to iterate it in case anyone misunderstood.
Re: Heroku has been running a second copy of my scheduler instance
#10Clearly the author still hasn't learned his lesson: his "no more vendor lock" solution is another vendor(s) - which is always able to vendor-lock him, again. It is truly mind blowing on how many people keep falling for one of the oldest trick in IT : vendor lock-in. === No more vendor lock In 2018 Heroku was pretty much the only option for a newbie like me to get started with web-development. The landscape is very di…
So what should he be doing, building his own data center?