Live data from Hacker News

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

about.gitlab.com

241–250 of 275 posts

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

#241
post #212

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 pro…

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.

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

#242
post #219

Earlier quoted context omitted.

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.

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

#243
post #122

Earlier quoted context omitted.

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

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.

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

#244

Earlier quoted context omitted.

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 publish…

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

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

#245
post #122

Earlier quoted context omitted.

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?

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.

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

#246

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

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.

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

#247

Earlier quoted context omitted.

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 publish…

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/

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

#248

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 detai…

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

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?

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

#249

Earlier quoted context omitted.

> 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 publish…

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 addr…

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.

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

#250

Earlier quoted context omitted.

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.
Post reply on HN