Live data from Hacker News

Proposed server purchase for GitLab.com

about.gitlab.com

21–30 of 327 posts

Re: Proposed server purchase for GitLab.com

#21

Love how they did some number crunching and decided that rent vs own, own won. I think that if more places looked they would find that out also. There must be a margin in it since the big players are making money at it. I'm interested to see what they end up with in the end.

> Love how they did some number crunching and decided that rent vs own, own won. I think that if more places looked they would find that out also

I wouldn't be so quick to jump to that conclusion. It's not just the cost of owning and renewing the hardware, it's everything else that comes with it. Designing your network, performance tuning and debugging everything. Suddenly you have a capacity issue, now what b/c you're not likely to have a spare 100 servers racked and ready to go, or be able to spin them up in 2m? Autoscaling?

Companies spend enormous amounts of engineering hours to maintain their on-premise solutions. And sometimes that's fine b/c you have requirements that you can't easily do in the cloud (think of high frequency trading for example). However, once you tally all that up, plus all the value added services you can buy in the cloud (just take a look at the AWS portfolio for example) the price might well be worth it. That's not to say you won't need engineers to help you with cloud stuff, but you'll probably need less and they'll be able to focus on solving a different class of problems for you.

> There must be a margin in it since the big players are making money at it.

From what I've seen the players aren't making (lots of) money on providing compute power. They're basically racing against each other to the bottom. What they're making money on is all the value added services, the rest of the portfolio AWS/Google Cloud Platform/Azure offers.

Re: Proposed server purchase for GitLab.com

#23
post #12

It seems based on this post that all the hardware is going to end up in one datacenter. that seems like a big risk if that datacenter ends up having issues. Perhaps look into how to have the nodes split between 2 or 3 different datacenters?

The cost of bandwidth between sites would kill this idea.

Re: Proposed server purchase for GitLab.com

#24
post #10
post #2

I'll be here all day to learn from suggestions. I'm hoping for much feedback so please reference questions with the letter and number: 'Regarding R1'.

I'm curious to know if you think this work is within the core competency of GitLab. if so, how did you decide it was. If not, how do you realize the investment over time in something that isn't? Is the GitLab CEO here?

GitLab CEO here. Hardware and hosting are certainly not our core competencies. Hence all the questions in the blog post. And I'm sure we made some wrong assumptions on top of that. But it needs to become a core competency, so we're hiring https://about.gitlab.com/jobs/production-engineer/

Re: Proposed server purchase for GitLab.com

#25
post #10
post #2

I'll be here all day to learn from suggestions. I'm hoping for much feedback so please reference questions with the letter and number: 'Regarding R1'.

I'm curious to know if you think this work is within the core competency of GitLab. if so, how did you decide it was. If not, how do you realize the investment over time in something that isn't? Is the GitLab CEO here?

[deleted]

Re: Proposed server purchase for GitLab.com

#26
post #13

Earlier quoted context omitted.

Frankfurt surely has a great IX. Even if Frankfurt would make everyone better off (which I'm not sure about) there is another problem. People in the US are used to lower latencies because most SaaS services are hosted there.

I have less of a concern on latency than I do with who has taps in the lines... I would assume that the .de lines are saturated with 5 eyes...

So what location would be out of reach of FVEY? And why would you put secret stuff on Gitlab.com?

Re: Proposed server purchase for GitLab.com

#27
post #13

Earlier quoted context omitted.

Frankfurt surely has a great IX. Even if Frankfurt would make everyone better off (which I'm not sure about) there is another problem. People in the US are used to lower latencies because most SaaS services are hosted there.

I have less of a concern on latency than I do with who has taps in the lines... I would assume that the .de lines are saturated with 5 eyes...

I remain skeptical about the existence of non-tapped lines.

Re: Proposed server purchase for GitLab.com

#28
N1/N2: I think you are making a mistake by concentrating on the advantage of having a single node type. Databases really aren't like other systems.

SuperMicro has a 4 node system available in which each node gets 6 disks, 2028-TP-xx-yyy. Get two of these, populate 2 nodes on each as your databases, and you can grow into the other spaces later. Run your databases on all-SSD; store backups on spinners elsewhere.

Having two node types is not a calamity compared to having just one.

Post reply on HN