Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

about.gitlab.com

Post reply on HN
Print view View original

71–80 of 275 posts

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

#71

Post by toyg »

jrochkind1 wrote: post #33
gwbas1c wrote: post #14

I find Heroku rather easy. About a year ago I wrote a vanilla blog engine in NodeJS. It only required a small amount of debugging to get up and running on Heroku. (Although I don't know if I ended up modifying my code to adhere to Heroku quirks, or if the changes I needed for Heroku are normal.) One weird thing happened a few days ago. I noticed that my blog was offline, and I ended up needing to modify my Postgres c…

This actually happened to an app I'm invovled with too. Turns out heroku started requiring SSL for postgres connections on "hobby" tier only last month. (It had already been required for "standard" and "professional"; and the blog post says they had been advertising the deprecation for a while, although I hadn't noticed either -- the thing about heroku is it makes it so easy to just ignore it mostly, that you can jus…

> lately I do notice more and more things where heroku doesn't seem to be "dotting all the i's"

It feels basically frozen. The Salesforce acquisition seems to have been a Yahoo!-type deal for them, where they just keep things running as long as the checks come in and will sunset when enough people leave. Which is sad. Or at least this is my perception.

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

#73

Post by koolba »

sytse wrote: post #32
koolba wrote: 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…

The article isn’t clear about it but the 5 minute production app is an ambition, not a reality. Setting up IAM is indeed hard. The most workable idea we have so far is having the user run as CloudFormation script to set it up, see https://gitlab.com/gitlab-org/5-minute-production-app/deploy...

> The article isn’t clear about it but the 5 minute production app is an ambition, not a reality.

Not clear? The sub title to the article is "The 5 minute production app." and further down it includes timings like "8:43pm CET: Pipeline started with the build job. 2 min 33 sec." and "8:48pm CET: Deployed in 1 min 11 sec.".

> Setting up IAM is indeed hard.

Indeed. It's the iron triangle of devops: Speed, Simple, and Secure (You only get to pick two)

> The most workable idea we have so far is having the user run as CloudFormation script to set it up, see https://gitlab.com/gitlab-org/5-minute-production-app/deploy...

That's likely the best approach for initializing an AWS account though it boils down to, "Just trust us and run this". I doubt any new user would take the time to expand that CFN template, find the script that it loads (https://vantage-public.s3.amazonaws.com/x-account-role-creat...), analyze the resources, and see that it grants read only access to everything every created in your AWS account via a cross-account authorization.

Rather than target "Go live in 5-minutes", I think it'd be more worthwhile to target a longer time frame that'd lead to better understanding of the components involved. Yes it's not as sexy as "git push and you're live!", but the selling point is that you end up with a platform that can do anything including running your own resources, not just pushing 12-factor app code.

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

#74

Post by emayljames »

Trasmatta wrote: post #37
arthurcolle wrote: post #30

Earlier quoted context omitted.

> I have been a backend focussed developer in the past 20 years, web development is often fighting with Javascript and CSS. Especially Heroku as a deployment platform is a new area for me. No editing either...

I found the article confusing. It was difficult to understand what they're actually doing (I'm still unclear on that, actually).

Is like the writer had a momentary stroke in places.

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

#75

Post by throwaway883248 »

sytse wrote: post #6
judge2020 wrote: post #3

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

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

#76

Post by emayljames »

arthurcolle wrote: post #70
john_cogs wrote: post #56

Earlier quoted context omitted.

The documentation might help you to better understand what we're building: https://gitlab.com/gitlab-org/5-minute-production-app/deploy...

I would definitely caution you + the author of this post to tone down the rhetoric. Heroku has earned a tremendous amount of goodwill by being... basically fucking awesome and enabling tremendous amounts of productivity without having to screw around with infinite configuration settings. Just earn your own goodwill on your own merits, not by denigrating an extremely competent "competitor"

Yeah, a basic rule is don't bad mouth competition, it will always reflect on you and not your competition.

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

#78

Post by emdowling »

dubcanada wrote: post #10

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…

Agree with all of this. It is just such an easy environment to work in. Pipelines, team management, etc are a breeze.

When it gets too expensive, Cloud66 is a great migration path and offers the best of both worlds. It's a fairly simply transition too.

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

#79

Post by ZephyrBlu »

the_duke wrote: post #51

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.

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

#80

Post by tyeager »

oweiler wrote: 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.
Post reply on HN