Live data from Hacker News

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

about.gitlab.com

31–40 of 275 posts

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

#31
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…

What does "hyper cloud" mean in this context? Searching only shows a headset with the name "HyperX Cloud" but I'm sure that's not what you are referring to.

Hyperscaler = Google, Amazon, Microsoft, Alicloud

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

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

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

#33
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 just ignore it mostly).

https://devcenter.heroku.com/changelog-items/2035

Is there some way to encode this in the postgres DATABASE_URL? I'm not sure. With my particular app, it would have been ignored anyway, my app was deconstructing the DATABASE_URL into components to feed into the database connection configuration, and was not paying attention to any hypothetical part of it that would have specified ssl. This was per the instructions of the framework being used.

I could believe there's a way heroku could have done this better though... lately I do notice more and more things where heroku doesn't seem to be "dotting all the i's" [USA expression for attention to detail and perfection] as much as I used to count on them to.

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

#34
Gitlab has been trying to be a PaaS for years, but seems to subscribe to the “add more shiny features” school of product design rather than addressing the fundamental workflow of Heroku or Cloud Foundry.

They are also being incredibly trite when they say “Do not use Heroku”, which is not at all the point of that Twitter thread, it’s a cheap way to push your own product.

The point Adam was making (which I don’t entirely agree with) was that we (the broader industry building PaaS features on Kubernetes - eg. Knative, others) are all chasing a design target from 2012 that he thinks is a dead end, and we should be trying new things.

I think the issue is less about the failure of Heroku as a design target than a failure to commodify the infrastructure it takes to get to Heroku-like ease of use. In other words, people like Heroku (or Cloud Foundry) but large market segments don’t want to pay for it. So we need to bring the price down by commodifying the tech.

Long run it would be nice to simplify broader classes of apps than “12 factor apps” (and indeed, I’ve seen “3 or 4 factor apps” run on these platforms), but for anyone that have seen the enormous productivity gains of those platforms, especially in a large company, it seems we still have a lot of low hanging fruit we can address.

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

#35
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…

What does "hyper cloud" mean in this context? Searching only shows a headset with the name "HyperX Cloud" but I'm sure that's not what you are referring to.

In the West it means AWS, Azure, or GCP. See https://gitlab.com/gitlab-org/5-minute-production-app/deploy...

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

#37

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!

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

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

#38

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 stated"

Feels like an easy way out to claim whatever you want on company property without getting in trouble.

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

#40
post #21

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 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"
Post reply on HN