Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why companies move off Heroku (besides the cost)

blog.porter.run

Post reply on HN
Print view View original

221–230 of 230 posts

Re: Why companies move off Heroku (besides the cost)

#221

Post by cakoose »

Started something new last year and was considering Heroku, but their HA database offering uses async replication: https://devcenter.heroku.com/articles/heroku-postgres-ha#fai...

> Like followers, standbys are kept up to date asynchronously. This means that it is possible for data to be committed on the primary database but not yet on the standby. In order to minimize data loss we take two very important steps:

> 1. We do not attempt the failover if the standby is more than 10 segments behind. This means the maximum possible loss is 160MB or 10 minutes, whichever is less.

> 2. If any of the 10 segments were successfully archived through continuous protection, but not applied during the two minute confirmation period, we make sure they are applied before bringing the standby out of read-only mode.

> Typically there is little loss to committed data.

AWS RDS and GCP Cloud SQL do synchronous replication, so you are much less likely to lose data in common hardware failure scenarios.

With those options available, a managed DB with async replication is a no-go. I don't understand how so many businesses would be ok with it. (I suspect most people don't even realize that Heroku HA is async.)

Re: Why companies move off Heroku (besides the cost)

#222

Post by dml2135 »

fomb wrote: post #217
dml2135 wrote: post #16

I'm at a small startup (about 8 engineers) and for the most part Heroku has been a great solution for a team of our size. However, the recent github incident was a major PITA for us, and has us seriously considering leaving the platform for the first time. We're still working on getting all of our automated deployments back up and running. In addition, we had just put in some work to start using the Review Apps featu…

Github actions are your friend friend: https://github.com/AkhileshNS/heroku-deploy https://github.com/pmbanugo/heroku-review-app-actions

This is awesome, thanks!

Re: Why companies move off Heroku (besides the cost)

#223

Post by gingerlime »

mrkurt wrote: post #210
gingerlime wrote: post #177

Earlier quoted context omitted.

we’re using aiven.io and quite happy, although hard for me to compare. you can port across clouds, which is reassuring if we need to switch. Otherwise their support was helpful debugging a couple of db issues (in our own code). Wonder how they compare in this matrix if anyone knows? no affiliation. just a customer.

aiven.io is quite good. They went broad instead of deep, so they're not as good at Postgres as the Postgres specific companies. But they're probably better Postgres than a PaaS can build by themselves.

that’s useful to know that others do postges better. We use their redis as well, so in some ways, breadth is useful for them and for us.

at the time we picked aiven, we couldn’t find any redis-specialized hosting with instances in GCP europe if I recall. so their breadth also plays in terms of locating near the customer servers (important for latency)

Re: Why companies move off Heroku (besides the cost)

#224

Post by danjac »

jacobsenscott wrote: post #56

For all heroku's frustrations (and I agree with all of them in the article), it is still the only thing that "just works" for a standard monolith web app. Heroku is not cheap, but it is still cheaper than a couple full time employees + aws. It is really too bad they aren't innovating - they are just burning up their 10 year lead in the space. I wouldn't start a new project on Heroku - not because of the cost, but bec…

I'm currently evaluating PAAS services. The use case is early-stage SAAS with very small dev team who want to focus on the product and not have to deal with Kubernetes or the AWS services soup. Maybe further down the line that might be necessary but right now there isn't sufficient time or people for devops time-sinks. So PAAS it is.

I've used Heroku before and it was fine, and price as you say is not an object compared to developer time, but when I see people not being able to deploy for 2 weeks that rings very loud alarm bells. It means they don't have enough people to fix the problem (whether customer service or developers) and they can't afford or don't want to hire more people. Salesforce clearly are happy to let Heroku die on the vine, and are OK with current customers slowly leaving the platform while they squeeze the last drops of profit from them. That's a shame, but it is what it is. So instead currently looking at other options - Render, Google Cloud Run, fly.io etc.

Re: Why companies move off Heroku (besides the cost)

#225

Post by danjac »

justjake wrote: post #53
ryanSrich wrote: post #50

Earlier quoted context omitted.

Would you be willing to go over our Heroku environment to see if we'd be a good fit for Railway? I can't tell from the demo if you have things like automated backups, rollbacks, workers, add-ons for logging/monitoring/performance/etc. Those are all tablestakes for us. But Railway certainly looks great.

I would love to! I can tell you a couple things off the bat: - We have automated backups but they're for our own internal disaster recovery. User backups are something we want to do but haven't put on our roadmap yet - A key thing with Railway is "It's just code". So, a worker is just another service. We don't have special casing for specific types of code. We just run the code! So, yes we do support them - We have a…

I was trying out your free tier and was looking for any way to run shell commands (like heroku run). There's "railway connect" to connect directly to a database but really what is needed (i.e. table stakes) is to be able to do something like "railway run ./manage.py shell" remotely (NOT local).

Re: Why companies move off Heroku (besides the cost)

#226

Post by craigkerstiens »

sandGorgon wrote: post #174
craigkerstiens wrote: post #127

Earlier quoted context omitted.

