Live data from Hacker News

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

about.gitlab.com

91–100 of 275 posts

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

#91
post #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 e…

Agree on the storage point, I used their Redis and Postgres options for a few years with no real issues. Everything was seamless, even maintenance. The only complaint I could have would be cost, but that is expected.

Also, using S3 is simple and shouldn't incur much cost due to running in the same AWS region.

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

#92
post #62

Earlier quoted context omitted.

It would be helpful if the post was a bit clearer on that. FWIW, I've used Heroku as a production environment at multiple jobs. It works great there as well. The primary issue in my experience is cost. If you need to serve a lot of traffic, Heroku gets very expensive very fast. But it's still easy to use. That cost can be offset by the fact that you may not need to hire a dedicated devops engineer right away, and you…

I agree the blog post isn’t clear on that. I agree a simple production app can be great on Heroku. However besides being costly it is also hard when you want a managed service that isn’t on the platform. There are other reasons, https://gitlab.com/gitlab-org/5-minute-production-app/deploy... lists 9 in total. While a production app on Heroku isn’t hard it isn’t trivial either. We’re trying to make the 5 minute produc…

We hear you. But it looks like you're losing focus.

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

#93

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.

Then why not just publish the article on Medium or whatever? Nobody will notice or care about the "Unfiltered" label, they will just associate the authors' opinions with Gitlab regardless.

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

#95

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!

Yeah, seems they are trying to deflect their posts like this with a " This blog post is Unfiltered" notice that apparently frees them from anything mentioned as the blog is "intended for user-generated content submitted by the GitLab team. The views and opinions represented in this blog are personal to the author of each respective blog post and do not represent the views or opinions of GitLab unless explicitly state…

Legally they may not be in trouble, their brand is still tarnished imo. My esteem for GitLab has diminished as a result of this terrible blog post.

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

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

Well, the blog is "uNfILtErD". That's code for: unresearched rant

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

#97
post #93

Earlier quoted context omitted.

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

Then why not just publish the article on Medium or whatever? Nobody will notice or care about the "Unfiltered" label, they will just associate the authors' opinions with Gitlab regardless.

No idea. I agree it's stupid. I guess they're trying to be authentic, though this just seems low effort.

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

#98
post #24

> Lots of CLI commands involved, and it did not run in a CI/CD pipeline with additional tests before deploying it. Now the web application is deployed into a black box. That's just the other side of coin. If you want a simple "push and it's up!" interface then Heroku is a shiny coin. If you want to sell multiple levels of CI pipelines then it looks rusty. > Want to use Let’s Encrypt and your own domain name? I've nev…

Heroku has pipelines, with Github integration that makes CI/CD a breeze too

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

#99
What is the audience you're trying to target here? My project is already doing what you're attempting to demo here deploying a RKE2 cluster in AWS GovCloud and SC2S using terraform and installing applications into it using flux, all happening in Gitlab, but we are very much not doing this as a replacement for Heroku. Heroku doesn't exist and isn't even a possibility where we deploy. I don't imagine the one-man team trying to share a passion project with friends on the Internet really has the same concerns and cares about something like this.

For what it's worth, I kind of hate that we're using Gitlab for this, but as far as fully-integrated DevSecOps solutions that include VCS, binary artifact repositories, and pipeline orchestration all in one, there's Gitlab and there's Azure DevOps and that's it. No one else offers this, so here we are. My complain is more that, as much as I also hate Jenkins because the no database everything is configured via text files scales terrible, especially over NFS, and security is non-existent, but going from Groovy DSL to embedded bash scripts in a heredoc that is part of a yaml list object is a significant downgrade in pipeline developer experience and quality control as a vehicle for pipeline as code.

I really, really wish you guys hadn't gone with yaml-defined tasks as a pipeline scripting language. As bad as Jenkins is for every other reason, they really got the pipeline DSL correct.

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

#100
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 with which you can configure a production app, not a development app. Development apps on Heroku are already close to perfect. The examples in this post are contrived since it talks about a development app, as rightly called out by Heroku people https://twitter.com/johnbeynon/status/1374306499426652161

It should have gone into why hyper clouds might be preferable https://gitlab.com/gitlab-org/5-minute-production-app/deploy...

It should have talked about state, we made a small improvement in https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request... but we should have done the planned work in https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/11137 and made one post out of it.

Post reply on HN