4 ms·

Hopefully now they will realize that they should run on a colo rather than be wholly on the cloud... and hire for that expertise (their previous attempt to do s

Hopefully now they will realize that they should run on a colo rather than be wholly on the cloud... and hire for that expertise (their previous attempt to do so was a bit amateurish, which is understandable ). Nothing blows money faster than unlimited storage and unlimited bandwidth when you're not charging for it... And before you down vote me, realize that github, their main competitor, runs on a colo for this very same reason. No matter how much revenue you get from paid accounts, and selling on-prem installs, the free service popularity which fuels the paid revenue will outpace it for the forseable future. Trying to reign in those cost, isn't a bad ( or hard ) thing.

hackbinary 9y ago
Could you clarify what you mean by the difference between colo vs on-prem? We run their on-prem in our colo, and it works great for us.
- SteveNuts 9y ago
  He's talking about where GitLab should run their services from. He meant GitLab should purchase hardware and move into a colo rather than run off of cloud services.
- joeblubaugh 9y ago
  I believe he means that the "SaaS option" is run in the cloud by GitLab itself, which is probably very expensive given that the nature of the service is both storage and network-intensive. If GitLab operated their own datacenter(s) it could be considerably less expensive.
- citruspi 9y ago
  I think keepper meant that GitLab.com (the hosted service) should colo instead of running in the cloud[0]. [0]: https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-the-cloud/ https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-t...
- zaidf 9y ago
  Colocated hosting refers to a kind of hosting where Gitlab puts their own hardware inside of a data center. They primarily pay the data center for physical space (also called rackspace), bandwidth and power but they don't pay for the the server itself since the physical hardware belongs to you. Dedicated hosting is similar to colocated hosting with the only difference being the physical server is rented to you by the data center. This is different from cloud hosting because unlike cloud hosting, with dedicated servers you are the only customer using the physical server that is located in the data center. An off-shoot of dedicated hosting is a VPS (virtual private server.) VPS can be seen as a mix of cloud and dedicated in that the physical server's resources are split between x customers but each customer has their own virtual machine with root access.
- keepper 9y ago
  It was definitely not one of my better worded comments :) colo == renting space/cooling/power from a datacenter provider to run your own servers. on-prem == on premise installs/support They have two revenue models, SaaS and Selling you support [1]. Giltlab has a "loss leader strategy" like many online businesses. The difference is that in this case, their free plan will grow so exponentially fast, it will become a huge cost center. Also, to add to my simplistic post above, colo wasn't meant to only imply Gitlab having to run everything, for example, they could go with a managed provider, and have them run the network/hardware site of things. This is also still substantially less expensive than the cloud, when your biggest bills will be storage and bandwidth ( which of course, is my assumption ). From their tech postings, it seems their problem domain doesn't allow them to utilize s3 or any other other massive scale distributed storage, so they have been primarily utilizing block storage.[2][3] [1]https://about.gitlab.com/products/ https://about.gitlab.com/products/ [2]https://about.gitlab.com/2015/01/03/the-hardware-that-powers-100k-git-repos/ https://about.gitlab.com/2015/01/03/the-hardware-that-powers... [3]https://about.gitlab.com/2016/11/10/why-choose-bare-metal/ https://about.gitlab.com/2016/11/10/why-choose-bare-metal/
deleted 9y ago
[deleted]
ethomson 9y ago
Yes, this is true to an extent. But price is one of many factors that go into GitHub's design decisions for infrastructure planning. (I used to work on the Git Infrastructure team at GitHub, which is responsible for exactly this.) Nor is it the _first_ consideration. Price is important (obviously) but only after performance and resiliency. Putting repositories on bare metal on-premises makes sense for GitHub's architecture. They run git itself, which is happiest packbuilding with as many IOPS as it can manage. But they've also built out a number of custom performance monitoring and load balancing applications, and any single Git repository is replicated across a number of servers using spokes, their custom Git load balancing system. They run on-premises because they've done a detailed analysis of their needs and hired a staff of developers and infrastructure experts to deliver it. And as a result, they're the world's largest Git hosting provider. But you _can_ be perfectly happy in the cloud. Visual Studio Team Services hosts its Git repositories in Azure. Since VSTS didn't start out hosting Git repositories, but Git repository management was added _after_ it already had a cloud-first architecture, it didn't make sense to host repositories on-disk. (Nor would relying on Git for Windows have been performant five years ago.) Instead, VSTS built out custom Git server implementation to take advantage of storing repositories in SQL Azure and Azure Blob Storage. And this implementation scales up to the needs of Microsoft's customers - both external and internal - who are hosting the world's largest Git repositories. So I think that you can be happy on-premises _or_ in the cloud. I think it comes back 100% to your point that you need to hire for that expertise.
- revelation 9y ago
  Visual Studio Team Services surely doesn't pay list price for their bandwidth on Azure. It's the same company! Azure is the colo! You seem to assume running a colo means having some bearded Linux admin on staff that runs all the applications with init.d on bare metal. Not so, kubernetes is a thing. They wisely haven't chained themselves to any of the critical proprietary Azure lockins.
  - ethomson 9y ago
    No - although I am an aging unix neckbeard, I do not assume that you _need_ that to be successful.