Oh thanks for the props Kurt. The idea of PaaS disaggregation is definitely something I've been pondering for a bit and think I'm on the same page. At Heroku we were very opinionated about only Postgres for the longest time. We were fortunate to build-out the add-on ecosystem to give you more options, and explicitly did not want to run them ourselves for the longest time. I'm not sure how lucky we were vs. good, but…

genuinely curious - this is the first time im hearing of crunchydata in a "versus RDS" context. is there a pricing and feature comparison for RDS vs Crunchydata ? a honest tradeoff comparison.

We don't have anything published, but some of the basic summary on why us:

- We give you full Postgres super user access, so less restrictions

- Quality of support, whether it's the Postgres basics of indexing or you've found a crazy bug deep in Postgres. Our team contributes a lot to upstream Postgres itself and can go as deep as we need to, but in general quality of support is a big differentiator for us

- We've been able to beat in cases price to performance just on the mix of Postgres experience coupled with our experience running on AWS/other clouds.

- Not locked into a single cloud, can go from AWS to Azure and vice versa with click of a button.

There's more details, and more coming particularly around the developer experience and proactively improving your database for you. But that's the high level pitch.

We'll likely have something in our docs (https://docs.crunchybridge.com) soon to address it more directly.

Re: Why companies move off Heroku (besides the cost)

#227

Post by craigkerstiens »

Reitet00 wrote: post #179
glenngillen wrote: post #141

Earlier quoted context omitted.

disclaimer: former Heroku person here too Some examples of the things I've missed around developer experience for a database, that Craig and the team made possible at Heroku Postgres, include: - fork: ever had one of those "why does this bug only exist in production?" problems? It was so trivial to fork the DB and run your tests/hypothesis/whatever without the risk of actually impacting production. Same thing for _re…

> - fork: ever had one of those "why does this bug only exist in production?" problems? It was so trivial to fork the DB and run your tests/hypothesis/whatever without the risk of actually impacting production. Same thing for _really_ testing a migration script or load test. This sounds great! How does it work though? Is it using some special postgres feature or btrfs snapshots or something else completely?

It's leveraging pretty native Postgres tooling that restores the base backup from within Postgres, then replays the WAL to the exact point and time you specify. With snapshots and other mechanisms you may get a database "up" sooner, but we've seen when we follow that approach it's so long for the PG cache to warm up that you effectively still have a useless database even though it's "up". Further Postgres itself depending on how you do it will have to go through crash recovery, which I've seen cases on some providers taking over 10 hours.

Doing the native approach in Postgres isn't perfect, but we've focused on getting the developer experience for it down so you can use your database and it "just work" and if something goes wrong you understand how to rollback seamlessly.

Re: Why companies move off Heroku (besides the cost)

#228

Post by Reitet00 »

craigkerstiens wrote: post #227
Reitet00 wrote: post #179

Earlier quoted context omitted.

> - fork: ever had one of those "why does this bug only exist in production?" problems? It was so trivial to fork the DB and run your tests/hypothesis/whatever without the risk of actually impacting production. Same thing for _really_ testing a migration script or load test. This sounds great! How does it work though? Is it using some special postgres feature or btrfs snapshots or something else completely?

It's leveraging pretty native Postgres tooling that restores the base backup from within Postgres, then replays the WAL to the exact point and time you specify. With snapshots and other mechanisms you may get a database "up" sooner, but we've seen when we follow that approach it's so long for the PG cache to warm up that you effectively still have a useless database even though it's "up". Further Postgres itself depe…

Very cool! Thanks for taking the time to describe this in detail Craig (and Glenn).

Re: Why companies move off Heroku (besides the cost)

#229

Post by musicalmindz »

dikei wrote: post #192
pech0rin wrote: post #180

Earlier quoted context omitted.

You can easily use pg_dump to do a "vanilla" backup to s3. Its a managed db service but if you wanted to run your own you can extract your data and move to a new db. The lock is not "complete" you are acting like you can't even extract your data.

Using pg_dump for migration of large DB is very difficult due to the downtime it might involve.

This is exactly the issue I have right now on Aurora. We have a 30TB db and there's no easy way to export it to S3 for backup. The closest we have found is this... https://docs.percona.com/percona-xtrabackup/2.4/xbcloud/xbcl...

Anyone else have any idea if there's a better option??

Re: Why companies move off Heroku (besides the cost)

#230

Post by kasia66 »

Usually, companies migrate from Heroku to cut the cost as they grow, but there are other reasons too:

- The recent Heroku outages. - Lack of flexibility to adjust the available CPU, as Heroku offers six basic dyno types. As a result when the company grows they need to deal with overhears. - Heroku runs its servers on AWS, however, developers do not have access or control over the regions. This is an issue for the companies that deal with data requirements. - It does not offer support for crons/jobs. - Heroku default environment does not offer static IPs. (Private Spaces are only available on the Heroku Enterprise subscription.)

Have a look at cloud66.com, it creates an environment like Heroku but on your servers on any cloud. This creates many benefits, including persistent storage and support for all available regions of your cloud provider of choice. But it also makes a big difference in availability: your application is not dependent on Cloud 66’s availability and won’t go down. Disclaimer:I work at Cloud 66.

Post reply on HN