We are far from a better Heroku for production apps in a hyper cloud | Hacker News Reader

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

about.gitlab.com

253 pointsrement268 comments

This is wild. Complains about having to read the Heroku documentation, and then goes through the steps to showcase how absurdly simple it is to deploy to Heroku with the CLI. It almost reads like an advertisement for Heroku.

...then goes on to show it could be done in GitLab in a more convoluted way. Ignores the fact that Heroku doesn't require GitLab, and seems to not be aware that Heroku does not require the CLI to deploy.

...and the GL steps require that you have previously created an AWS account, IAM, and have the credentials.

At the end of it all, it's obvious GL is using Terraform at the back end, anyway.

I'm left wondering why anyone would use this? Heroku is stupid easy to set up and get going, but you wouldn't use it if your production demands were getting complicated. However, if your production demands were getting complicated you surely would not use this GL solution. This entire thing seems to be a solution in search of a problem. I don't get it.

And ultimately I wouldn't want my entire deployment pipeline to be dependent on my code hosting provider. GitLab just 5x'd their prices a few months ago. Going all in on them for your entire CI/CD pipeline just seems crazy to me.

To add to that, they've trivialized Heroku to just being a "package your app and deploy it" whereas Heroku is VASTLY more than that, which GitLab couldn't even touch on in this article outside of a footnote at the bottom.

This post appears to be a comparison between deploying something on Heroku from scratch in 5 minutes, all-in, and someone knowledgeable about GitLab, GitLab CI and AWS, with accounts and credentials already created and configured, deploying something trivial in 6 minutes.

That's quite a straw-man.

If I were GitLab, I wouldn't be criticising the UX of companies known for excellent UX like Heroku while GitLab's UX is in the state its in.

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.

I love that “A great UX” is, in this case, “git push ssh://heroku.com/my-app”...

It is also not having to "create a new AWS IAM role with credentials for automation".

So I think heroku has stagnated a bit, and I am definitely very open to "better herokus".

But the idea that something you did in five minutes is going to be better than heroku (in all ways?) is.... I don't know what the adjective is. Heroku is very mature and polished software, that almost always does what you expect -- it's a very non-leaky abstraction, I guess. You can almost always get away with ignoring the details. (Yes, not 100%, but almost always). And there's pretty high quality documentation explaining how all the parts work, when you do need to figure out something.

This is unlikely to be a "better heroku", that solves all the problems heroku solves with as little time/energy from the customer -- if it really is, this post definitely didn't convince me of it, I still don't totally understand what it's even demo'ing. And it just makes gitlab look rude and/or desperate to have a heading that's simply "Do not use Heroku" -- because it's not open source, is the argument, i guess? Plus a vague and sarcastic tweet? How would we feel if heroku (or github) had an article titled "Do not use gitlab" with no more of an argument than that? It's just... childish.

I mean if you want an open source Heroku or you want a cheaper option you can run on a droplet, there's always Dokku. 5 minutes' Googling would have told the author that yet not a mention in that blog post...

Well, the blog is "uNfILtErD". That's code for: unresearched rant

Iny my experience, Render.com is a better (at least cheaper) Heroku plus it handles distributed Elixir really easily.

Does heroku not handle distributed elixir? What does that even entail

You need private networking or the Erlang nodes can't talk to each other.

Nice, I hadn't heard of them, but does look interesting, I'll add it to the list to check out at some point.

Going through the docs just a bit, I see some things have you using docker manually, like "Deploy Persistent Redis with Docker" -- that's not necessarily a barrier, but it is already less simple/abstracted than heroku. But still might be worth it.

I don't know how to keep up current awareness of this stuff, what the companies/options are. How do you?

(Render founder) the current Redis setup is one-click and zero maintenance, but we're also planning to launch a fully managed Redis later this year.

Thanks for the plug! Here's our (admittedly biased) Render vs Heroku comparison: we're not just cheaper; we're a better fit for how applications are built today.

https://render.com/render-vs-heroku-comparison

I agree wholeheartedly. I'm one of the people in the world creating a "Better Heroku" but my whole premise of my product is that Heroku like you said has kind of stagnated but is still the gold standard.

I don't see a reason for such childish attacks of Heroku. I'm solving similar issues but to go be more cost-effective and support more types of apps. I still hold Heroku in high regard and had the pleasure of having some higher ups as mentors of mine when I was in Junto Institute in Chicago.

render.com is a better Heroku. Absurdly easy, inexpensive and killer UX.

They also have in beta a way to spin up whole environments for every PR your dev team has. Imagine every PR has it's own database, backend and frontend, spun up/killed on the fly.

It's a very compelling feature.

I believe heroku has this feature too, no?

https://devcenter.heroku.com/articles/github-integration-rev...

But I am interested in checking out render, that I just heard about here.

(Not particularly interested in spending time checking out whatever Gitlab OP is trying to tell me about tbh)

> A typical web app requires a database, storage or caching backend, which can get complicated to run with Heroku.

Plainly wrong. Easiest thing ever to spin a pg instance for free and have it immediately available for your app to use.

Better Heroku? Does it let you use a pipeline of dev, staging and prod? Does it auto create new copies of your app (db and other services included!) every time you issue a pull request? Does it destroy those apps/services when you merge to master? Does it let you push to prod with one button? Integrated logs viewable on the web ui? Hell, integrated bash to a copy of your app in the web ui? Oh I forgot testing... webhooks... access control for other devs...

Better Heroku. Pathetic

This was a great comment until the mean-spirited last word.

Some folks don’t take kindly to lofty claims and name-dropping just to rile up interest.

I’ve run production apps on Heroku in the past, best possible service for small teams. Gitlab? Given how expensive it is - I’m not so sure.

