Live data from Hacker News

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

about.gitlab.com

191–200 of 275 posts

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

#191
post #181

Earlier quoted context omitted.

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.

Because if you charged less you wouldn’t make enough to support a business?

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

#192
post #85

Earlier quoted context omitted.

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.

Which goes back to the parent comment about criticizing a company known for great UX. I don’t think Gitlab understands why people like Heroku. I don’t want to go learn a bunch of individual services and then figure out how to wire it all together. For simpler architectures, you can make that setup, extremely easy, which is where Heroku really shines.

I love that “A great UX” is, in this case, “git push ssh://heroku.com/my-app”...

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

#193
while the original title created some resentment, I like the idea of the "5 minute production app". Especially, since it is built on an open platform like gitlab. What I would wish, is to not only take hyperscalers into account. I would like this feature to be available on a basic VPS too.

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

#194
post #190
post #158

Earlier quoted context omitted.

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.

It's an admirable attempt to break the stuffy "professional" atmosphere. Let people be themselves, imperfections and all. For that, I applaud the effort. Maybe they want to detract the type of person who places this much weight on such silly matters because those exact types in my experience are difficult to work with.

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

#195

Earlier quoted context omitted.

Which goes back to the parent comment about criticizing a company known for great UX. I don’t think Gitlab understands why people like Heroku. I don’t want to go learn a bunch of individual services and then figure out how to wire it all together. For simpler architectures, you can make that setup, extremely easy, which is where Heroku really shines.

I love that “A great UX” is, in this case, “git push ssh://heroku.com/my-app”...

It is also not having to "create a new AWS IAM role with credentials for automation".

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

#196
post #154
post #110

Earlier quoted context omitted.

User experience is often laughed at or even overlooked, but this is why Firebase and Heroku are used! I had a mainframes course in university and people from IBM would tout how everything we do today was already invented by them decades ago. But yeah, when you tried to use their stuff you had to jump through so many hoops, that you lost your motivation half the way.

I'm often confused at how poor so many engineers' product-sense is. Especially infra engineers (speaking as one). It's one thing to not have good product-sense when you're not the user, but for products like Heroku you literally are. My best guess is that a lot infra engineers actually value seeing the complexity and being able to understand all the pieces being used in the system more than they value getting somethi…

It’s from getting caught out when they’ve hidden the setting that is causing your site to be down in the name of making things easier.

I’m not saying it’s right or wrong, but that’s where it comes from.

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

#197
post #40
post #21

Earlier quoted context omitted.

I agree Heroku has the perfect dev environment, not much to improve there. We’re trying to make the perfect production environment. Most people end up hosting at a hyper cloud (edit: like AWS). We’re trying to make the app on a hyper cloud in production as easy as Heroku is in development. We’re still building that, it is t done by any means. And the article doesn’t do a good job of showing what we are trying to make…

but isnt that what AWS does with elastic beanstalk? elastic beanstalk always seemed to me as a "heroku with more dials"

I've never tried Heroku, but I have tried EB on a number of occasions and never had anything but grief with it. Often takes me days to get something deployed.

And the next time I do it, it's like it's all brand new. It never gets easier.

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

#198
post #159

Earlier quoted context omitted.

Heroku runs on AWS already, they're earning cost + markup as it is. If they purchased Heroku and did this, they'd be out several billion dollars plus lose their markup. Many of the Heroku addons also run on AWS, so customers may lock themselves into without knowing it. Additionally, customers are free to further lock themselves into the AWS ecosystem via "private space"/VPC peering. And they have a competitor to Lino…

> Heroku runs on AWS already, they're earning cost + markup as it is. If they purchased Heroku and did this, they'd be out several billion dollars plus lose their markup. I fail to understand this. If Heroku is on AWS, Heroku is selling its services at price X. AWS is getting from Heroku Y money, where X > Y (or it should at least, if Heroku is not operating at loss). If Amazon owns Heroku it could sell its services…

> I fail to understand this

Parent was proposing that AWS sell Heroku services at cost.

As you say, my point was it doesn’t make sense

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

#199
post #21

Earlier quoted context omitted.

I agree Heroku has the perfect dev environment, not much to improve there. We’re trying to make the perfect production environment. Most people end up hosting at a hyper cloud (edit: like AWS). We’re trying to make the app on a hyper cloud in production as easy as Heroku is in development. We’re still building that, it is t done by any means. And the article doesn’t do a good job of showing what we are trying to make…

> See https://gitlab.com/gitlab-org/5-minute-production-app/deploy ... This code is awful. > Terraform which has the following advanatges: > 1. Terraform is the most popular What an awful reason to pick a technology. I love TF but using something because it's popular is the worst reason ever. Why even include this as a reason? None of the others are particularly compelling for a "5-minute" setup either. > 5. You avoi…

> I love TF but using something because it's popular is the worst reason ever. Why even include this as a reason?

They don't really mean "because it's popular", they mean because it's the industry incumbent and de-facto standard. You can't use anything else, because nothing else makes sense.

You need to standardize on one tool, especially if your infrastructure / teams grow. If you want to deploy something on AWS using an API with a minimal graph of dependencies, there's just Terraform. Pulumi isn't totally free, you have to write more code, there aren't nearly as many providers, not as many people know it, etc. There's basically nothing else. As a result, it's "popular".

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

#200
post #133
post #131

Earlier quoted context omitted.

Amazon really should have bought Heroku instead of Salesforces. I continue to wonder why Salesforce bought it in the first place. And if they are willing to unload it.

Heroku not being AWS might be a feature. I'm not sure if AWS wouldn't try and integrate them and "break" something in the process. Whereas now, they still get money from it (Heroku runs on AWS) and can offer their own "alternatives" as part of the larger AWS offering.

Heroku not being AWS might be a feature, but Heroku being Salesforce is straight-up terrifying. I'm probably not moving my apps off Heroku anytime soon simply because they're running just fine maintenance free, but I'm not going to risk running any future apps on a Salesforce platform.
Post reply on HN