Earlier quoted context omitted.
I think Heroku has a right to charge what they're charging but the price is really the only con for Heroku. It definitely isn't the cheapest service out there by miles so if someone could make a Heroku that's cheaper, that would be a huge improvement
I definitely wonder why someone else hasn't managed to compete with them on price for a similar and similarly high-quality service. But this post makes me think it's unlikely to be gitlab.
We are far from a better Heroku for production apps in a hyper cloud
191–200 of 275 posts
Re: We are far from a better Heroku for production apps in a hyper cloud
#192Earlier quoted context omitted.
They don't even TIME that whole step about AWS and credentials, it's a one line link to documentation. That kinda "draw the rest of the owl" stuff is why people like Heroku.
Which goes back to the parent comment about criticizing a company known for great UX. I don’t think Gitlab understands why people like Heroku. I don’t want to go learn a bunch of individual services and then figure out how to wire it all together. For simpler architectures, you can make that setup, extremely easy, which is where Heroku really shines.
Re: We are far from a better Heroku for production apps in a hyper cloud
#193Re: We are far from a better Heroku for production apps in a hyper cloud
#194Earlier quoted context omitted.
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...
That sort of disclaimer is either naive or disingenuous No one knows or cares what "unfiltered" means. My initial take was "unfiltered" meant "straight talk." There's no reason for a casual visitor to have any clue it means "rando blog rant spam." This sort of post on this sort of domain is implicitly endorsed by the corporation and it's malpractice to pretend otherwise.
Re: We are far from a better Heroku for production apps in a hyper cloud
#195Earlier quoted context omitted.
Which goes back to the parent comment about criticizing a company known for great UX. I don’t think Gitlab understands why people like Heroku. I don’t want to go learn a bunch of individual services and then figure out how to wire it all together. For simpler architectures, you can make that setup, extremely easy, which is where Heroku really shines.
I love that “A great UX” is, in this case, “git push ssh://heroku.com/my-app”...
Re: We are far from a better Heroku for production apps in a hyper cloud
#196Earlier quoted context omitted.
User experience is often laughed at or even overlooked, but this is why Firebase and Heroku are used! I had a mainframes course in university and people from IBM would tout how everything we do today was already invented by them decades ago. But yeah, when you tried to use their stuff you had to jump through so many hoops, that you lost your motivation half the way.
I'm often confused at how poor so many engineers' product-sense is. Especially infra engineers (speaking as one). It's one thing to not have good product-sense when you're not the user, but for products like Heroku you literally are. My best guess is that a lot infra engineers actually value seeing the complexity and being able to understand all the pieces being used in the system more than they value getting somethi…
I’m not saying it’s right or wrong, but that’s where it comes from.
Re: We are far from a better Heroku for production apps in a hyper cloud
#197Earlier 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…
but isnt that what AWS does with elastic beanstalk? elastic beanstalk always seemed to me as a "heroku with more dials"
And the next time I do it, it's like it's all brand new. It never gets easier.
Re: We are far from a better Heroku for production apps in a hyper cloud
#198Earlier quoted context omitted.
Heroku runs on AWS already, they're earning cost + markup as it is. If they purchased Heroku and did this, they'd be out several billion dollars plus lose their markup. Many of the Heroku addons also run on AWS, so customers may lock themselves into without knowing it. Additionally, customers are free to further lock themselves into the AWS ecosystem via "private space"/VPC peering. And they have a competitor to Lino…
> Heroku runs on AWS already, they're earning cost + markup as it is. If they purchased Heroku and did this, they'd be out several billion dollars plus lose their markup. I fail to understand this. If Heroku is on AWS, Heroku is selling its services at price X. AWS is getting from Heroku Y money, where X > Y (or it should at least, if Heroku is not operating at loss). If Amazon owns Heroku it could sell its services…
Parent was proposing that AWS sell Heroku services at cost.
As you say, my point was it doesn’t make sense
Re: We are far from a better Heroku for production apps in a hyper cloud
#199Earlier 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…
> See https://gitlab.com/gitlab-org/5-minute-production-app/deploy ... This code is awful. > Terraform which has the following advanatges: > 1. Terraform is the most popular What an awful reason to pick a technology. I love TF but using something because it's popular is the worst reason ever. Why even include this as a reason? None of the others are particularly compelling for a "5-minute" setup either. > 5. You avoi…
They don't really mean "because it's popular", they mean because it's the industry incumbent and de-facto standard. You can't use anything else, because nothing else makes sense.
You need to standardize on one tool, especially if your infrastructure / teams grow. If you want to deploy something on AWS using an API with a minimal graph of dependencies, there's just Terraform. Pulumi isn't totally free, you have to write more code, there aren't nearly as many providers, not as many people know it, etc. There's basically nothing else. As a result, it's "popular".
Re: We are far from a better Heroku for production apps in a hyper cloud
#200Earlier quoted context omitted.
Amazon really should have bought Heroku instead of Salesforces. I continue to wonder why Salesforce bought it in the first place. And if they are willing to unload it.
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.