Yeah, if you write a promotional post for technical people (I don't know who else this post would be for) you should expect to be called out on your bullshit.

I’ll ignore the last word.

The article doesn’t do a great job of showing it, but the 5 minute production app makes it easier to setup stateful services on the hyper clouds.

And it does spin up a new environment for every merge request.

> I’ll ignore the last word.

I dont think you should. Being the CEO of the company which published this blog, the last thing you should do is ignore a genuine review of what quality that blog post is.

> 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 never seen a platform that is easier to add Let's Encrypt domain validated TLS than Heroku's. Yes it's manual steps, but it's manual because you have to set up your DNS to point to their load balancer. I fail to see how much simpler it could be than that.

> How about adding the deployment natively to GitLab to have a single application in your DevOps workflow?

> # A better Heroku: The 5 minute production app

> ... The documentation says to create a new AWS IAM role with credentials for automation.

Nothing that involves creating AWS accounts or IAM role creation would take five minutes for someone unfamiliar with AWS. And if does happen in less than five minutes than I guarantee you that new user either has no clue what they just created or (boolean, not exclusive) they've left some gaping wide hole in their IAM permissions.

I'm not saying that it can't be done. I'm saying there is no way that creating all of that from scratch can be done simply, securely, and quickly for a new user.

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.

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?

Heroku has pipelines, with Github integration that makes CI/CD a breeze too

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 process line and you're done.

Everything is beyond easy and requires very little actual knowledge. You don't need a bunch of silly yml configs or knowledge of how containers work. You just pick a button and setup your git repo and it deploys your app. Want to SSH in? Install the CLI tools and type heroku ps:exec, want to see the logs? Go to the logs error to type heroku logs.

They have a perfect dev environment, fairly decent CLI tooling, bulletproof battle tested deployment setup (minus they fact they go down basically every 2 days if you aren't on the paid plans), and very little you need to understand.

On top of that: It's very easy to create an open-source project and put a "Deploy on Heroku" button right on the Github page.

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 easier. Setting up managed services on AWS is time consuming and that is what we want to solve. See https://gitlab.com/gitlab-org/5-minute-production-app/deploy...

The contents of the blog post doesn’t warrant the title. We regret it.

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 this context "Hyper Cloud" means one of the major cloud vendors - AWS, GCP, Azure.

Hyperscaler = Google, Amazon, Microsoft, Alicloud

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

but isnt that what AWS does with elastic beanstalk? elastic beanstalk always seemed to me as a "heroku with more dials"

I think that lots of the clouds will have their own offering, but having an open source based offering across clouds is what we're going for.

Also it's very early stages - but the goal would to be better than Beanstalk

As long as it is faster than gitlab itself, sure. Every time I go to the hosted gitlab, I cringe. I like the product but the whole thing is sooo slow. First, 5 seconds wasted to "check if my browser supports gitlab", then the lag on every click. Hopefully your heroku will have a better experience than your gitlab.

Isn't that "5 seconds" a cloudflare thing?

Why should I care? I click sign in button, which takes me to https://gitlab.com/users/sign_in and I see the message. Who cares where it comes from.

Oh my goodness, no. Beanstalk is a very poor clone of Heroku.

Context: I have used Elastic Beanstalk in real production apps for years. For my Rails side project, figured I would use Beanstalk instead of Heroku so that I'm using the same platform (although I have also used Heroku in prod settings).

Quick summary is the AWS tutorial for launching their Rails sample app in Elastic Beanstalk doesn't work at all. I though maybe my Rails install was borked somehow, so I tried launching a sample app at Heroku. Worked on the first try.

Heroku really spends time making sure everything works out of the box, and that's what you're paying for.

I've never tried Heroku, but I have tried EB on a number of occasions and never had anything but grief with it. Often takes me days to get something deployed.

And the next time I do it, it's like it's all brand new. It never gets easier.

It would be helpful if the post was a bit clearer on that.

FWIW, I've used Heroku as a production environment at multiple jobs. It works great there as well. The primary issue in my experience is cost. If you need to serve a lot of traffic, Heroku gets very expensive very fast. But it's still easy to use.

That cost can be offset by the fact that you may not need to hire a dedicated devops engineer right away, and your other developers spend much less time dealing with server setup and debugging.

I agree the blog post isn’t clear on that.

I agree a simple production app can be great on Heroku. However besides being costly it is also hard when you want a managed service that isn’t on the platform. There are other reasons, https://gitlab.com/gitlab-org/5-minute-production-app/deploy... lists 9 in total.

While a production app on Heroku isn’t hard it isn’t trivial either. We’re trying to make the 5 minute production app faster to set up than Heroku for production apps by automatically configuring a bunch of services. We’re not there yet but that is the goal.

We hear you. But it looks like you're losing focus.

> Hypercloud

Why list all of these reasons and then make no use of them in the infrastructure code? The code doesn't scale, has huge downtime, you recommend granting Admin access to the CI jobs, the free tier is only for the first year the account exists. The purpose and focus of this repo isn't clear to me at all.

I am not a Heroku user so cannot assess how this compares to their offering but as someone who spends ~4 hours a day looking at Terraform and the AWS console this does not look "production" quality at all.

* The web app is deployed to a single AWS EC2 instance which cannot be scaled horizontally.

* The web server is deployed from an AMI filter, when a new AMI matches this filter there will be downtime to redeploy the instance entirely.

* There does not seem to be any considerations for patching the web server.

* Everything shares a single security group. Although this is probably fine because you are using managed services for redis and postgres its still weird to allow port 443/22 from anywhere on your database.

I'd be happy to be proven wrong on these points.

There also seems to be quite a bit of assumed knowledge about AWS and Terraform. You mention the free tier a lot, but that only applies for the first year since your AWS sign up. After the free tier is up this infra is going to cost $40+ per month.

> 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 avoid the cost and complexity of Kubernetes

But k8s is popular so why not use that?

>If you are not sure what correct permissions are then use AdministratorAccess as a temporay solution.

Aside from all of the spelling errors in the README I hate this advice. You have the infrastructure code, you know what's going to be provisioned. Create an IAM policy and add it to the code or README. Telling people to give their little app Admin access is a terrible idea.

In addition to all of the issues another commenter mentioned. This is hardly "production" quality code or infrastructure. Production should be able to scale, that's the entire point of using HyperCloud providers.

> I love TF but using something because it's popular is the worst reason ever. Why even include this as a reason?

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

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?

Totally agree. The ease was the reason for us as well (although now running Cloud 66).

This post seems a bit disingenuous. Gitlap + Terraform + AWS != Heroku.

"there is no CLI involved"

Well that's annoying, seeing as I've just done everything else on the CLI

You can do the majority of Heroku interactions on the CLI if you prefer.

I know, and I do

The quote was from the blog. Making it seem like doing things off the CLI was a plus point

Right now I have a git alias that does everything, including pushing to my heroku master, in one command. Why would I want to go off the CLI?

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.

Heroku CI, Pipelines, and Review Apps made for an awesome continuous deployment setup for me in the past.

Easy promotion of builds to staging/production after your tests pass and apps created automatically per pull request for testing in an environment just like all of your other environments.

Yep. Heroku's workflow is why I created Piku (https://github.com/piku/piku). I wanted something dead easy for deployments and updates when iterating.

Interesting. On Dokku installing postgres and redis takes just two commands. How would the equivalent look on piku?

I fully agree, this should have been about it production app, not a development app which is already great on Heroku. Also see this post by the author https://news.ycombinator.com/item?id=26555617

What difference is the "production app" distinction supposed to make? Its not clear from neither the article nor the linked comment. If it's an attempt to suggest that Heroku isn't suitable for production use, that's going to need a lot of argument backing it up.

A production app has stateful services that retain data between deployments. The ambition of the 5 minute production app is to make this faster than doing it on Heroku.

The article doesn't make this case at all. Heroku is suitable for production and we didn't intent to suggest otherwise.

Typical heroku apps have services like postgres and redis that maintain state between deployments. This is very typical, and trivial to provision. Still not sure what you mean. Are you sure you are at all familiar with heroku?

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 something working quickly and easily.

It must be something to do with forgetting how hard things are for novices

Reminds me of the famous old HN comment about Dropbox

That one never gets old.

https://en.wikipedia.org/wiki/Curse_of_knowledge

It’s from getting caught out when they’ve hidden the setting that is causing your site to be down in the name of making things easier.

I’m not saying it’s right or wrong, but that’s where it comes from.

AWS may be the gold standard for hosting but I still recommended most startups start with Heroku for their hosting, especially since they add the code pipelines.

The amount of VC dollars I have seen wasted on re-inventing the wheel of hosting/devops is a textbook case of premature optimization.

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.

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 Linode/DO in their Lightsail offering (though how successful it is in competition I'm not sure)

> 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 still for X, eating Heroku's margin plus the margin it already had on the AWS offering.

> I fail to understand this

Parent was proposing that AWS sell Heroku services at cost.

As you say, my point was it doesn’t make sense

Heroku Buy AWS services at standard AWS Price (X) * (Substantial) Discount.

HeroKu Sell their services at (Y) where currently Y is >(X).

If they had acquired Heroku by Selling it at AWS Price (X), Amazon is still earning where they previously were not earning from those heavy Discount. At the expense of the Operational Cost of Heroku Team. And the benefits of further lock in and additional market segment which is currently not very well served by AWS.

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.

Heroku not being AWS might be a feature, but Heroku being Salesforce is straight-up terrifying. I'm probably not moving my apps off Heroku anytime soon simply because they're running just fine maintenance free, but I'm not going to risk running any future apps on a Salesforce platform.

Not sure I follow this. Salesforce bought Heroku over a decade ago and Heroku is still improving in its areas of expertise, with no signs of changing that.

If anything, Salesforce has been moving more of its core developer experiences over to the Heroku model rather than trying to make Heroku more Salesforce-y.

After a short exposure to SFMC I can see why someone would be concerned about the impact they would have on Heroku, but it is good to hear there are reasons for optimism.

Funnily enough, SFMC was also an acquisition, and it was acquired after Heroku.

SFMC is easily the worst Salesforce project from a dev experience / integration point of view, agreed there.

In terms of the raw pieces yes but AWS UX (or lack of it) leaves a lot to be desired. It's basically – "Here! Here's the raw pieces and API – have at it!" and you have to build or bring in external tooling to use it seamlessly.

There's a product opportunity for basically every AWS service to make it usable for those who just wanna get sh*t done.

Yes. I have spent $4000 on consultants to set up our AWS project and it’s still not easy as “git remote add prod ssh://heroku.com/my-app”.

This “git push” is a killer feature — maybe it doesn’t really make sense security-wise or in a real architecture, but it makes it very sexy.

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.

Yes!! Being part of a large org, nobody cares about the ops bit, leadership/product/dev mgrs just want features deployed!!! It's very obvious that the sooner we can abstract all the ops away the leaner we'll be.

> You don't need a bunch of silly yml configs

The "silly yml configs" are the things I care about the most. I don't want to have to remember how to reproduce my environment in order to stamp out a new one or recover an existing one. I'm all for removing the seldom-needed complexity, but "reproducibility" is the concern around which I build my whole tech stack--I largely avoid VM-based stacks precisely because the reproducibility story is so much flakier than the reproducibility story for containers. I imagine you can use something like Terraform for Heroku, but pretending that you can ignore reproducibility altogether is... really something. Maybe the parent means that "yaml is silly" and Heroku has a better reproducibility story in some other format (maybe graphical?)?

There is a gap here in apps that (typical) developers need. There is absolutely a market for footguns that work 95% of the time as long as the developer pays some attention to it.

If you did all of the things required of launching a cloud level service for every signup page... few things would get done. There are some web apps which only need to exist for a few weeks or less before they can be tossed in a fire.

If I'm a startup with limited customer expectations of reliability and I just want to see if my friends would use my product demo... a point and click solution sounds pretty great.

Absolutely, I didn't mean to imply that there was no room for MVPs (as well as signup pages, demos, etc), but I didn't understand that the thread was limited in scope to MVPs. Is it?

they have them if you want. But you don't need them, which is the getting started quickly bonus.

They did update just under the title...

"Update: This post does not live up to its original title We are building a better Heroku. It shows my own personal experience and reflects poorly on competitors. I am sorry about that."

No, it reflects poorly on GitLab. The competitor comes out looking just fine.

Honestly, this article presents a fairly ridiculous comparison. You could bump deploy times on Heroku to 20 minutes and I would still use it without a second thought. At best, I'll complain a little louder.

Here's step 1 from the article: The documentation says to create a new AWS IAM role with credentials for automation.

At this point, you've already failed. You are forcing more complexity on me than I have to care about when using Heroku. And the underlying complexity is worse. You need to be familiar with Gitlab's CI/CD pipelines. Your included YAML file hides all the complexity and uses all your magic variables: https://gitlab.com/gitlab-org/5-minute-production-app/deploy...

What happens when something breaks?

Quite literally, the only downside of Heroku is the pricing. Even that, I question for smaller teams where operational overhead can get way worse. I have yet to come across anything in the ballpark.

Anyway, this may still be a decent setup for deploying an app to AWS perhaps, but comparing to Heroku in the title is way off base.

Heroku's pricing is also justified IMO, since if you're using Heroku you're most likely saving money on hiring an on-call infrastructure or ops team, and saving money on having your engineers switch focus from feature development to maintaining the system, or doing dev-ops work.

You're paying Heroku to do the operational stuff for you so you can spend more time building your product. That's a price well worth paying to a point, and even then I don't think the default next step is going full-blown cloud and K8S. Although that seems to be the way these days.

I mean, if you've got a year's worth of runway to launch your product, then you don't really want the engineer you're paying 90k+ a year for to get bogged down in debugging a custom CI/CD pipeline.

> even then I don't think the default next step is going full-blown cloud and K8S

What would you suggest as a 'next step' after heroku?

Switching to a VPS or two is an option. You get more control over the machines you're running.

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.

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

I'm usually positive towards Gitlab, but if I were them I would make this post disappear as quickly as possible, it's that embarrassing.

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

Then why not just publish the article on Medium or whatever? Nobody will notice or care about the "Unfiltered" label, they will just associate the authors' opinions with Gitlab regardless.

No idea. I agree it's stupid. I guess they're trying to be authentic, though this just seems low effort.

The place for employees to post their personal opinion that doesn’t represent the company is their personal blog, not “about.gitlab.com/blog”. After you’ve raised almost half a billion dollars in funding, you can afford a PR person to review posts that appear on the company blog.

A PR person did review the post.

See this comment: https://news.ycombinator.com/item?id=26557589

Where does that show anyone from the PR department approving it? I don't see anyone I recognize from the PR department there...

This is how "unfiltered" blogs work: https://about.gitlab.com/handbook/marketing/blog/unfiltered/

Ah sorry I misread "PR" as in Pull Request for "PR" as in Public Relations.

I believe there were at least marketing people involved in approving the post though.

Alternatively, 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 Postgres but no ability to add Redis in the same ecosystem, you have to step out of the app platform, Heroku just one click and you have Redis associated with your app and many other add-ons.

There is a lot of potential on Digital Ocean, it in its infancy, the thing I like the most about it is $ for spec, with a $50 Heroku dyno I get 1GB RAM at DO the specs are way superior.

The blogpost mentions CLI usage and the global naming issues, those are annoying sure, but not the breaking point for Heroku.

The biggest competitor to Heroku IMO it's themselves. The fact their price remain the same even though specs and computational power has became way cheaper.

I would happily keep stuff in Heroku if they revisited their pricing policy.

"There is a lot of potential on Digital Ocean, it in its infancy, the thing I like the most about it is $ for spec, with a $50 Heroku dyno I get 1GB RAM at DO the specs are way superior."

You can a real server for about that money too, and it will leave all the clouds in the dust

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?

Check out Render.com

My trouble with Digital Ocean app platform and "turnkey" templates from VPS providers is that I don't trust them.

I want a secured box. Everything rootless. SELinux. SSH hardening. Etc.

I am better off on my own and everybody else too. Next week I am doing pre-release of my book and I hope it will be a good resource for people to take the deployment to their own hands[0].

[0] https://deploymentfromscratch.com/

I feel like Gitlab is going in a direction of AWS, except that instead of having separate products it just bundles everything in one. One massive bloatware that's scary to touch, no idea where features begin or end, or what is it even for in the end. Everything? I thought it was supposed to be Git hosting, but I'm not even sure anymore.

In this case I think it is more an ecosystem of build and deploy scripts that use the tools GitLab already provides (gitlab pipelines, terraform, etc.). GitLab is not providing the server space, instead you provide credentials to any supported cloud space and GitLab pipelines deploy the application.

That sounds like a good idea to me. For my personal projects I'd rather have everything in one place, especially if that one place is so well integrated like Gitlab.

AWS, on the other hand, is 500 different massive bloatwares that are scary to touch, to the point where there are literal courses available so you can learn how to use them. I've never had a good experience doing even basic stuff there.

> Everything? I thought it was supposed to be Git hosting, but I'm not even sure anymore.

They're losing to GitHub. While they advertise that they have 2/3 of the self-hosted git server market share, they just barely have a double digit share of the total VCS market, which is where the real enterprise money and value is. I don't have figures on hand, but I'd guess they have a single digit percentage of actual enterprise market share. GitHub has the same domination over its space that Google has over search, and Microsoft is excellent at competing on enterprise partnerships.

Tech companies usually scale out their products eventually anyway, but in GitLab's case it's probably existential if they want to maintain status as a high growth, VC-backed company. They need to find another of their competitors' moats which is easier to chip away at, or they need to change the game and introduce something original.

> They're losing to GitHub

In my experience their approach to pipelines and CI is a winner. In that regard GitHub seems to be playing catchup and the "checks" feel like second class citizens in GitHub while it feels really cohesive in GitLab.

Sure. I wouldn't be surprised if they have better features along specific dimensions. I'm talking about monetizable market share and revenue.

Gitlab has a post money valuation of $6b on revenue of around $150m+. It’s not “winning” but arguably it’s okay to be #3 (behind Atlassian / Bitbucket though they’re more diversified). It’s clearly doing fine enough to IPO or get bought at a premium. They have some huge customers that refuse to use GitHub.

I do question the “kitchen sink” product strategy and whether it’s sustainable - Atlassian pulled it off by building a product line rather than an all-in-one.

> I feel like Gitlab is going in a direction of AWS...

It turns out, if you host the source, you hold the keys to the world of DevOps, too. It is completely natural then for GitLab to venture in to an ever expanding field of GitOps and eventually the Cloud computing market. I mean, Microsoft plonked billions on GitHub for Azure more than anything else.

GitLab is an experiment of building a VC funded startup on anti-patterns and see how far you can go and get away with.

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

Hi, I wrote the blog post last week, and decided to publish it on Monday. https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

The title was chosen poorly, and the blog post did not reflect on its intentions. For that, I deeply apologize.

The experience and first time with Heroku is my raw impression, also the fact that I am a backend developer who is learning frontend and web apps.

It is a hard lesson learned today, although I am here for it. Iterate and improve, listen to feedback, and learn.

Sytse helps with his expertise and vision on the 5 minute production app, responding here to help. He is not to blame at all, I truly appreciate his guidance and thoughtful responses.

thanks @dnsmichi for taking responsibility quickly. personally, I think competition is what drives the web tech forward and I appreciate the openness gitlab brings to both the technology and the process you are using. The blog post process you have linked demonstrates this very well. Btw, I dig your flame emoji :-D

I hope they give you a nice bonus for trying to fall on the sword so honorably, but even if no one else read your post before you posted it then that's still a leadership failure, frankly.

I just want to say that I think most (If not all) of the vitriol is not directed towards you, but GitLab itself.

A guy linked a bunch of GitLab tickets in another comment showing that you went through the proper process and had multiple other people approve the post, so I think there wasn't much else you could personally do.

and now a retrospective with big point "hey, we made it to 1# on HN at least"... facepalm

I wrote that sentence and you took that completely out of context.

Here's the context if someone really does care: https://gitlab.com/gitlab-com/marketing/corporate_marketing/...

It's also important to note in a non-transparent company you wouldn't see any of this

> While the sentiment of the feedback was mostly negative for the reasons below, the fact is we were able to get to the top of Hacker News - something we attempted in a previous OKR but were not successful with. So while I agree that this might not have been the way to do that, I think we DID learn something about it, and that the "ideal" post is somewhere between "writing attention-grabbing titles" and "only publishing boring, technical, emotionless content."

So which is it, this was just one employee's personal opinion or this was an attempt to meet a company OKR? You can't have it both ways, and it's quite shitty to put your employees in a situation where if they're successful the company takes credit but if they're not they get thrown under the bus.

We attempted it in a previous OKR last quarter: https://gitlab.com/groups/gitlab-com/marketing/corporate_mar.... That's why I mentioned it in the past tense. This article was not part of that old OKR, you can see the issues that brought it up.

And the "we" there refers more to my team - the author of the post is on my team. GitLab OKRs start at the company level, but every team has their own that roll up: https://about.gitlab.com/company/okrs/.

The author wrote a blog post about a project GitLab is working on to shine more light on the work that is being done. While the tone and content of the post needed to be better, as we have acknowledged in both comments and changes to the post, we did receive feedback that can help us improve this project going forward.

We're also going to learn from this and improve how we write blog posts in the future, too.

To address your last point, I want to be clear that the author is a valued member of my team. His hard work has been recognized repeatedly in recent weeks in the form of awards and other recognition. This blog post will not change the high regard I, and his other colleagues, hold him in.

Everything you have seen today is our team living up to its values: the author's bias for action in publishing this post, the transparency and being quick to say sorry in how we responded and addressed this community's feedback, and how our team assumed positive intent and worked together to try to improve and learn from this situation.

You can read more about our values here: https://about.gitlab.com/handbook/values/

The comments are filled with GitLab employees, including your CEO, blaming the low quality of the post on it being "unfiltered", i.e. the employee's fault. If you value your employees, give them the tools they need to be successful, in this case an editor.

Hi,

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

The issues you have found are all assigned to me, or I created them. My task is to create blog posts, some of which being a hackathon and challenge. The KPI are impressions, other metrics are hard to measure. As a Developer Evangelist, I often need to learn new technologies, or dive into unknown areas connecting the dots.

You can learn more about our focus areas in our handbook: https://about.gitlab.com/handbook/marketing/community-relati...

I'm focussing on the Ops side, with a backend development background in the past 15 years. I was once a maintainer of an OSS monitoring project called Icinga, a Nagios fork back then. I decided to take on a new journey with becoming a Developer Evangelist in March 2020 (you can learn more on my website https://dnsmichi.at/about/ in case you're interested).

That being said, I've found it interesting to learn about web apps and their deployment, and dive into new things. Never having found a use case for trying Heroku, March brought up one: There was a Twitter theme of "Everyone is building a better Heroku" - https://twitter.com/adamhjk/status/1369704730218299392?s=27

From there, I thought of learning Heroku while comparing it with the 5 minute production app. I underestimated the challenge of creating a web app with a persistent backend, and decided to stick with the simple battleships demo I had initially found.

This state of the blog post felt good enough for me, and I did not include the persistent backend just yet, but moved it into a separate blog post. This is feedback I got during the review.

Turns out that this decision was wrong, next to other negative raw sentiments I had added in the blog post.

You can try to convince that it is not my fault, and I will convince you - it is, and I am standing up for it. Public and transparent.

I know we all get better from making mistakes. The lesson I learned today helped me improve a talk I gave at a meetup in my evening, it added technical insights as well as helped with the story line. That's the tracking issue: https://gitlab.com/gitlab-com/marketing/corporate_marketing/...

We will continue to iterate, and have a retrospective on what we can improve from the lessons learned today. Thanks for your feedback.

What is the audience you're trying to target here? My project is already doing what you're attempting to demo here deploying a RKE2 cluster in AWS GovCloud and SC2S using terraform and installing applications into it using flux, all happening in Gitlab, but we are very much not doing this as a replacement for Heroku. Heroku doesn't exist and isn't even a possibility where we deploy. I don't imagine the one-man team trying to share a passion project with friends on the Internet really has the same concerns and cares about something like this.

For what it's worth, I kind of hate that we're using Gitlab for this, but as far as fully-integrated DevSecOps solutions that include VCS, binary artifact repositories, and pipeline orchestration all in one, there's Gitlab and there's Azure DevOps and that's it. No one else offers this, so here we are. My complain is more that, as much as I also hate Jenkins because the no database everything is configured via text files scales terrible, especially over NFS, and security is non-existent, but going from Groovy DSL to embedded bash scripts in a heredoc that is part of a yaml list object is a significant downgrade in pipeline developer experience and quality control as a vehicle for pipeline as code.

I really, really wish you guys hadn't gone with yaml-defined tasks as a pipeline scripting language. As bad as Jenkins is for every other reason, they really got the pipeline DSL correct.

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

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

Why would I go to the docs if you can't even describe it properly in a blog post?

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.

Thanks for the feedback. I agree.

Is like the writer had a momentary stroke in places.

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.

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.

Or an easy way for a company to get the credit for a popular post, and hang a contributor out to dry if it's poorly received. Do the work and properly vet and edit your posts, and insist your employees post their own opinions on other platforms on their own time.

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.

The only thing they succeeded in was reminding me how good Heroku is compared to whatever they're trying to sell

Unless you need to scale up. Then it is significantly more expensive. Their PostgreSQL offering uses AWS on the backend too so once you start needing to make more changes or specify regions/sites it makes sense to switch to RDS, plus you end up saving a lot of money.

The scaling / costs are an issue but then you're not using Heroku anyway and ... probably not whatever that blog is trying to sell you on ;)

Agreed. Also, note this weird little flag/notice from the post:

> This blog post is Unfiltered

with a link to the "legal disclaimer":

> DISCLAIMER: This 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. All content provided on this blog is for informational purposes only. Neither GitLab nor any of the individual blog contributors ("Contributors") make any representations as to the accuracy or completeness of any information on this site. Neither GitLab nor any Contributors will be liable for any errors or omissions in this information or any losses, injuries, or damages from the display or use of this information. Comments are welcome, and in fact, encouraged. However, GitLab reserves the right to edit or delete any comments submitted to this blog without notice should GitLab determine them to i) be spam or questionable spam; ii) include profanity; iii) include language or concepts that could be deemed offensive, hate speech, credible threats, or direct attacks on an individual or group; or iv) are in any other way a violation of GitLab's Website Terms of Use. GitLab is not responsible for the content in comments. This policy is subject to change at any time.

