Live data from Hacker News

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

about.gitlab.com

101–110 of 275 posts

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

#101
> Note that we never left the browser, there is no CLI involved.

This is not a positive thing, generally. Web-based deployments configurations are difficult to replicate and understand.

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

From experience, this step can take a large amount of time if you don't want to just say "grant all". But create a new account for this project and it's fine.

But overall this seems pretty cool if you want a quick start with a bunch of setup to get you started with a cloud app. Seems more customizable / controllable than Heroku.

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

#102
post #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.

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.

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

#103

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…

I fully agree, this should have been about it production app, not a development app which is already great on Heroku. Also see this post by the author https://news.ycombinator.com/item?id=26555617

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

#104
There is already a better Heroku and it's Vercel (previously Zeit) https://vercel.com/ I believe Vercel is the spiritual successor of Heroku. I guess Heroku got bought by Salesforce and the founders/visionaries left. Heroku should have moved to bill per seconds/milliseconds based on AWS Lambda functions like Vercel did later.

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

#105
Idk, this whole article felt contrived, but it's great that Gitlab aspires to be better than Heroku. We need that, since I feel Heroku has stagnated a bit, and it's cool someone is picking this up.

Heroku first and foremost gives me peace of mind about my production up. Someone handles that my app is running, someone cares that my backups are in place and working, etc.

And adding additional components and integrations is super easy to do, I don't need to know much about the underlying technology and how to run it.

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

#106

Author here. This post doesn't live up to its title, I'm sorry about that. The title should have been 'We are building a better Heroku FOR PRODUCTION APPS' (we'll add the 'for production apps' to the title) 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…

Can you explain what you mean by ‘for production apps’? Because some people are definitely using Heroku in production.

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

#107
post #80
post #17

I wish they would focus on other things. Things like GitLab CI's cache are unusable with most workloads, we even had builds which were faster without the cache than with it.

GitLab product manager here. Would any of the cache best practices ( https://docs.gitlab.com/ee/ci/caching/#good-caching-practice... ) be helpful for your use case? I'm interested to learn more about what's not working for your workloads; why cache is not improving the speed of your builds.

Some issues to consider following include: - https://gitlab.com/gitlab-org/gitlab/-/issues/17307 - https://gitlab.com/gitlab-org/gitlab/-/issues/24677 - https://gitlab.com/gitlab-org/gitlab/-/issues/18358

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

#108

Author here. This post doesn't live up to its title, I'm sorry about that. The title should have been 'We are building a better Heroku FOR PRODUCTION APPS' (we'll add the 'for production apps' to the title) 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…

Can you explain what you mean by ‘for production apps’? Because some people are definitely using Heroku in production.

Production apps in a hyper scale cloud

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

#109

I'm not sure how a blog post like this made it past any kind of review/quality control/PR in a 1000+ employee company. Criticising other services is quite poor form already. But then the criticism is a shallow dismissal by someone knowing nothing about Heroku, and with a minimal, odd example on top. And the proposed alternative is running Terraform in a CI pipeline to set up AWS. Yeah, that's not why people use Herok…

> I'm not sure how a blog post like this made it past any kind of review/quality control/PR in a 1000+ employee company That's what the Unfiltered tag is for. To resolve the company of any responsibility for this kind of thing.

The place for employees to post their personal opinion that doesn’t represent the company is their personal blog, not “about.gitlab.com/blog”. After you’ve raised almost half a billion dollars in funding, you can afford a PR person to review posts that appear on the company blog.

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

#110

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…

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.

Post reply on HN