yuhong 9y ago
I have been thinking about whether GitLab should opt for the M version Xeons when they finally get their servers so they can upgrade to 128GB TSV LR-DIMMs in the future.

hackbinary 9y ago

Could you clarify what you mean by the difference between colo vs on-prem? We run their on-prem in our colo, and it works great for us.

SteveNuts 9y ago
He's talking about where GitLab should run their services from. He meant GitLab should purchase hardware and move into a colo rather than run off of cloud services.
joeblubaugh 9y ago
I believe he means that the "SaaS option" is run in the cloud by GitLab itself, which is probably very expensive given that the nature of the service is both storage and network-intensive. If GitLab operated their own datacenter(s) it could be considerably less expensive.
citruspi 9y ago
I think keepper meant that GitLab.com (the hosted service) should colo instead of running in the cloud[0]. [0]: https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-the-cloud/ https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-t...
zaidf 9y ago
Colocated hosting refers to a kind of hosting where Gitlab puts their own hardware inside of a data center. They primarily pay the data center for physical space (also called rackspace), bandwidth and power but they don't pay for the the server itself since the physical hardware belongs to you. Dedicated hosting is similar to colocated hosting with the only difference being the physical server is rented to you by the data center. This is different from cloud hosting because unlike cloud hosting, with dedicated servers you are the only customer using the physical server that is located in the data center. An off-shoot of dedicated hosting is a VPS (virtual private server.) VPS can be seen as a mix of cloud and dedicated in that the physical server's resources are split between x customers but each customer has their own virtual machine with root access.
keepper 9y ago
It was definitely not one of my better worded comments :) colo == renting space/cooling/power from a datacenter provider to run your own servers. on-prem == on premise installs/support They have two revenue models, SaaS and Selling you support [1]. Giltlab has a "loss leader strategy" like many online businesses. The difference is that in this case, their free plan will grow so exponentially fast, it will become a huge cost center. Also, to add to my simplistic post above, colo wasn't meant to only imply Gitlab having to run everything, for example, they could go with a managed provider, and have them run the network/hardware site of things. This is also still substantially less expensive than the cloud, when your biggest bills will be storage and bandwidth ( which of course, is my assumption ). From their tech postings, it seems their problem domain doesn't allow them to utilize s3 or any other other massive scale distributed storage, so they have been primarily utilizing block storage.[2][3] [1]https://about.gitlab.com/products/ https://about.gitlab.com/products/ [2]https://about.gitlab.com/2015/01/03/the-hardware-that-powers-100k-git-repos/ https://about.gitlab.com/2015/01/03/the-hardware-that-powers... [3]https://about.gitlab.com/2016/11/10/why-choose-bare-metal/ https://about.gitlab.com/2016/11/10/why-choose-bare-metal/

deleted 9y ago

[deleted]

ethomson 9y ago

Yes, this is true to an extent. But price is one of many factors that go into GitHub's design decisions for infrastructure planning. (I used to work on the Git Infrastructure team at GitHub, which is responsible for exactly this.) Nor is it the _first_ consideration. Price is important (obviously) but only after performance and resiliency. Putting repositories on bare metal on-premises makes sense for GitHub's architecture. They run git itself, which is happiest packbuilding with as many IOPS as it can manage. But they've also built out a number of custom performance monitoring and load balancing applications, and any single Git repository is replicated across a number of servers using spokes, their custom Git load balancing system. They run on-premises because they've done a detailed analysis of their needs and hired a staff of developers and infrastructure experts to deliver it. And as a result, they're the world's largest Git hosting provider. But you _can_ be perfectly happy in the cloud. Visual Studio Team Services hosts its Git repositories in Azure. Since VSTS didn't start out hosting Git repositories, but Git repository management was added _after_ it already had a cloud-first architecture, it didn't make sense to host repositories on-disk. (Nor would relying on Git for Windows have been performant five years ago.) Instead, VSTS built out custom Git server implementation to take advantage of storing repositories in SQL Azure and Azure Blob Storage. And this implementation scales up to the needs of Microsoft's customers - both external and internal - who are hosting the world's largest Git repositories. So I think that you can be happy on-premises _or_ in the cloud. I think it comes back 100% to your point that you need to hire for that expertise.

revelation 9y ago
Visual Studio Team Services surely doesn't pay list price for their bandwidth on Azure. It's the same company! Azure is the colo! You seem to assume running a colo means having some bearded Linux admin on staff that runs all the applications with init.d on bare metal. Not so, kubernetes is a thing. They wisely haven't chained themselves to any of the critical proprietary Azure lockins.
- ethomson 9y ago
  No - although I am an aging unix neckbeard, I do not assume that you _need_ that to be successful.

yuhong 9y ago

I have been thinking about whether GitLab should opt for the M version Xeons when they finally get their servers so they can upgrade to 128GB TSV LR-DIMMs in the future.