It's written by a developer with a disclaimer that it's "unfiltered". I think it's part of their PR strategy to sound authentic and not salesy. Seems to mostly work for them.

Authentically cringey

> Ended up in a Heroku blackbox for your stateful web app? GitLab introduces a better Heroku integrated into your DevSecOps workflow: The 5 minute production app.

Are we sure this wasn't written by some sort of new AI bot GitLab is employing? So many keywords stuffed in those opening lines.

The comparison in the article is incredibly naive, IMO; they are not being a better Heroku, this is just demonstrating something you can do if you already have good knowledge of three complex tools: AWS, Terraform, and GitLab Pipelines.

> Are we sure this wasn't written by some sort of new AI

I gotta admit I laughed out loud when I read it.

I have decent knowledge of those tools and I'd still rather use Heroku for a simple production app.

I like Heroku. I use it.

I suppose maybe I'm a possible customer for these guys, but I just don't care about their nitpicks or glib / empty twitter quotes.

Like I have a login for Heroku... it wasn't hard to make but apparently it was for them, that kinda makes me wonder about them.

Meanwhile their example is the opposite of Heroku, super opaque:

>The documentation says to create a new AWS IAM role with credentials for automation.

Oh just jump in the "create a new AWS IAM role with credentials for automation" canon and fly off to AWS land? I've worked with AWS plenty and man it's not been fun. I'm sure someone who knows thinks that's a trivial step, but I don't do it often enough to be sure of what is going on / be all that comfortable with it.

