7 ms·

>If they said tomorrow that we had to pay $60 a month to get what we're getting now 0 to 60 overnight sounds like a very disastrous thing for a company to do,

>If they said tomorrow that we had to pay $60 a month to get what we're getting now 0 to 60 overnight sounds like a very disastrous thing for a company to do, like a big ol bait and switch. I would immediately stop using that company and find alternatives, and I am guessing it will be the same for a lot of people too. At 60usd a month for 5 people, a developer should be able to buy a few servers(~4) for less than $30-$40, selfhost something like gitea with drone.

xupybd 4y ago
Yes you could but that is a shift in responsibility. At that point we are responsible for keeping that infrastructure running. Any failure ties up internal resources. At the scale of 1 developer and 2 freelancers it doesn't make so much sense. There are far more valuable things we can do for the business than remove that $60 USD cost.
onion2k 4y ago
selfhost something like gitea with drone And then set up the users Then set up the permissions And the hooks And move repos to it Then set up deployments, figuring out how to replace any missing Gitlab features Then update the docs that describe how the repo structure works for onboarding Etc etc Moving infrastructure is a couple of days work at least for a small team. If you factor than cost into it then it's rarely worthwhile. And that's before any time lost to investigating and fixing outages, updating the software, and so on.
- fendy3002 4y ago
  People are severely underestimating how complicated it is to host a private server, even if they go to self hosted gitlab which essentially the same. The amount of downtime, sudden server crash, problem with SSL with NAT, setting up gitlab runner, upgrading, etc. You'll need someone experienced enough and maybe even a dedicated infra role to handle those things
  - Aeolun 4y ago
    > You'll need someone experienced enough and maybe even a dedicated infra role to handle those things Depends on where you are are doing it. AWS makes it ridiculously easy to hand off basically all aspects of hosting. Set up once, use forever.
    - nicce 4y ago
      AWS does not go to this category. You are literally paying for them to handle these matters.
  - simfree 4y ago
    We've been running Gitlab for over half a decade with over 100 repos, runners on Windows, Linux and Mac with minimal need for maintenance. Same story for the primary free software project we rely on (who we have a support contract with). Neither us nor them spend anywhere close to 10 hours a year on maintaining selfhosted Gitlab related infrastructure.
  - linspace 4y ago
    > People are severely underestimating how complicated it is to host a private server People underestimate consistently how complicated is to build reliable things, hardware or software. There is a world between "it works for me" and "it works for all"
    - pooper 4y ago
      And dysfunctional organizations. I worked as a contractor at one place where we simply used the shared file server as a git remote. Reasoning was if the file server was down, it would come back up quickly because it affects everyone. I didn't understand this reasoning until I got emails from the database team saying the database servers stopped working and every development team now needs to change their connection string from machinename-abc.corp to machinename-bcd.corp How in the world someone could write an email like that is beyond me. Ok machines crash all the time but why can't they reuse the same name for the new machine?
- azinman2 4y ago
  Don’t forget backups, testing to make sure they work, etc
