Hacker News Reader

Comment by ksajadi | Hacker News Reader

the progression from Heroku to AWS is very common as SaaS businesses grow. However one thing that’s missing from all “alternatives to Heroku” is what I call life after deployment or Day-2 operations. Many solutions show you a sleek demo of how easily you can deploy a Hello World app to their platform but leave you in a straight jacket when it the app is deployed and you need tools to keep it running, like changing an Nginx (or equivalent) setting or using persistent storage or a Postgres contrib.

Making decisions about infrastructure is as much about day-2 as it is about the initial deployment. I see fly.io and render in this camp. Shiny day-1 docs and demos and then wishing you good luck when you need a `rails c` to see something in the DB

View on HN

I hate what Salesforce has done to Heroku but after a year of running our saas on aws, render, and fly - here I am, back on Heroku. It sucks, but slightly less than the alternatives.

Fly has potential, but they've changed/grown so much that most docs are out of date, everything is buggy, support is not very responsive, and their security posture leaves a lot to be desired. Not a fun place to be production issues pop up.

I'm building Argonaut to be a layer on top of AWS/GCP to make them less sucky. The primary use case is startups that have a bunch of services and have outgrown heroku etc. I'd love to chat if we can help - you get the stability of AWS and a push to deploy dev experience for your apps.

(I work at Heroku) Do you have more details on what sucks? Anything we're not already tracking to fix in our public roadmap? https://github.com/heroku/roadmap/issues

Glad to hear there's a roadmap. In my PAAS thrashing I've got quite a few notes:

- no wildcard subdomain ssl - poor metrics, nothing per instance - poor dyno granularity - (jumps from 2.5GB RAM to 14, no cpu/storage control) - no transparency on what each dyno actually is - external postgres replication disabled (deal breaker) - no first class postgres metrics and access logs/alerts (kibana recommended, but not great) - no external postgres backups (e.g. S3) - no deletion locks on dynos and add-ons, esp databases!!! - no warning when add-ons like databases are being deleted as a result of apps being deleted - deleting an add-on also irreversibly deletes all replicas and backups - painfully inconsistent naming for databases through their connection str env - dyno types for build processes use Perf-M? Not configurable - No lambda or github action style computing - No scheduled scaling - Unable to choose aws-us regions - Hard 30s timeout limit - Limited to 1 api key per user. No labels, configurable permissions, usage logging - no http/2 - frustrating enterprise offering. massive over-sell, near zero value

> dyno types for build processes use Perf-M? Not configurable

What are you looking for here? Larger build dynos? Heroku provides the build service for free so we use perf-m dynos to get fast builds with reasonable cost (for us).

(Render CEO) What can Render do better?

This precisely the niche Cloud 66 tries to fill, it caters for the growth businesses, providing initial ease but without sacrificing control. This allows companies to grow without being forced out before they are ready. (Disclaimer: I work for Cloud 66)

Does Cloud 66 have any resources on migrating a large (~300 GB) Postgres DB off Heroku, with minimal downtime? This has been our biggest sticking point when thinking about leaving Heroku.

Moving data is always the trickiest part! We get a lot of Heroku customers who need help with their data migration. My honest answer is there will always be some downtime while the switch over is happening, but we know of a few ways to reduce it. Unfortunately Heroku PG databases don't allow outside replication setup, so we can't really baseline your data and then close the replication gap with a shorter downtime. But we do support multi-DB solutions so we can run against an old and new DB at the same time while data is gradually being moved over. If you're interested, ping me at hello-at-cloud66.com if you want to discuss further :)

We'll keep that in mind, we're currently locked into a (ridiculous) enterprise contract with them. But it expires in November :)

We're considering using this https://bucardo.org/Bucardo/ based on this https://www.porter.run/blog/migrating-postgres-from-heroku-t...

Going to give it a shot when I have some free time.

Hello! Author of that little blog post there. Happy to be hit up with thoughts/feedback when you give it a shot!

Thank you so much for writing that. I was starting to lose hope of getting our data out of Heroku without some insane amount of downtime.

Please feel free to DM me should you need any tips with this. Email - me[at]rudimk.com.

That's what I'm struggling with. You're not wrong, but I feel like it's way too easy to go to the other extreme and suddenly you're way in over your head.

The title is correct. But any of you changes or lessons are perfectly fine. (Sure, a bit awkward to do ssh from cafes). May be reading the Google SRE PDF (or equivalent) would have been a bit more useful. At my wife's business one of the team member shall LOGIN to DO/AWS every month send a screenshot that account/CC is in good standing.

Can’t you do rails c in fly via the fly ssh console command?

The point is you can do it from Heroku UI.

vercel is great

How’s rails deployment experience with Vercel?

Reacting to his comment "However one thing that’s missing from all “alternatives to Heroku” is what I call life after deployment or Day-2 operations."

Since that's generic enough to also see vercel as a heroku alternative, be it for node and not rails

Reply on news.ycombinator.com