Live data from Hacker News

Why we are not leaving the cloud

about.gitlab.com

21–30 of 216 posts

Re: Why we are not leaving the cloud

#21
Gitlab is hosted on Azure and like many startups received six figures worth of free credits to be in the cloud.

As the credits run out the architecture reverts to the natural state - architectures tend to be the derivative of organizational structure, code base, and processes of a company.

Through this lens these decisions start making more sense. It is a reactionary process. Sometimes when you start small you bounce around like that and are lucky enough to grow for years and years until you hit a wall.

Re: Why we are not leaving the cloud

#22
post #5

Buried towards the bottom is the interesting decision to dump CephFS and go with NFS instead.

I find that interesting as well. Furthermore, looking into deploying containers with cheap cloud hosters , I was curious how to share data across various nodes by looking at how Google and Amazon do it. Turns out it's still NFS. I've never looked into networked FS before, but I thought they'd move past NFS to something more advanced...and newer I suppose.

Re: Why we are not leaving the cloud

#23
So, GitLab based a crucial part of their company on some random comments that were just quoted and could be said the other way around as well? Were is your own thinking and your own decision making?

Bare metal doesn't mean colocation. It also doesn't mean going bare metal only, you could go with a hybrid approach and save the base costs while maintaining the cloud scalability.

Re: Why we are not leaving the cloud

#24

Hmm. Nearly all the commenters seem to be "extreme", i.e. either full-cloud or full-bare-metal. Why not go hybrid? Do your baseline load with bare-metal and your spike load with AWS, GCE or Azure Cloud.

You are adding more points of failure and complexity. To what, save some money? Which is fine, but then most of the arguments against pure on-prem apply. Save money but a lot of complexity. If your on-prem dies, most hybrid cloud setups will die.

Re: Why we are not leaving the cloud

#25

It's interesting that the first half of the explanation is largely quotes from a prior HN post's responses. Does anyone else feel a bit weird seeing off hand comments getting quoted in the explanation for a business decision? I guess we should all get more accustomed to our public input carrying weight in the zeitgeist. Gitlab's "develop in the open" nature really shows through here. I am not saying that's bad, it's…

We quote a lot of responses from HN but that doesn’t mean it’s the only thing that led us to this decision. I was personally involved in a lot of private conversations about this, with the executive team, with investors and with people who had gone through this exercise before, and they all had as much if not more impact on our final decision than the HN thread did. It’s just harder to quote them than referencing additional (& similar) opinions noted in a public forum.

Re: Why we are not leaving the cloud

#26
post #23

So, GitLab based a crucial part of their company on some random comments that were just quoted and could be said the other way around as well? Were is your own thinking and your own decision making? Bare metal doesn't mean colocation. It also doesn't mean going bare metal only, you could go with a hybrid approach and save the base costs while maintaining the cloud scalability.

[deleted]

Re: Why we are not leaving the cloud

#27
post #7

Where is the original thought? There were few hard numbers. There was way too much quoted material and no Gitlab thoughts on it. It looks like they made the post based on feelings instead of a metric like time or dollars.

[deleted]

Re: Why we are not leaving the cloud

#28
I'm a little shocked at this decision. The issues faced are all solved problems from PB storage to HA on server clusters even across Data centers. Good solutions do have upfront costs but the math that cloud hosting is 5-10X more than co-location company owned/leased is still in the ball park. It sounds like they may need an architect with enterprise experience to help them out rather than random comments on HN.

Re: Why we are not leaving the cloud

#29
post #11

It's interesting that the first half of the explanation is largely quotes from a prior HN post's responses. Does anyone else feel a bit weird seeing off hand comments getting quoted in the explanation for a business decision? I guess we should all get more accustomed to our public input carrying weight in the zeitgeist. Gitlab's "develop in the open" nature really shows through here. I am not saying that's bad, it's…

I don't think they were using this as justification or explanation in their eventual reversal. I think they provided these quotes as interesting tidbits. Kind of like pull-out quotes on an article. You can ignore them entirely and still get the gist of the post. On a more general note: It's got to be incredibly hard to do what GitLab does with their extreme transparency. I feel like we have to be careful about readin…

Thanks. The most useful advice was shared in private. People coming to our office to share war stories of regretting moving to bare metal. I also received dozens of people sending direct messages via twitter because they couldn't share their stories publicly. Some of the best advice are things that we can't share publicly. For example a major company going bare-metal and then spending a lot of time to set up an authorization system that you get for free with AWS IAM.

Re: Why we are not leaving the cloud

#30
post #5

Buried towards the bottom is the interesting decision to dump CephFS and go with NFS instead.

I wonder if Amazon's new managed EFS service would make sense? It's exposed as a NFS mount to the OS. The claims are:

- Up to thousands of Amazon EC2 instances, from multiple AZs, can connect concurrently to a file system.

- Data is stored redundantly across multiple AZs.

- Low, consistent latency.

- Multiple GBs per second.

Post reply on HN