91–100 of 114 posts
* Import my current Heroku config into Terraform resources so I can co-ordinate changes across multiple platforms as a single atomic change. * Embrace a strangler pattern (https://www.redhat.com/architect/pros-and-cons-strangler-arc...). I used Cloudfront, but you could put any CDN in front.
* My databases + workers were a large part of my Heroku bill, and I had a very spikey usage profile (potentially days with near zero usage, with brief peaks), so I used it as an opportunity to refactor towards a serverless infrastructure (https://www.redhat.com/architect/pros-and-cons-strangler-arc...). This was entirely superfluous to the migration though. If I'd not taken that approach the alternate would have been to provision and RDS Postgres instance, add the required IAM profiles to my Heroku app. Work out how/when to schedule a window to cutover to RDS being the primary DB. Update the DATABASE_URL accordingly. Again, doing all of this via Terraform to make it happen. But doing it in small incremental steps where possible (i.e., adding the IAM profiles to the app first). Once cut-over, take a final snapshot of the Heroku Postgres database and then shut it down.
* Updating the code on my workers to be idempotent.
* Make sure config vars are imported to Terraform and are sync'd to the various places they need to be (probably just the Heroku app for now).
* Have the workers run inside containers on AWS (doing them just one worker at a time), exposing the required config vars for them to work. Let the Heroku + AWS workers both process the work for a period of time, hence the need for being idempotent. Once I'm confident the AWS ones work as intended, shut down the Heroku workers.
* Picking off individual paths/API endpoints to serve from AWS. In my case I also migrated all of this to API gateway + lambda. An ALB with EC2/ECS would have also been an alternative. Add a new path based route to your CDN (e.g., /v2/the-existing-path) and have it's origin point to your non-Heroku service. Test it. Once it works, update the existing path that users are using to now go to the new origin. It means if you discover some issue you can quickly update the routing to have Heroku resume serving that route. Once you're confident, rinse and repeat the next path. Continue through until all traffic is ultimately served by the new host.
* If there's nothing left then scale down the remaining processes on Heroku.
I've gone an all-in AWS approach, but the same general principle could apply to whatever platform you want to run on. I think the biggest thing people I've spoken to in the past about this overlook is that you don't have to make some big wholesale switch. There's ways to derisk it and take an incremental approach to migrating. Which also drastically reduces the cost of making the wrong decision. If you can run just one route through AWS/Fly/DigitialOcean/whatever then you can get a sense for whether it will _actually_ work for your needs, and quickly roll back if you change your mind.
Earlier quoted context omitted.
Forget little bugs... the big picture is far more important. I cannot recommend anyone use this product given recent (years) inattention. Since you work for Heroku / Salesforce, letting your users know if this is a dead product or not would be a good first step. If not dead, explain why there have been no updates and what is to be expected moving forward.
Heroku is very much alive. On your comment about what is to be expected.... stay tuned. Given that, I also don't want to forget the little bugs, I believe they are important to a great user experience. I think this is true for any product, but especially true for Heroku.
I was pretty unhappy with the outage last night. All the user blogs for https://bearblog.dev went down for about an hour and a half (and I had so many emails to respond to this morning). I'm looking to move Bear over to either a Digital Ocean droplet (I have the staging server running on one with SQlite and Litestream running, and believe it could actually scale well), or to Fly.io (to be seen).
I am not very familiar with any of these, but here is the short list of things I've compiled from past HN threads, that might be alternatives to heroku that provide similar affordances to heroku. Most of them I have done no more than look at the website and determine that, yeah, it was similar to heroku for my personal criteria of what makes something similar to heroku. (Some things suggested in past threads did not…
Render.com - we use this for production at Grilla. Great experience, great platform. I wish I could pay them money to have my builds go faster but everything I want out of the box in places where you would think to look for them first. Fantastic dev ux. Never said, fuck I wish I had this and couldn't find it.
Fly.io - still extremely rough around the edges and militant about things that most companies don't really care about. For example, you create your database, and you see the credentials once and only once. You didn't save them? Tough luck, delete your database and create a new one. Just a lot of sharp corners. Same with ENV vars, you can only set them not see them. Which is ridiculous. Hey my payment processor isn't working, the webhooks aren't coming in, let's debug check the webhook env var, what you can't see it? Ugh.... They are most likely working very hard on the fundamentals of the hosting platform, but they need a lot of work on the dev ux.
Railway.app - Sexy as fuck, will potentially tear me away from Render on my next endeavor. These guys are taking everything that's shitty about hosting apps and making it simple. One thing I did miss was being able to ssh into a running container to run an elixir console into the running process. But for everything else, they are right on the money and gaining quick.
I left Heroku in favor of just a hand-configured DigitalOcean droplet. I might try Fly.io but honestly, for what I’m doing, the flexibility of a full Ubuntu box is just too good, even in 2022.
Try Debian if you want everything almost the same as Ubuntu but without the bloat. Everything is faster. What it lacks in branding/marketing, it makes up for it in the speed. Also recommend FreeBSD.
Earlier quoted context omitted.
Forget little bugs... the big picture is far more important. I cannot recommend anyone use this product given recent (years) inattention. Since you work for Heroku / Salesforce, letting your users know if this is a dead product or not would be a good first step. If not dead, explain why there have been no updates and what is to be expected moving forward.
Heroku is very much alive. On your comment about what is to be expected.... stay tuned. Given that, I also don't want to forget the little bugs, I believe they are important to a great user experience. I think this is true for any product, but especially true for Heroku.
Doesn't look well received, Heroku is a dead product for devs.
Today I went to restore a backup from three weeks ago on a new test instance and I saw it broke. I was getting some utterly weird messages about the pgcrypto extension not being available anymore (problem since I use UUIDs as my ids). After HOURS of messing around I found this https://devcenter.heroku.com/changelog-items/2446 . None of which was communicated to anyone, and it completely breaks all old backups. There'…
Yep. I am getting pretty good support communications on this issue in heroku support tickets (you are not?), but the fact that they haven't actually made a public announcement about it is pretty unforgiveable. Last I heard from support, they thought the issue you are running into with backup restores would be solved maybe in the next week or two... but there is no public place to look for status or resolution, I just…
The issue they say this was to mitigate is this CVE https://www.postgresql.org/about/news/postgresql-145-138-121... which seems extraordinarily difficult to exploit (oh, and they don't address in already active databases... so....).
Very much throwing the baby out with the bathwater.
Plus the "we're shutting down all your stuff" message today makes me scrambling for another service.