Hacker News Reader

Comment by sytse | Hacker News Reader

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.

View on HN

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.

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.

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

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?

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

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.

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.

Reply on news.ycombinator.com