That kinda "here's a link to some documentation for a vague step" (that they don't time....) is why I use Heroku...

IAM is never fun, even if you work with it a lot. You always end up forgetting something and, come security audit time, you find out that people have been creating tons of policies that are just like "s3::*"

Completely out of topic, but I think there is almost a perfect sync (with about a year of buffer) between the moment we lost the famous "gitlab CEO here" comments on HN and the moment where comments on HN starting shifting towards the negative side.

Long gone are the 'gitlab is so amazing' comments, and the top comments are usually much more critical (clickbait, stability, . . .).

Not taking sides, just an observation that I make to myself pretty much every time I see Gitlab over here.

For reference : https://www.google.com/search?hl=en&q=%2Dsite%3Amedium.com%2...

Has GitLab already finished building a better GitHub before they waste time in a better Heroku when in fact nobody else thinks that we need a better Heroku?

Last time I checked GitLab was still significantly slower than GitHub.

What a poor article.

> Especially Heroku as a deployment platform is a new area for me.

Maybe you should get some more experience with the product before writing your critique? Or write about something you know more about.

> Getting there and installing the pre-requisites on the CLI took longer than expected.

No mention of how long, but when you use your own tool instead you time it down to the second...

> Lots of CLI commands involved, and it did not run in a CI/CD pipeline with additional tests before deploying it.

You published your code on github, so we can all see that you didn't actually write any tests. Heroku does actually have a CI offering, but let's just ignore that I guess?

The first blog post I ever wrote that made the front page of Hacker News was called "Docker is the Heroku Killer".

https://news.ycombinator.com/item?id=8371249

Let me be real clear here...only Heroku will ever beat Heroku.

Docker has enabled a lot of other great options that are all modeled after the experience that Heroku has created...but ultimately people keep looking to Heroku because they are the gold standard.

Better is a series of tradeoffs. Heroku has been refining the tradeoffs to using their platform for a decade. You may create tradeoffs that work better for a use case that you want to enable, but ultimately you're going to have to convince people that your set of tradeoffs has made things "better".

This was a confusing read. I guess GitLab has a hosting service, or does it? Or was this a demo of terraform?

The 5 minute production app is a fancy GitLab CI script that uses Terraform to provision managed services.

The goal is to “quickly make a stateful app that is deployed on a hypercloud” https://gitlab.com/gitlab-org/5-minute-production-app/deploy...

More a demo of how GitLab pipelines and terraform work together. In this case the app was deployed to AWS.

but thats not even in the same ballpark as heroku or is it? people using heroku dont want to have anything to do with terraform

correct.

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

Puzzling from someone working for a git platform. Or maybe fitting?

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.

lol its literally a couple of quite memorable CLI commands

Or a couple clicks in the web GUI if you prefer.

> It takes a while to configure a persistent database, redis, and storage on Heroku

Really? Have you actually tried this? In my experience Heroku couldn't make it any easier. You can provision a database in 60 seconds, from a Deploy to Heroku button in your Github README, or in the lovely dashboard, or on the CLI, or with two lines in heroku.yml.

We're a heavy Gitlab user and I'm a big fan of Gitlab's typically transparent communications style, but this article reflects really badly on you. I think you should take it down.

I have been following these gitlab promotion threads here at HN and I dont usually comment, but I had to create this account after reading this post. It looks really bad and incompetent when a CEO of the company makes a statement like this. Have you ever used Heroku? On what basis are you allowing people to bash that product on your website? Do you consider Heroku your competitor? On what technical abilities of Gitlab do you think you have reached a place where you consider them your competitor? Some random meaningless doc someone put together to show how you will do better?

I don't know what you mean. It's literally one click to configure a persistent database and redis on heroku. It's true that "persistent storage" can get more complicated, depending on what you mean, partially because that phrase encompasses a variety of different things for different needs.

I don't see how you could possibly make this easier.

You could make it cheaper, and possibly "transportable to a differnet vendor" (even a non-AWS vendor), which is what some people are chasing. To do this while being as easy as heroku is the holy grail. (not easier but as easy because configuring a persistent db or redis is already at the literal maximum of easiness on heroku).

But you think you can make configuring a persistent database easier than heroku? I honestly have no idea what you are thinking of when you say this "takes a while to do" on heroku. Are we talking about the same heroku?

Hey Gitlab,

This is as worse as it can get. This is tabloid stuff. Have lost respect for you.

Name calling Heroku which is known for its UX and ease of use. And then offering nothing but some made up nonsense and buzzwords. What happened to your good standards ?

Why can't you be serious and build a better Heroku instead ? for real

They do the same on linkedin and that was the reason I unfollowed them, too many buzzwords for short content. GitLab used to have a really good technical blog (like postgres articles), but you wouldn't believe the top 10 things they started doing! Unfortunately recent posts are medium.com quality.

> You cannot debug Heroku by reading the source code.

I get the sentiment, but that's absolutely the last thing you want to do when going for the "5 minute production app".

I can push an HTML file to prod in 4 minutes with my shiny tech. Heroku took 5. Therefore, my new shiny thing is better.

> Apparently Heroku is not Open Source.

...Neither is AWS. And?

Gitlab is better than this.

This reads like the infamous "use ftp" comment about Dropbox, but in reverse. It totally misses the point of why people use Heroku. A) It's free B) You don't need to know how to code.

