I suggest we don't need a 'better' Heroku, but rather a 'cheaper' Heroku, with the exact same UX as Heroku. That would be a worthy goal to aim towards.
We are far from a better Heroku for production apps in a hyper cloud
171–180 of 275 posts
Re: We are far from a better Heroku for production apps in a hyper cloud
#172Earlier quoted context omitted.
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.
It was a bad blog post, we're sorry. Also see the comment by the author https://news.ycombinator.com/item?id=26555617
This post is really embarrassing, I would just take it down.
And you should really institute a review process. There is no such thing as "unfiltered" blog posts on an official domain.
It reflects badly on the company.
Re: We are far from a better Heroku for production apps in a hyper cloud
#173I suggest we don't need a 'better' Heroku, but rather a 'cheaper' Heroku, with the exact same UX as Heroku. That would be a worthy goal to aim towards.
Yeah, how dare they charge money for making almost everything a one-click, barely-maintenance solution with a free tier that covers everything that's non-commercial (meaning individuals, non-profit, but even short lived PoC/MVPs by commercial entities)
They're pretty much already the cheapest service out there, it's kind of weird to want something that's cheaper when their prices are more than reasonable.
Re: We are far from a better Heroku for production apps in a hyper cloud
#174This 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…
Calling it "user-generated content" when it's generated only by employees not actual GitLab users is quite disingenuous.
Besides, disclaimers like that don't even legally work. Employers can't disclaim responsibility for what their employees do when it is within the scope of their employment.
Re: We are far from a better Heroku for production apps in a hyper cloud
#175Honestly I wish the GitLab CEO would stop this running around the bush thing here. We know exactly what happened. This is not just an innocent accident by an employee. I mean the title says it all... -> "We are building a better Heroku"
People at GitLab, probably including sytse, have decided that it's worthwhile to build a new Heroku competitor into GitLab.
Then someone was tasked to write a PR blog post about it.
Then sytse did what he always does with GitLab PR, they post it on HN and tell GitLab employees to upvote it to make HN front page...
... and now when it has backfired because people point out how ridiculous this sounds sytse tries to play it down by saying it was a poorly written accident and deflects the blame from his own wrongdoing and pushes it on that employee. What a poor form of a CEO.
---
EDIT:
Proving my point:
- Blog posts tracked on Corporate Marketing:
https://gitlab.com/gitlab-com/marketing/corporate_marketing/...
- Issue which mentions an internal Slack conversation where this was discussed:
https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/11063
- PR which stated the release date of the post and was reviewed and approved by several people. It even had sytses (GitLab CEO) as an initial approver listed:
https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...
- 5 minute production app epic tracking issues, milestones, marketing, etc.:
https://gitlab.com/gitlab-org/5-minute-production-app
This was not a poor accident by a single employee. It's noble that the author tries to take all the blame on himself, but honestly, I feel like that is a moment where a leader has to step in and accept their mistake and not let a small trooper eat all the bullets.
Re: We are far from a better Heroku for production apps in a hyper cloud
#176Earlier quoted context omitted.
The idea would be to allow Heroku working independently while offering their solution at literally AWS cost (without all the discount), or even AWS Graviton2 cost. This would pretty much directly compete with Linode and DO on a value proposition. And a lock in to AWS ecosystem.
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…
Did not even know VPC peering was a thing. In the past I've often used Amazon RDS with Heroku Web servers for hosting Rails apps. For my current project I initially started out with Aurora Serverless which is VPC only, so I thought my web servers also had to be in the same VPC, so I decided to use Elastic Beanstalk instead of Heroku.
I do wish Amazon had an offering like Heroku. While Elastic Beanstalk works pretty good it's nowhere near as nice or easy to use as Heroku. It has gotten a bit better with Amazon Linux 2 [Procfile, platform hooks], but still leaves a lot to be desired. I wish I could scale up/down faster like you can with Heroku. There is probably a way to improve it, but right now the way it's set up any deploy, config change, etc bundles the gems and precompiles the assets which take a while. So deploy/scale up take around 8-10 minutes. It's been a while since I've used Heroku but from what I remember it's pretty much instant to add more dynos.
I also ran into a couple of other annoying issues with EB.
1. There is a bug if using Amazon Linux 2 Ruby 2.7 deploying a RoR app where assets are not precompiled on configuration changes. It was an easy fix, just needed to add a script to .platform/confighooks/predeploy but it should have just worked.
2. When migrating to Amazon Linux 2 I deployed a version of the app that needed some code changes to work on Amazon Linux 2. There is no way to disable rollback on failed deploy on EB. Setting the "Ignore Health Check" option to true does not help here. I ended up in a situation where I needed to both push a code update and update some environment variables. However any code update I would push would fail because of the missing environment variables and rollback and any configuration change to update the environment variables would rollback because the current code had an error. I ended up having to tear down the environment and recreate it to get out of this loop.
3. Another minor issue is the Monitoring/Health dashboard. It will show warning/degraded/severe during scaling operations. For example when you trigger a scale down event it will complain:
"Environment health has transitioned from Ok to Warning. ELB processes are not healthy on 1 out of 6 instances. ELB health is failing or not available for 1 out of 6 instances."
Like of course it's not responding, the autoscaling group just terminated it.
I feel like Elastic Beanstalk really could be a Heroku competitor if AWS cared enough to put the work into it. It just needs some polish and quality of life improvements, but I guess this way they still make their money and Heroku has a good business middle-man'ing it.
I'm wondering if perhaps I would be better off using ECS or EKS, or if that's what AWS wants me to use hence why they are not putting much effort in EB.
Re: We are far from a better Heroku for production apps in a hyper cloud
#177Alternatively, I tried using DigitalOcean app platform (side note: super hard to Google for help due to the generic name) and it was way harder than setting up Heroku, I invested multiple hours in a few days and when I finally got the app running I was not confident enough to proceed with the migration yet. Things I've noticed: * Segmentation Fault when deploying a Rails app, Heroku just works. * Ability to add Postg…
DO has Redis managed databases, and you can use those with Apps. You can associate an existing redis instance when creating the web app. Perhaps it's clunky if you create the web app first and then add the db?
Re: We are far from a better Heroku for production apps in a hyper cloud
#178People 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…
What are you saying is lacking in heroku's production environment?
"Setting up managed services on AWS is time consuming and that's what we want to solve."
Right, that's exactly what heroku has solved. Are you saying you don't think heroku has solved it as well as you have or you can?
> The contents of the blog post doesn’t warrant the title. We regret it.
OK, what SHOULD the title be, what's it actually about? Trying to build a heroku competitor?
Re: We are far from a better Heroku for production apps in a hyper cloud
#179People 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…
People use Heroku (and Google App Engine) because - if your app fits the model, and most do - you can completely skip ops/devops. Your whole team can go to sleep without a pager. You spend your life building features that customers care about instead of mucking with config files.
Re: We are far from a better Heroku for production apps in a hyper cloud
#180> 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...
So what is the article actually about then?
You're saying it's about the fact that you aspire to make something that's simlar to heroku but better in some unspecified ways [I mean, cheaper would be nice], while telling people "Do not use heroku" right now?
Seriously, what is the article about, if it's not about how you have something better than heroku (which nobody should ever use) that will let someone deploy an app in 5 minutes, which is what it says it's about?