Live data from Hacker News

We are far from a better Heroku for production apps in a hyper cloud

about.gitlab.com

81–90 of 275 posts

Re: We are far from a better Heroku for production apps in a hyper cloud

#81
post #6

> The Git URL unfortunately does not provide access. Sorry to say but not having a git web UI doesn't mean you can't access it. The very next command you push to it via `git push heroku main`, meaning you have full access to it, including the ability to force push to it.

Yeah, I think it would have been better to differentiate in the article based on setting up state. It takes a while to configure a persistent database, redis, and storage on Heroku. That is what we’re trying to make easier, as well as hosting it on a hyper cloud. See https://gitlab.com/gitlab-org/5-minute-production-app/deploy...

> It takes a while to configure a persistent database, redis, and storage on Heroku

Really? Have you actually tried this? In my experience Heroku couldn't make it any easier. You can provision a database in 60 seconds, from a Deploy to Heroku button in your Github README, or in the lovely dashboard, or on the CLI, or with two lines in heroku.yml.

We're a heavy Gitlab user and I'm a big fan of Gitlab's typically transparent communications style, but this article reflects really badly on you. I think you should take it down.

Re: We are far from a better Heroku for production apps in a hyper cloud

#82
I like Heroku. I use it.

I suppose maybe I'm a possible customer for these guys, but I just don't care about their nitpicks or glib / empty twitter quotes.

Like I have a login for Heroku... it wasn't hard to make but apparently it was for them, that kinda makes me wonder about them.

Meanwhile their example is the opposite of Heroku, super opaque:

>The documentation says to create a new AWS IAM role with credentials for automation.

Oh just jump in the "create a new AWS IAM role with credentials for automation" canon and fly off to AWS land? I've worked with AWS plenty and man it's not been fun. I'm sure someone who knows thinks that's a trivial step, but I don't do it often enough to be sure of what is going on / be all that comfortable with it.

That kinda "here's a link to some documentation for a vague step" (that they don't time....) is why I use Heroku...

Re: We are far from a better Heroku for production apps in a hyper cloud

#83

People do not use Heroku because it takes 5 minutes to spin up a box. They use it because it's super easy. Click a button, bam deployed. Want to add a database, click what database you want, bam you got a database, environment variables set and a GUI (depending on what you pick). Want to scale up? Click a button, you're now scaled up. Want a entire review system with staging links and everything? Setup the review pro…

Yep. Heroku's workflow is why I created Piku (https://github.com/piku/piku). I wanted something dead easy for deployments and updates when iterating.

Re: We are far from a better Heroku for production apps in a hyper cloud

#84

This was very cringey. A super contrived demo and bashing Heroku through a Twitter reference. Reads like someone is drunk/high and wanted to shitpost about a competitor. I would be appalled by this if I were GitLab's PR department!

The only thing they succeeded in was reminding me how good Heroku is compared to whatever they're trying to sell

Unless you need to scale up. Then it is significantly more expensive. Their PostgreSQL offering uses AWS on the backend too so once you start needing to make more changes or specify regions/sites it makes sense to switch to RDS, plus you end up saving a lot of money.

Re: We are far from a better Heroku for production apps in a hyper cloud

#85

This post appears to be a comparison between deploying something on Heroku from scratch in 5 minutes, all-in, and someone knowledgeable about GitLab, GitLab CI and AWS, with accounts and credentials already created and configured, deploying something trivial in 6 minutes. That's quite a straw-man. If I were GitLab, I wouldn't be criticising the UX of companies known for excellent UX like Heroku while GitLab's UX is i…

They don't even TIME that whole step about AWS and credentials, it's a one line link to documentation.

That kinda "draw the rest of the owl" stuff is why people like Heroku.

Re: We are far from a better Heroku for production apps in a hyper cloud

#86
> "A typical web app requires a database, storage or caching backend, which can get complicated to run with Heroku."

Ah no. That is exactly where Heroku is dead easy. The creating, maintaining, updating and general day-to-day management of these "addons" require almost no input from the user. DB failover and mgmt is almost magic.

I wished GitLab would stay away from this needless, click bait type articles. It's not even well researched, almost if they never really ran a serious app on Heroku.

Sure Heroku has quirks (no http2) but I bet a lot less quirks than a homegrown GitLab CI + Terraform solution.

Re: We are far from a better Heroku for production apps in a hyper cloud

#87

People do not use Heroku because it takes 5 minutes to spin up a box. They use it because it's super easy. Click a button, bam deployed. Want to add a database, click what database you want, bam you got a database, environment variables set and a GUI (depending on what you pick). Want to scale up? Click a button, you're now scaled up. Want a entire review system with staging links and everything? Setup the review pro…

Agree with all of this. It is just such an easy environment to work in. Pipelines, team management, etc are a breeze. When it gets too expensive, Cloud66 is a great migration path and offers the best of both worlds. It's a fairly simply transition too.

Heroku CI, Pipelines, and Review Apps made for an awesome continuous deployment setup for me in the past.

Easy promotion of builds to staging/production after your tests pass and apps created automatically per pull request for testing in an environment just like all of your other environments.

Re: We are far from a better Heroku for production apps in a hyper cloud

#88
post #6

Earlier quoted context omitted.

Yeah, I think it would have been better to differentiate in the article based on setting up state. It takes a while to configure a persistent database, redis, and storage on Heroku. That is what we’re trying to make easier, as well as hosting it on a hyper cloud. See https://gitlab.com/gitlab-org/5-minute-production-app/deploy...

I'm sorry but this is just a joke. It takes a while to configure a database, redis and storage on Heroku? This reads as someone who has never used Heroku.

lol its literally a couple of quite memorable CLI commands

Re: We are far from a better Heroku for production apps in a hyper cloud

#89

So I think heroku has stagnated a bit, and I am definitely very open to "better herokus". But the idea that something you did in five minutes is going to be better than heroku (in all ways?) is.... I don't know what the adjective is. Heroku is very mature and polished software, that almost always does what you expect -- it's a very non-leaky abstraction, I guess. You can almost always get away with ignoring the detai…

I mean if you want an open source Heroku or you want a cheaper option you can run on a droplet, there's always Dokku. 5 minutes' Googling would have told the author that yet not a mention in that blog post...

Re: We are far from a better Heroku for production apps in a hyper cloud

#90

Earlier quoted context omitted.

The only thing they succeeded in was reminding me how good Heroku is compared to whatever they're trying to sell

Unless you need to scale up. Then it is significantly more expensive. Their PostgreSQL offering uses AWS on the backend too so once you start needing to make more changes or specify regions/sites it makes sense to switch to RDS, plus you end up saving a lot of money.

The scaling / costs are an issue but then you're not using Heroku anyway and ... probably not whatever that blog is trying to sell you on ;)
Post reply on HN