Live data from Hacker News

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

about.gitlab.com

181–190 of 275 posts

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

#181

I suggest we don't need a 'better' Heroku, but rather a 'cheaper' Heroku, with the exact same UX as Heroku. That would be a worthy goal to aim towards.

Yeah, how dare they charge money for making almost everything a one-click, barely-maintenance solution with a free tier that covers everything that's non-commercial (meaning individuals, non-profit, but even short lived PoC/MVPs by commercial entities) They're pretty much already the cheapest service out there, it's kind of weird to want something that's cheaper when their prices are more than reasonable.

I think Heroku has a right to charge what they're charging but the price is really the only con for Heroku. It definitely isn't the cheapest service out there by miles so if someone could make a Heroku that's cheaper, that would be a huge improvement

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

#182

Honestly I wish the GitLab CEO would stop this running around the bush thing here. We know exactly what happened. This is not just an innocent accident by an employee. I mean the title says it all... -> "We are building a better Heroku" People at GitLab, probably including sytse, have decided that it's worthwhile to build a new Heroku competitor into GitLab. Then someone was tasked to write a PR blog post about it. T…

Hi, I wrote the blog post last week, and decided to publish it on Monday. https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

The title was chosen poorly, and the blog post did not reflect on its intentions. For that, I deeply apologize.

The experience and first time with Heroku is my raw impression, also the fact that I am a backend developer who is learning frontend and web apps.

It is a hard lesson learned today, although I am here for it. Iterate and improve, listen to feedback, and learn.

Sytse helps with his expertise and vision on the 5 minute production app, responding here to help. He is not to blame at all, I truly appreciate his guidance and thoughtful responses.

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

#183
post #48
post #11

Earlier quoted context omitted.

More a demo of how GitLab pipelines and terraform work together. In this case the app was deployed to AWS.

but thats not even in the same ballpark as heroku or is it? people using heroku dont want to have anything to do with terraform

correct.

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

#184
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...

I don't know what you mean. It's literally one click to configure a persistent database and redis on heroku. It's true that "persistent storage" can get more complicated, depending on what you mean, partially because that phrase encompasses a variety of different things for different needs.

I don't see how you could possibly make this easier.

You could make it cheaper, and possibly "transportable to a differnet vendor" (even a non-AWS vendor), which is what some people are chasing. To do this while being as easy as heroku is the holy grail. (not easier but as easy because configuring a persistent db or redis is already at the literal maximum of easiness on heroku).

But you think you can make configuring a persistent database easier than heroku? I honestly have no idea what you are thinking of when you say this "takes a while to do" on heroku. Are we talking about the same heroku?

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

#185

Earlier quoted context omitted.

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

Or a couple clicks in the web GUI if you prefer.

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

#186
post #181

Earlier quoted context omitted.

Yeah, how dare they charge money for making almost everything a one-click, barely-maintenance solution with a free tier that covers everything that's non-commercial (meaning individuals, non-profit, but even short lived PoC/MVPs by commercial entities) They're pretty much already the cheapest service out there, it's kind of weird to want something that's cheaper when their prices are more than reasonable.

I think Heroku has a right to charge what they're charging but the price is really the only con for Heroku. It definitely isn't the cheapest service out there by miles so if someone could make a Heroku that's cheaper, that would be a huge improvement

I definitely wonder why someone else hasn't managed to compete with them on price for a similar and similarly high-quality service.

But this post makes me think it's unlikely to be gitlab.

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

#187

Earlier quoted context omitted.

AWS may be the gold standard for hosting but I still recommended most startups start with Heroku for their hosting, especially since they add the code pipelines. The amount of VC dollars I have seen wasted on re-inventing the wheel of hosting/devops is a textbook case of premature optimization.

In terms of the raw pieces yes but AWS UX (or lack of it) leaves a lot to be desired. It's basically – "Here! Here's the raw pieces and API – have at it!" and you have to build or bring in external tooling to use it seamlessly. There's a product opportunity for basically every AWS service to make it usable for those who just wanna get sh*t done.

Yes. I have spent $4000 on consultants to set up our AWS project and it’s still not easy as “git remote add prod ssh://heroku.com/my-app”.

This “git push” is a killer feature — maybe it doesn’t really make sense security-wise or in a real architecture, but it makes it very sexy.

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

#188
post #168

They updated the post with this disclaimer: > Update: This post does not live up to its original title We are building a better Heroku...It should have emphasized the building part, we're just starting. The current 5 minute production app doesn't hold a candle to Heroku at the moment. It should have made it clear the goals is to improve the speed with which you can configure a production app, not a development app. D…

> It should have made it clear the goals is to improve the speed with which you can configure a production app, not a development app. Development apps on Heroku are already close to perfect.

What the heck does that mean? All of my apps are "production apps", what is a "development app" and why would I be deploying it to heroku? Nobody is paying heroku prices for something other than an app that will be in production! (Yes, you might have staging and feature demo etc... is that what they're tyring to talk about? They think heroku is great for deploying your staging phase, but when you get to the production phase.... they think the article explains this somehow? Cause it certainly does not).

I for real don't even underestand the distiction they are trying to make here about heroku being good for "development apps" not "production apps". Like before saying whether I agree or not, I don't even understand what they are talking about.

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

#189

Honestly I wish the GitLab CEO would stop this running around the bush thing here. We know exactly what happened. This is not just an innocent accident by an employee. I mean the title says it all... -> "We are building a better Heroku" People at GitLab, probably including sytse, have decided that it's worthwhile to build a new Heroku competitor into GitLab. Then someone was tasked to write a PR blog post about it. T…

Hi, I wrote the blog post last week, and decided to publish it on Monday. https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request... The title was chosen poorly, and the blog post did not reflect on its intentions. For that, I deeply apologize. The experience and first time with Heroku is my raw impression, also the fact that I am a backend developer who is learning frontend and web apps. It is a hard lesson lea…

thanks @dnsmichi for taking responsibility quickly. personally, I think competition is what drives the web tech forward and I appreciate the openness gitlab brings to both the technology and the process you are using. The blog post process you have linked demonstrates this very well. Btw, I dig your flame emoji :-D

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

#190
post #158
post #149

Earlier quoted context omitted.

It's a blog post on the company's official blog, no? I doubt it's like a free-for-all where any employee can post whatever they want without any review. Judging GitLab based on the content posted on their blog seems like fair game.

It is fair game to judge us based on our blog. At the same time it is a free-for-all for employees for blog posts marked Unfiltered as this one is. The author apologized in https://news.ycombinator.com/item?id=26555617 and we've made 8+ updates to the article to reduce the bias https://gitlab.com/gitlab-com/www-gitlab-com/-/commits/maste...

That sort of disclaimer is either naive or disingenuous

No one knows or cares what "unfiltered" means. My initial take was "unfiltered" meant "straight talk." There's no reason for a casual visitor to have any clue it means "rando blog rant spam."

This sort of post on this sort of domain is implicitly endorsed by the corporation and it's malpractice to pretend otherwise.

Post reply on HN