- KronisLV 4y ago
  > Selfhost something like gitea with drone I actually recently did just that, moving over everything from my self-hosted GitLab instance into Gitea, Drone CI and Nexus: https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-nexus-and-drone https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-... (the same would apply when moving from a cloud GitLab instance to the other self-hosted solutions) Edit: fixed the link now. Honestly, it wasn't so bad, given that I didn't couple what I had too tightly to the functionality of GitLab in particular - having an external issue tracker, though moving CI and build artifact storage systems can indeed necessitate porting them over (which was easy, given that I mostly use Dockerfiles and shell scripts for builds anyways) and cause additional work. > And then set up the users; Then set up the permissions; And move repos to it Thankfully, nowadays neither is too hard to do, given that there are pretty good migration scripts which will work, unless you're doing something very non-standard and peculiar. I migrated close to a 100 repositories with not a single failure, though perhaps that's also because I don't mess around with Git LFS after being burnt whilst trying to sync GitLab and GitHub repos with LFS data going into a black hole. > And the hooks; Then set up deployments, figuring out how to replace any missing Gitlab features The good thing here in particular was the fact that I use Docker for builds as mentioned before, so getting "docker build -t ... -f ... ." working across different build systems is generally pretty easy (except for Jenkins which is needlessly hard sometimes), especially when the software for the CI runner nodes themselves runs in Docker containers (with trusted code you can also just share the Docker socket, otherwise you probably want a DinD setup). Deployments are also just telling another system (Portainer/Docker Swarm in my case; sometimes Helm for Kubernetes) that it should retrieve the latest build artifacts from some OCI compatible repo and run the new version of the application with any given configuration. > Then update the docs that describe how the repo structure works for onboarding I don't think that I've ever actually needed to change this, since while the UI itself does change (e.g. organizations vs groups), the actual contents of a particular repository itself remain the same. Might need to update an URL or two, but for the most part I saw no blockers here. > Moving infrastructure is a couple of days work at least for a small team. If you factor than cost into it then it's rarely worthwhile. It took me less than a day, total. But maybe that's because I've built a bit of a pipeline around running containers in my infrastructure and have the ingress/reverse proxy setup around them all established. Not to sound cocky, there are also caveats and things that I do agree with you in regards to pain points (below). > And that's before any time lost to investigating and fixing outages, updating the software, and so on. This is probably the bigger issue here, though. All of the sudden, the stability of it all is your responsibility. Now, in my case that wasn't such a change in circumstances because I started out with GitLab and with my limited hardware setup moving over to Gitea and friends was actually a win from a resiliency standpoint vs an integrated GitLab Omnibus install (that loves to eat RAM). For for anyone moving from the cloud to an on-prem infrastructure, this is definitely one of the main concerns. That said, for many out there storing their code and other stuff in the cloud is a non-starter (e.g. certain government orgs or enterprises), which is where self-hosting can indeed be very helpful, though in most cases I've seen GitLab instances be used instead of Gitea. That said, Gitea is also an excellent option for anyone who just wants to embrace self-hosting out of principle or other reasons. Being in control of your data is pretty cool (at least until you misconfigure something and everyone is in control of your data). That said, if you don't buy into the balkanization of software platforms nowadays too much and focus on the common standards of the systems instead, overall it's not as painful as one might think. Of course, you can also pick a platform that's too hard to actually use and administer (which is why I switched away from GitLab) by yourself, but then the question becomes of why you're even using it in the first place. Honestly, GitLab is an excellent platform with amazing features, but handling updates and its hardware requirements wasn't fun: https://blog.kronis.dev/everything%20is%20broken/gitlab-updates-are-broken https://blog.kronis.dev/everything%20is%20broken/gitlab-upda... Oh, also sometimes migrating data can be downright hellish, like when I tried migrating SVN to Git, with migration scripts not working due to non-standard repo layouts, which meant that I had to rewrite the layouts and history on the SVN end so things would actually work properly and those scripts wouldn't hang. Though it was ages ago and I haven't used SVN that much recently, Tortoise SVN was a nice piece of software though, RIP.
inopinatus 4y ago
Transferring all the administrative burden and operational risk whilst incurring the additional expense of SRE time makes the business case here look dead in the water.
aaaaaaaaaaab 4y ago
$60 is like 30-60min at a developer’s hourly rate.
- KronisLV 4y ago
  > $60 is like 30-60min at a developer’s hourly rate. More like 4 hours of my salary (~2100 euros per month after taxes), given that I live in Eastern Europe and work for a local company. I think that there is definitely an interesting shift in opinions towards expenditure towards software, platforms and tools. The poorer a particular nation (and its developers) are on average, the more inclined everyone is towards a mindset of "doing instead of buying", given how their own time is comparatively less valuable than paying someone else to do it. Then again, the same applies to the software that they use, personally I pay for the Ultimate package of all the JetBrains products (their IDEs are really good), but a lot of my acquaintances only use free software, or other means of acquiring it. Kind of why a lot of Russia and other countries over there (if you look eastwards) is running on pirated Windows machines. Curiously, that's also why something like AWS is out of reach for me and instead I use local platforms like Time4VPS, or something like Hetzner/Scaleway/Contabo.
  - 5e92cb50239222b 4y ago
    Makes sense. I am from an even poorer ex-soviet country. I think we have zero (or very close to zero) subscriptions, use no external services for anything critical, and host everything ourselves. It's not only much cheaper, but faster as well (when the closest datacenter is 150 ms away, the difference is obvious). It also protects us in case the dictator does something stupid and we get cut off because of sanctions or inability to pay. I've seen an even stronger drive towards self-hosting since February of this year, just in case.
