Live data from Hacker News

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

about.gitlab.com

211–220 of 275 posts

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

#211
post #133

Earlier quoted context omitted.

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.

Not sure I follow this. Salesforce bought Heroku over a decade ago and Heroku is still improving in its areas of expertise, with no signs of changing that.

If anything, Salesforce has been moving more of its core developer experiences over to the Heroku model rather than trying to make Heroku more Salesforce-y.

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

#212

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…

They did update just under the title...

"Update: This post does not live up to its original title We are building a better Heroku. It shows my own personal experience and reflects poorly on competitors. I am sorry about that."

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

#213

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…

> You don't need a bunch of silly yml configs The "silly yml configs" are the things I care about the most. I don't want to have to remember how to reproduce my environment in order to stamp out a new one or recover an existing one. I'm all for removing the seldom-needed complexity, but "reproducibility" is the concern around which I build my whole tech stack--I largely avoid VM-based stacks precisely because the rep…

they have them if you want. But you don't need them, which is the getting started quickly bonus.

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

#214
post #43

Honestly, this article presents a fairly ridiculous comparison. You could bump deploy times on Heroku to 20 minutes and I would still use it without a second thought. At best, I'll complain a little louder. Here's step 1 from the article: The documentation says to create a new AWS IAM role with credentials for automation. At this point, you've already failed. You are forcing more complexity on me than I have to care…

Heroku's pricing is also justified IMO, since if you're using Heroku you're most likely saving money on hiring an on-call infrastructure or ops team, and saving money on having your engineers switch focus from feature development to maintaining the system, or doing dev-ops work.

You're paying Heroku to do the operational stuff for you so you can spend more time building your product. That's a price well worth paying to a point, and even then I don't think the default next step is going full-blown cloud and K8S. Although that seems to be the way these days.

I mean, if you've got a year's worth of runway to launch your product, then you don't really want the engineer you're paying 90k+ a year for to get bogged down in debugging a custom CI/CD pipeline.

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

#215
post #210

Earlier quoted context omitted.

> You don't need a bunch of silly yml configs The "silly yml configs" are the things I care about the most. I don't want to have to remember how to reproduce my environment in order to stamp out a new one or recover an existing one. I'm all for removing the seldom-needed complexity, but "reproducibility" is the concern around which I build my whole tech stack--I largely avoid VM-based stacks precisely because the rep…

There is a gap here in apps that (typical) developers need. There is absolutely a market for footguns that work 95% of the time as long as the developer pays some attention to it. If you did all of the things required of launching a cloud level service for every signup page... few things would get done. There are some web apps which only need to exist for a few weeks or less before they can be tossed in a fire. If I'…

Absolutely, I didn't mean to imply that there was no room for MVPs (as well as signup pages, demos, etc), but I didn't understand that the thread was limited in scope to MVPs. Is it?

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

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

Wow.

sytse, there's no one else I know who's your equal in the kind of leadership you show in managing GitLab.

The transparency, the honesty in everything GitLab does is truly astonishing. Thanks for letting folks like me who know next-to-nothing about building companies be a fly-on-the-wall from oceans away, watch your meetings on YouTube, go through your plans and processes, observe eng designs and discussions around them, among other valuable career-building things. What you're doing is tectonic, all the while continuing to grow what's already a huge business.

Thank you.

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

#217

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…

I hope they give you a nice bonus for trying to fall on the sword so honorably, but even if no one else read your post before you posted it then that's still a leadership failure, frankly.

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

#218
post #211

Earlier quoted context omitted.

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.

Not sure I follow this. Salesforce bought Heroku over a decade ago and Heroku is still improving in its areas of expertise, with no signs of changing that. If anything, Salesforce has been moving more of its core developer experiences over to the Heroku model rather than trying to make Heroku more Salesforce-y.

After a short exposure to SFMC I can see why someone would be concerned about the impact they would have on Heroku, but it is good to hear there are reasons for optimism.

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

#219

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…

and now a retrospective with big point "hey, we made it to 1# on HN at least"... facepalm
Post reply on HN