Same thing applies to Netlify. This post seems quite desperate.

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 customer here. Sometimes I also feel like they are adding a lot of stuff instead of improving their core services. BTW I already gave up on using GitLab's native caching in favor of doing all my CI/CD with Kaniko + Multi Stage Dockerfiles

I would not care about new features if they had granular billing like AWS, GCP, etc... But here I am paying for Devsecops and a lot other stuff I don't use.

I would love to hear more about this billing information in GitLab. Are you looking for build minutes and CPU of Runners per cloud service? What kind of questions are you typically trying to answer with that information?

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.

Some issues to consider following include: - https://gitlab.com/gitlab-org/gitlab/-/issues/17307 - https://gitlab.com/gitlab-org/gitlab/-/issues/24677 - https://gitlab.com/gitlab-org/gitlab/-/issues/18358

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 connection code to explicitly enable encrypted connections. This struck me as very strange. I mostly work with Microsoft SQL, and those kinds of things are set via the connection string. Shouldn't Heroku have just updated my database connection string without breaking my site? Admittedly, I have a lot less experience with Postgres than Microsoft SQL.

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.

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

Yeah, I feel that. Although the salesforce acquisition was way back in 2010, I think heroku still had some innovation and progress after that for a few years. But not in a few years now.

The good news is that heroku started out so solid that it can last a while in this state still being a good product. But it doesn't seem great.