raverbashing 4y ago
$60 is nothing compared to a developer's salary Sure, you could setup with 4 machines and think this is costing you only $40 per month, if you take out all the maintenance and setup time
sokoloff 4y ago
“Would you like to pay $60 a month to avoid a yak shave and on-going yak beard trimming?” Yes, I would. I’m often accused of being somewhat too frugal, but in this case frugality points me strongly towards paying the $60/mo.

xupybd 4y ago

Yes you could but that is a shift in responsibility. At that point we are responsible for keeping that infrastructure running. Any failure ties up internal resources. At the scale of 1 developer and 2 freelancers it doesn't make so much sense. There are far more valuable things we can do for the business than remove that $60 USD cost.

onion2k 4y ago

selfhost something like gitea with drone And then set up the users Then set up the permissions And the hooks And move repos to it Then set up deployments, figuring out how to replace any missing Gitlab features Then update the docs that describe how the repo structure works for onboarding Etc etc Moving infrastructure is a couple of days work at least for a small team. If you factor than cost into it then it's rarely worthwhile. And that's before any time lost to investigating and fixing outages, updating the software, and so on.

fendy3002 4y ago
People are severely underestimating how complicated it is to host a private server, even if they go to self hosted gitlab which essentially the same. The amount of downtime, sudden server crash, problem with SSL with NAT, setting up gitlab runner, upgrading, etc. You'll need someone experienced enough and maybe even a dedicated infra role to handle those things
- Aeolun 4y ago
  > You'll need someone experienced enough and maybe even a dedicated infra role to handle those things Depends on where you are are doing it. AWS makes it ridiculously easy to hand off basically all aspects of hosting. Set up once, use forever.
  - nicce 4y ago
    AWS does not go to this category. You are literally paying for them to handle these matters.
- simfree 4y ago
  We've been running Gitlab for over half a decade with over 100 repos, runners on Windows, Linux and Mac with minimal need for maintenance. Same story for the primary free software project we rely on (who we have a support contract with). Neither us nor them spend anywhere close to 10 hours a year on maintaining selfhosted Gitlab related infrastructure.
- linspace 4y ago
  > People are severely underestimating how complicated it is to host a private server People underestimate consistently how complicated is to build reliable things, hardware or software. There is a world between "it works for me" and "it works for all"
  - pooper 4y ago
    And dysfunctional organizations. I worked as a contractor at one place where we simply used the shared file server as a git remote. Reasoning was if the file server was down, it would come back up quickly because it affects everyone. I didn't understand this reasoning until I got emails from the database team saying the database servers stopped working and every development team now needs to change their connection string from machinename-abc.corp to machinename-bcd.corp How in the world someone could write an email like that is beyond me. Ok machines crash all the time but why can't they reuse the same name for the new machine?
