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.
We are far from a better Heroku for production apps in a hyper cloud
31–40 of 275 posts
Re: We are far from a better Heroku for production apps in a hyper cloud
#32> 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…
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
#33I 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…
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
#34They 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
#35Earlier 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.
Re: We are far from a better Heroku for production apps in a hyper cloud
#36I get the sentiment, but that's absolutely the last thing you want to do when going for the "5 minute production app".
Re: We are far from a better Heroku for production apps in a hyper cloud
#37This 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...
Re: We are far from a better Heroku for production apps in a hyper cloud
#38This 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!
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
#39Re: We are far from a better Heroku for production apps in a hyper cloud
#40People 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…