I still don't know of anything else as good as heroku for "we don't really have any ops expertise in-house, do it for us and make it Just Work". I doubt the OP is that. I really don't have time (or honestly interest) to learn kubernetes.

There is already a better Heroku and it's Vercel (previously Zeit) https://vercel.com/ I believe Vercel is the spiritual successor of Heroku. I guess Heroku got bought by Salesforce and the founders/visionaries left. Heroku should have moved to bill per seconds/milliseconds based on AWS Lambda functions like Vercel did later.

Isn't Vercel pretty much just for Jamstack? Not everyone wants or needs that so I'm not sure it's better.

Hey! Lee from Vercel here. Vercel isn't just for static sites – it also handles server-rendered applications, serverless functions, and hybrid frameworks (like Next.js).

The current focus has been on an incredible front-end experience, but we're working to become a first-party integrator with your favorite backend solutions.

For example, you can deploy a full-stack Next.js application with a PostgreSQL database in less than 3 minutes: https://twitter.com/leeerob/status/1351576575888797696

Isn't serverless still just lambda..?

Slow to boot, and subject to denial-of-wallet attacks.

I do love vercel for static sites, and also think my blog with a minimal backend for comments is a good fit.

But less sure how it'll hold up to even a single heroku dyno, which can do a lot of concurrent request at very low cost.

Cold boots are going away with innovations like Firecracker[1]. One of our larger customers was able to handle 90 million concurrent requests during peak traffic.

[1]: https://www.serverless.com/blog/firecracker-what-means-serve...

This is not entirely true. Firstly because Lambda keeps getting cheaper with the move from per 100ms billing to pwe 1ms being a big contributor. but also that I see organizations handling millions of requests per hour at peak but because of the dynamic nature of Lambda, any cost increase during the peaks are entirely offset by the reduced cost during low traffic periods since Lambda and associated services cost $0 when its doing nothing. Add in other services that act the same way such as S3, DynamoDB, API Gateway, etc and you have a very powerful, redundant and scalable applications without even really trying. No to mention that because spinning things out is so quick you can get a feature in front of users earning revenue way faster than any traditional service that requires some effort to start up, configure and maintain. And the costs associated with having VM's of the right size up to handle peak loads that are much slower to ramp up and down, creating significant periods of over provisioned capacity you pay for.