azinman2 4y ago
Don’t forget backups, testing to make sure they work, etc
KronisLV 4y ago
> Selfhost something like gitea with drone I actually recently did just that, moving over everything from my self-hosted GitLab instance into Gitea, Drone CI and Nexus: https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-nexus-and-drone https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-... (the same would apply when moving from a cloud GitLab instance to the other self-hosted solutions) Edit: fixed the link now. Honestly, it wasn't so bad, given that I didn't couple what I had too tightly to the functionality of GitLab in particular - having an external issue tracker, though moving CI and build artifact storage systems can indeed necessitate porting them over (which was easy, given that I mostly use Dockerfiles and shell scripts for builds anyways) and cause additional work. > And then set up the users; Then set up the permissions; And move repos to it Thankfully, nowadays neither is too hard to do, given that there are pretty good migration scripts which will work, unless you're doing something very non-standard and peculiar. I migrated close to a 100 repositories with not a single failure, though perhaps that's also because I don't mess around with Git LFS after being burnt whilst trying to sync GitLab and GitHub repos with LFS data going into a black hole. > And the hooks; Then set up deployments, figuring out how to replace any missing Gitlab features The good thing here in particular was the fact that I use Docker for builds as mentioned before, so getting "docker build -t ... -f ... ." working across different build systems is generally pretty easy (except for Jenkins which is needlessly hard sometimes), especially when the software for the CI runner nodes themselves runs in Docker containers (with trusted code you can also just share the Docker socket, otherwise you probably want a DinD setup). Deployments are also just telling another system (Portainer/Docker Swarm in my case; sometimes Helm for Kubernetes) that it should retrieve the latest build artifacts from some OCI compatible repo and run the new version of the application with any given configuration. > Then update the docs that describe how the repo structure works for onboarding I don't think that I've ever actually needed to change this, since while the UI itself does change (e.g. organizations vs groups), the actual contents of a particular repository itself remain the same. Might need to update an URL or two, but for the most part I saw no blockers here. > Moving infrastructure is a couple of days work at least for a small team. If you factor than cost into it then it's rarely worthwhile. It took me less than a day, total. But maybe that's because I've built a bit of a pipeline around running containers in my infrastructure and have the ingress/reverse proxy setup around them all established. Not to sound cocky, there are also caveats and things that I do agree with you in regards to pain points (below). > And that's before any time lost to investigating and fixing outages, updating the software, and so on. This is probably the bigger issue here, though. All of the sudden, the stability of it all is your responsibility. Now, in my case that wasn't such a change in circumstances because I started out with GitLab and with my limited hardware setup moving over to Gitea and friends was actually a win from a resiliency standpoint vs an integrated GitLab Omnibus install (that loves to eat RAM). For for anyone moving from the cloud to an on-prem infrastructure, this is definitely one of the main concerns. That said, for many out there storing their code and other stuff in the cloud is a non-starter (e.g. certain government orgs or enterprises), which is where self-hosting can indeed be very helpful, though in most cases I've seen GitLab instances be used instead of Gitea. That said, Gitea is also an excellent option for anyone who just wants to embrace self-hosting out of principle or other reasons. Being in control of your data is pretty cool (at least until you misconfigure something and everyone is in control of your data). That said, if you don't buy into the balkanization of software platforms nowadays too much and focus on the common standards of the systems instead, overall it's not as painful as one might think. Of course, you can also pick a platform that's too hard to actually use and administer (which is why I switched away from GitLab) by yourself, but then the question becomes of why you're even using it in the first place. Honestly, GitLab is an excellent platform with amazing features, but handling updates and its hardware requirements wasn't fun: https://blog.kronis.dev/everything%20is%20broken/gitlab-updates-are-broken https://blog.kronis.dev/everything%20is%20broken/gitlab-upda... Oh, also sometimes migrating data can be downright hellish, like when I tried migrating SVN to Git, with migration scripts not working due to non-standard repo layouts, which meant that I had to rewrite the layouts and history on the SVN end so things would actually work properly and those scripts wouldn't hang. Though it was ages ago and I haven't used SVN that much recently, Tortoise SVN was a nice piece of software though, RIP.

inopinatus 4y ago

Transferring all the administrative burden and operational risk whilst incurring the additional expense of SRE time makes the business case here look dead in the water.

aaaaaaaaaaab 4y ago

$60 is like 30-60min at a developer’s hourly rate.

KronisLV 4y ago
> $60 is like 30-60min at a developer’s hourly rate. More like 4 hours of my salary (~2100 euros per month after taxes), given that I live in Eastern Europe and work for a local company. I think that there is definitely an interesting shift in opinions towards expenditure towards software, platforms and tools. The poorer a particular nation (and its developers) are on average, the more inclined everyone is towards a mindset of "doing instead of buying", given how their own time is comparatively less valuable than paying someone else to do it. Then again, the same applies to the software that they use, personally I pay for the Ultimate package of all the JetBrains products (their IDEs are really good), but a lot of my acquaintances only use free software, or other means of acquiring it. Kind of why a lot of Russia and other countries over there (if you look eastwards) is running on pirated Windows machines. Curiously, that's also why something like AWS is out of reach for me and instead I use local platforms like Time4VPS, or something like Hetzner/Scaleway/Contabo.
- 5e92cb50239222b 4y ago
  Makes sense. I am from an even poorer ex-soviet country. I think we have zero (or very close to zero) subscriptions, use no external services for anything critical, and host everything ourselves. It's not only much cheaper, but faster as well (when the closest datacenter is 150 ms away, the difference is obvious). It also protects us in case the dictator does something stupid and we get cut off because of sanctions or inability to pay. I've seen an even stronger drive towards self-hosting since February of this year, just in case.

raverbashing 4y ago

$60 is nothing compared to a developer's salary Sure, you could setup with 4 machines and think this is costing you only $40 per month, if you take out all the maintenance and setup time

sokoloff 4y ago

“Would you like to pay $60 a month to avoid a yak shave and on-going yak beard trimming?” Yes, I would. I’m often accused of being somewhat too frugal, but in this case frugality points me strongly towards paying the $60/mo.