Lambdas are not slow to boot because of the methods used to tune how hot they stay; in a production application doing millions of invocations a day we saw 0.03 % of all invocations suffering a cold start that added an additional 100ms latency only. And if you absolutly have to have warm Lambdas always for even that 0.03% you can use provisioned concurrency that always keeps a certain number of Lambda functions warm.

Oh yes, and serverless is not just Lambda, its a about the whole suite of cloud services you combine together to build your solution.

My personal experience with a B2B SaaS startup is that Vercel and AWS Lambda are much cheaper than Heroku. 0 to 4th year of the B2B SaaS startup we went from 1 free dyno to 3x 25$ a month dynos on Heroku for a total of 75USD a month. 4th to 8th year we switched to AWS Lambda and we have paid... 0$ since then. AWS Lambda free minutes are well enough to run a B2B SaaS until like 300 paying customers. AWS Lambda is also part of the serverless movement and it pairs up well with static sites on CDN. You can pre-render and/or generate a stic website for all the www landing pages and put them in S3 buckets cached with AWS CloudFront (Amazon CDN).

I beat this horse to death, but I would definitely use it for if there was just a way to allowlist / vpc-peer so the functions can be the only thing talking to the database. Password isn't enough for a lot of applications.

As long as vercel has lame security, I'll consider it a toy, nice for quick jokey blogs and stuff but not something to use for a serious project. Not about to risk getting sued just to use vercel simply because your stuff's easy to use

This is good feedback. Allowlist support is available for enterprise teams. We definitely hear you on VPC peering - it's on our roadmap.

More on the security of our platform here https://vercel.com/security, as well. Thank you!

+1 for Vercel. It is so stupid, that even my grandma could do it!

the fuck did I just read? A bunch of buzz words smashed together "hyper clouds", "DevSecOps".

Then starts to show off how easy it is to use heroku, while complaining about how complex it is???

And at the end there are some vague screenshots showing a supposedly easier method of deploying things than using heroku, but first you have to learn GitLab CI/CD, Terraform, AWS, and probably a bunch of other things?

First you should build a better GitHub. After that I might take a look at this.

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.

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.

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.

Because if you charged less you wouldn’t make enough to support a business?

Disclaimer: I am building a company around this.

Not entirely. There's room for improvement on pricing. But you have to employ a culture where being cost-effective is engrained in the company.

I like to quote the pizza chain Lil Caesar's when I discuss this, which is why my company I am building is able to provide the same core features but cost less. We look for ways to save on operational costs and resources ourselves so that we can pass the buck down to our customers without compromising on quality.

It's possible.

But heroku charges a pretty big multiplier over the underlying AWS resources and does a pretty large volume (I don't know if the numbers are public, so I could be wrong, but my sense is they have a LOT of customers).

It seems likely to me that their prices are more about "what the market will bear" than about what they need to support the business. There's nothing wrong with that, nobody's forcing any customers to pay for heroku, the customers think the value is there.

It just makes me surprised that nobody's competing effectively on price. Which may mean I'm wrong and you are right. But there could also be other explanations.

If they HAD competitors offering the same thing, we might think that the competitors were forced to compete on price so all maybe were charging the least they could to support the business. At least that's the theory. But that they have no real competitors offering quite what they're offering... when what they're offering has been so successful... is surprising to me.

Maybe it's just hard to create something as high-quality as heroku Or to do it without funding, or to get funding for it?

I think the title is a bit confusing. "We are building a better Heroku" implies some sort of announcement that Gitlab is adding a new service to their offerings, and that's what I expected when I clicked. This is more like a tutorial for how to make a deploy pipeline using Gitlab.

That's a big statement. I am afraid it's not easy to replicate Heroku, let alone build something better. Quite the opposite I would say.

> Note that we never left the browser, there is no CLI involved.

This is not a positive thing, generally. Web-based deployments configurations are difficult to replicate and understand.

> The documentation says to create a new AWS IAM role with credentials for automation.

From experience, this step can take a large amount of time if you don't want to just say "grant all". But create a new account for this project and it's fine.

But overall this seems pretty cool if you want a quick start with a bunch of setup to get you started with a cloud app. Seems more customizable / controllable than Heroku.

Read the article. Came here for the comment thread. Was not disappointed.

They updated the post with this disclaimer:

> Update: This post does not live up to its original title We are building a better Heroku...It should have emphasized the building part, we're just starting. The current 5 minute production app doesn't hold a candle to Heroku at the moment. It should have made it clear the goals is to improve the speed with which you can configure a production app, not a development app. Development apps on Heroku are already close to perfect.

> It should have made it clear the goals is to improve the speed with which you can configure a production app, not a development app. Development apps on Heroku are already close to perfect.

What the heck does that mean? All of my apps are "production apps", what is a "development app" and why would I be deploying it to heroku? Nobody is paying heroku prices for something other than an app that will be in production! (Yes, you might have staging and feature demo etc... is that what they're tyring to talk about? They think heroku is great for deploying your staging phase, but when you get to the production phase.... they think the article explains this somehow? Cause it certainly does not).

I for real don't even underestand the distiction they are trying to make here about heroku being good for "development apps" not "production apps". Like before saying whether I agree or not, I don't even understand what they are talking about.

Since the post has diverged quite a bit from the original and most of the comments are about the original, here is the original: https://web.archive.org/web/20210322133353/https://about.git...

https://fly.io/ is the actual better Heroku.

If nothing else, this whole thread shows that actually running a product in production is much more difficult than a lot of people would like to believe, and paying for good managed hosting is worth it. Just because we want it to be cheap or easy doesn't mean it will be.

Aside: has anyone here ever tried to build an actual wheel? Like a wheel for a car, or a wheelbarrow, or a wagon? One that has to take hundreds / thousands of pounds, works in multiple environments, lasts years, requires little maintenance? I think the phrase "reinventing the wheel" understates the difficulty it takes to actually re-create a wheel even if you already know how it works. Not only is it wasted effort if a good wheel already exists, it's also much harder than you think.

This article is a bad look for GitLab.

These the same people who Jonny drop tables themselves? https://twitter.com/gitlabstatus/status/826591961444384768

using heroku, we don't have to worry about infrastructure (much). having terraform in the pipeline kind of defeats that.

Why is this not in the front page still? I'm not sure about how the ranking algorithm works but it seems that this has more points and is more recent that some of the post in the front page.

Idk, this whole article felt contrived, but it's great that Gitlab aspires to be better than Heroku. We need that, since I feel Heroku has stagnated a bit, and it's cool someone is picking this up.

Heroku first and foremost gives me peace of mind about my production up. Someone handles that my app is running, someone cares that my backups are in place and working, etc.

And adding additional components and integrations is super easy to do, I don't need to know much about the underlying technology and how to run it.

The title edit makes this topic pretty confusing.

A better Heroku to me would be something like Dokku but for OpenBSD (or generally unix-agnostic). An universal PaaS, if you will.

Also something that makes it easier to handle the dev/prod lifecycle. I'm sure it's all very easy once you have all your devops stuff down, but the setup is still somewhat convoluted and drowning in too much YAML.

AgileStacks app templates use a similar approach to provide full stack DevOps automation for Kubernetes based apps. Just push your code and deploy: https://github.com/agilestacks/stack-apps/

This does not seem better.

Is there a reason to not just use Gitlab + Convox + AWS to achieve this? Convox already is an alternative to Heroku that you can run anywhere

Convox is an inspiration. This is using GitLab CI and Terraform.

Peak VC

Nothing stop you to run test before run install when push to heroku :) CI/CD right from heroku.

i use heroku because someone else maintains infrastructure for me. i haven't had to touch apps for years (4+ years) except for security patches or other minor updates and everything just keeps trucking. we have a long way to go to build those systems.

Yea, they're imploding and dying. Probably need to fire a product manager or two.

"Building better Heroku"

... mmmkay

> "A typical web app requires a database, storage or caching backend, which can get complicated to run with Heroku."

Ah no. That is exactly where Heroku is dead easy. The creating, maintaining, updating and general day-to-day management of these "addons" require almost no input from the user. DB failover and mgmt is almost magic.

I wished GitLab would stay away from this needless, click bait type articles. It's not even well researched, almost if they never really ran a serious app on Heroku.

Sure Heroku has quirks (no http2) but I bet a lot less quirks than a homegrown GitLab CI + Terraform solution.

Agree on the storage point, I used their Redis and Postgres options for a few years with no real issues. Everything was seamless, even maintenance. The only complaint I could have would be cost, but that is expected.

Also, using S3 is simple and shouldn't incur much cost due to running in the same AWS region.

You're reading an employee's blog post not a gitlab corporate announcement. It's clear the author hasn't used Heroku's paid services at a larger scale given the points you've already made. I totally agree with the ease of use for Heroku and if you want to eat part of their market share you better make sure you're focused on the right aspect of Heroku.

It's a blog post on the company's official blog, no? I doubt it's like a free-for-all where any employee can post whatever they want without any review. Judging GitLab based on the content posted on their blog seems like fair game.

> It's a blog post on the company's official blog, no?

No. There’s a notice saying it’s unfiltered, with a link leading to a disclaimer saying, pretty much:

> it's like a free-for-all where any employee can post whatever they want without any review.

Or, in their own words:

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

Regardless of its unofficial status, it's a post promoting the company's products in a public space, where the employee is representing the company. As a GitLab employee agrees above, it's fair to judge the company and hold them to a high standard based on how their employees present their work in the public sphere.

> As a GitLab employee agrees above

That employee being the CEO ;)

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.

It's an admirable attempt to break the stuffy "professional" atmosphere. Let people be themselves, imperfections and all. For that, I applaud the effort. Maybe they want to detract the type of person who places this much weight on such silly matters because those exact types in my experience are difficult to work with.

Wow.

sytse, there's no one else I know who's your equal in the kind of leadership you show in managing GitLab.

The transparency, the honesty in everything GitLab does is truly astonishing. Thanks for letting folks like me who know next-to-nothing about building companies be a fly-on-the-wall from oceans away, watch your meetings on YouTube, go through your plans and processes, observe eng designs and discussions around them, among other valuable career-building things. What you're doing is tectonic, all the while continuing to grow what's already a huge business.

Thank you.

Idk about transparent. They deliberately hid their "open compensation calculator."

https://about.gitlab.com/handbook/total-rewards/compensation...

That's increasing opaqueness.

GitLab employee here. That was based on requirements outside of our control - and it is still available to employees and candidates. Everything is public by default, except for things that can't be - but we're public about what isn't public: https://about.gitlab.com/handbook/communication/#not-public

I agree but you're replying to the wrong comment

Thanks, we detached it from https://news.ycombinator.com/item?id=26554734 now.

while the original title created some resentment, I like the idea of the "5 minute production app". Especially, since it is built on an open platform like gitlab. What I would wish, is to not only take hyperscalers into account. I would like this feature to be available on a basic VPS too.

This is pointless as it already exists (Caprover)

qovery.com :)

So this looks like signs that after getting a boat load of money from their VCs, promising to be a "better github", the VCs have realized that they have been played. So it looks like the gitlab team has been asked to pursue other avenues to widen their horizons and get some returns for the VC investments. So they go from "we will be better github" to "we will be better heroku".

How will they do that? "Productized apps for hyperscale cloud". What does that mean? It's a bunch of buzz words our marketing and sales team invented.

Author here.

This post doesn't live up to its title, I'm sorry about that.

The title should have been 'We are building a better Heroku FOR PRODUCTION APPS' (we'll add the 'for production apps' to the title)

It should have emphasized the _building_ part, we're just starting. The current 5 minute production app doesn't hold a candle to Heroku at the moment.

It should have made it clear the goals is to improve the speed with which you can configure a production app, not a development app. Development apps on Heroku are already close to perfect. The examples in this post are contrived since it talks about a development app, as rightly called out by Heroku people https://twitter.com/johnbeynon/status/1374306499426652161

It should have gone into why hyper clouds might be preferable https://gitlab.com/gitlab-org/5-minute-production-app/deploy...

It should have talked about state, we made a small improvement in https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request... but we should have done the planned work in https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/11137 and made one post out of it.

Can you explain what you mean by ‘for production apps’? Because some people are definitely using Heroku in production.

Production apps in a hyper scale cloud

What do you think where Heroku apps run? Why would anyone truly caring about hyperscale trust Gitlab to handle that?

yeah, i've worked at "hyperscale" and not once have we ever thought about gitlab... (nor heroku - but we loved heroku for many small projects)

I assume above commenter was missing a /s. Personally, I don't get the distinction the author is making between production and development apps with regard to heroku

> I assume above commenter was missing a /s.

given that they are a GitLab employee, I doubt that.

Heroku apps run in a hyper scale cloud, sure, but they abstract away all of that. When you "graduate" from Heroku you have to move your entire app and re-architect the entire thing.

The idea behind this effort is to put you in a cloud native hyper cloud environment of your choice to start with and make that just as easy as Heroku. The big difference will be when you "graduate" - you'll already be in AWS or what have you, and under the covers isn't a black box but is a well formed set of GitLab primitives that you can now continue to use and expand upon.

I think the mention "hyperscale" is unnecessarily confusing here. At least in my perception, nearly nobody uses that term when they just talk about "using cloud services from AWS & Co", presumably you don't insist on limiting your product to just those (i.e. Terraform will happily talk to smaller Cloud providers like Hetzner too, presumably you don't intend to exclude them by design, but just understandably focused on the large names first?). People more usually (again, from what I see, you might have different experience with your target groups) explicitly say hyperscale when what they are doing is at that scale, and that's a level of complexity that's never going to be 5 minutes.

Yeah, I agree with the comments that the "for production apps" distinction is a bit weird. I would title it "We are building a Heroku-like experience for big cloud providers".

I can see the point of a service like this and the comparison is cool but there's no need to complain about Heroku, especially when the Gitlab services are not 100% equivalent. If you come for the champ, you'd better not miss and all that.

I like that title a lot - it is a more concise statement.

The title you came up with makes WAY more sense than the actual article. Now I understand what they're doing and that's honestly pretty cool. They just need a better writer.

Reply on news.ycombinator.com