11 ms·

This is one thing feel intuitively but have trouble arguing. When a solution requires running a server, I mentally count it as much more expensive than if it's

by kqr 5y ago

This is one thing feel intuitively but have trouble arguing. When a solution requires running a server, I mentally count it as much more expensive than if it's done locally and synchronously. I've noticed not everyone shares this bias, and I'm wondering if I'm unnecessarily conservative or other people are underestimating maintenance costs.

pid-1 5y ago
"just run your own git server" comments always make me scratch my head. IMO folks managing services for personal use vastly underestimate how much harder everything can get in an actual business environment.
- nijave 5y ago
  I don't think it's necessarily just "personal use". The complexity quickly scales with the company size. Replacing Github with Gitlab might be a week-long project at a small company but could easily turn into a multi-year project at a large one. It's not just a technical problem, either. Bigger companies tend to have more expertise-oriented teams (security, compliance, developer tooling, operations, internal infrastructure) which tends to make decisions more difficult than when a single person or team can do it themselves.
  - vlunkr 5y ago
    > Replacing Github with Gitlab might be a week-long project at a small company A week-long project initially. Now you have to install updates, set up and maintain secure access, reboot or troubleshoot when it dies, etc. Installing things is the easy part.
    - netizen-936824 5y ago
      What kind of a company doesn't have at least one sysadmin, I feel like that's kind of a critical position for maintaining systems?
      - buffet_overflow 5y ago
        The problem is when they have more services than sysadmins. While the sysadmins are busy upgrading the git server, the logging infrastructure suffers. They pivot to work on that, now the CI/CD server is down/slow/randomly breaking. But the sysadmin that knew the ins and outs of it left last quarter so the new sysadmins don't want to touch it. Oh, and management doesn't prioritize any of this stuff, so actually jumping two versions on the git server is a much bigger, fragile ordeal now than it was a month ago.
        CameronNemo 5y ago
        Exactly. Our team of 6 sysadmins manages: - DNS appliances, storage appliances, NTP appliances, - hypervisors, Dev/stage/prod k8s clusters, some other k8s clusters - dev/prod Elasticsearch/Logstash/Kibana clusters - internal GitLab, Jira, Confluence, nautobot, OpenDCIM, a deprecated Twiki - several internal custom apps - Probably more I am forgetting. Nothing gets patched consistently. Everything is neglected to a certain degree.
        rhizome 5y ago
        I'm not going to die on this hill, but that seems like a lot of complexity for a company with in-house skills, maybe even the worst of both (in-house vs cloud/managed) worlds.
        stevekemp 5y ago
        In a previous job I managed a migration from bitbucket (!) to self-hosted Github Enterprize. As part of the migration I forced the creation of a monthly "backup restore test". Every month we had a recipe to spin up a new instance of the Github appliance, and import the most recent backup into it. A lot of systems do tend to get a little neglected over time, and of course different organizations have different priorities, but I insisted on this because I figured for that particular company the Github instance was one of the most critical components - if it is down people can't work.
      - icedchai 5y ago
    - coward123 5y ago
      No kidding. I would have preferred to migrate the client to GitHub, but they were convinced that wasn't acceptable - had to run their own GitLab. Turned into a mess of managing Gitlab updates and BS rather than working on the product.
- marginalia_nu 5y ago
  A git server is just a computer with ssh access, though. Git itself is designed in a way where it doesn't even need a server. If you keep it simple, it stays simple.
  - nijave 5y ago
    Sure but the article isn't talking about a "git" server. It's talking about replacing Github with Gitlab which is a fully integrated developer workflow tool with code review functionality. They use "Git server" a lot in the article, but the opening and closing both specifically mention a Github replacement.
    - marginalia_nu 5y ago
      Right, but git itself has no concept of code reviews, if that's what you want, maybe you shouldn't be looking for a git server, but some mechanism for code reviews.
      - jeltz 5y ago
        Yes? That is presumably exactly what they are looking for. They just worded it poorly. The reason people use GitHub and Gitlab is usually not because they want a git server. For that there are much better tools like gitolite.
  - maccard 5y ago
    A postgres server is just a computer with 5432 open instead of 22. > If you keep it simple, it stays simple. Things that work well for one person in isolation don't work at scale or for teams. How do you handle authentication for your git server? What about backups? Manage disk space? Updates? That's before you get to the point of dealing with workflows and integrations, or "it's slow when 10 people clone at the same time"
    - marginalia_nu 5y ago
      Every cloned git repository is a backup. That's like the entire point of git. It's decentralized version control. This is why the notion of a "git server" is a bit of an oxymoron. Most of the things you're struggling to solve are effectively preventing it from actually working as intended.
- deleted 5y ago
  [deleted]
deleted 5y ago
[deleted]
jasode 5y ago
>When a solution requires running a server, I mentally count it as much more expensive than if it's done locally and synchronously. Are you comparing server vs local desktop software? The author's article is actually comparing server-SaaS vs server-on-premise (or server-self-managed-cloud-vm-container).
- kqr 5y ago
  I'm comparing anything that requires uptime monitoring to something that does not, in essence.
MereInterest 5y ago
By "requires running a server", do you mean that it requires you personally to run a server, or that it requires the seller of the solution to run a server? Asking because those are two very different costs to me. For the former, it means that there is time and money investment in running the server, but that my continued use is only limited by my willingness to keep the server up. For the latter, it means that the solution may be end-of-lifed at any time, and I have no control over when that happens.
jeffalyanak 5y ago
While there's definitely always a cost to consider when running a server, I think a good portion of that cost can be reduced with the right tooling an expertise. That's not to say that a experienced team can run an infinite number of arbitrary services without cost or anything like that, though. There may be a select few situations where the cost of deployment and maintenance is negligible, but that's going to be the exception rather than the rule.
gurjeet 5y ago
I wrote a few browser based small apps at q.ht [1], in the hopes that once written and tested, I will never have to maintain that code or infrastructure. While most of those tchotchke apps are still still functioning as designed, the PDF generator (that uses pdf.js) in Life-in-Weeks app [2] has somehow broken apart. It doesn't generate the PDFs like it used to. Despite so much of care and effort put into making these decisions, to not have to maintain/upkeep the software, the utopia remains elusive. [1]: http://q.ht http://q.ht (served via Github Pages, see https://github.com/gurjeet/q.ht https://github.com/gurjeet/q.ht) [2]: http://q.ht/life-in-weeks-on-one-sheet/ http://q.ht/life-in-weeks-on-one-sheet/
rhizome 5y ago
>I'm wondering if I'm unnecessarily conservative or other people are underestimating maintenance costs. Check out some of the HN posts where people talk about how much companies spend on AWS and calculate how many sysadmin/devop salaries those bills could pay for (it is commonly >1). Probably even easier would be to find a company that's about 10-15 years old and see how much their tech spend declined when they switched to the cloud. ;)
Havoc 5y ago
A hypervisor on LAN with decent tooling can be a neat. Definitely prefer that over on desktop local for near everything. Once it’s off site then it becomes a hassle cause security and per usage billing and all the other fun surprises that cloud comes with

by kqr 5y ago

pid-1 5y ago

"just run your own git server" comments always make me scratch my head. IMO folks managing services for personal use vastly underestimate how much harder everything can get in an actual business environment.

nijave 5y ago
I don't think it's necessarily just "personal use". The complexity quickly scales with the company size. Replacing Github with Gitlab might be a week-long project at a small company but could easily turn into a multi-year project at a large one. It's not just a technical problem, either. Bigger companies tend to have more expertise-oriented teams (security, compliance, developer tooling, operations, internal infrastructure) which tends to make decisions more difficult than when a single person or team can do it themselves.
- vlunkr 5y ago
  > Replacing Github with Gitlab might be a week-long project at a small company A week-long project initially. Now you have to install updates, set up and maintain secure access, reboot or troubleshoot when it dies, etc. Installing things is the easy part.
  - netizen-936824 5y ago
    What kind of a company doesn't have at least one sysadmin, I feel like that's kind of a critical position for maintaining systems?
    - buffet_overflow 5y ago
      The problem is when they have more services than sysadmins. While the sysadmins are busy upgrading the git server, the logging infrastructure suffers. They pivot to work on that, now the CI/CD server is down/slow/randomly breaking. But the sysadmin that knew the ins and outs of it left last quarter so the new sysadmins don't want to touch it. Oh, and management doesn't prioritize any of this stuff, so actually jumping two versions on the git server is a much bigger, fragile ordeal now than it was a month ago.
      - CameronNemo 5y ago
        Exactly. Our team of 6 sysadmins manages: - DNS appliances, storage appliances, NTP appliances, - hypervisors, Dev/stage/prod k8s clusters, some other k8s clusters - dev/prod Elasticsearch/Logstash/Kibana clusters - internal GitLab, Jira, Confluence, nautobot, OpenDCIM, a deprecated Twiki - several internal custom apps - Probably more I am forgetting. Nothing gets patched consistently. Everything is neglected to a certain degree.
        rhizome 5y ago
        I'm not going to die on this hill, but that seems like a lot of complexity for a company with in-house skills, maybe even the worst of both (in-house vs cloud/managed) worlds.
        stevekemp 5y ago
        In a previous job I managed a migration from bitbucket (!) to self-hosted Github Enterprize. As part of the migration I forced the creation of a monthly "backup restore test". Every month we had a recipe to spin up a new instance of the Github appliance, and import the most recent backup into it. A lot of systems do tend to get a little neglected over time, and of course different organizations have different priorities, but I insisted on this because I figured for that particular company the Github instance was one of the most critical components - if it is down people can't work.
    - icedchai 5y ago
  - coward123 5y ago
    No kidding. I would have preferred to migrate the client to GitHub, but they were convinced that wasn't acceptable - had to run their own GitLab. Turned into a mess of managing Gitlab updates and BS rather than working on the product.
marginalia_nu 5y ago
A git server is just a computer with ssh access, though. Git itself is designed in a way where it doesn't even need a server. If you keep it simple, it stays simple.
- nijave 5y ago
  Sure but the article isn't talking about a "git" server. It's talking about replacing Github with Gitlab which is a fully integrated developer workflow tool with code review functionality. They use "Git server" a lot in the article, but the opening and closing both specifically mention a Github replacement.
  - marginalia_nu 5y ago
    Right, but git itself has no concept of code reviews, if that's what you want, maybe you shouldn't be looking for a git server, but some mechanism for code reviews.
    - jeltz 5y ago
      Yes? That is presumably exactly what they are looking for. They just worded it poorly. The reason people use GitHub and Gitlab is usually not because they want a git server. For that there are much better tools like gitolite.
- maccard 5y ago
  A postgres server is just a computer with 5432 open instead of 22. > If you keep it simple, it stays simple. Things that work well for one person in isolation don't work at scale or for teams. How do you handle authentication for your git server? What about backups? Manage disk space? Updates? That's before you get to the point of dealing with workflows and integrations, or "it's slow when 10 people clone at the same time"
  - marginalia_nu 5y ago
    Every cloned git repository is a backup. That's like the entire point of git. It's decentralized version control. This is why the notion of a "git server" is a bit of an oxymoron. Most of the things you're struggling to solve are effectively preventing it from actually working as intended.
deleted 5y ago
[deleted]

deleted 5y ago

[deleted]

jasode 5y ago

>When a solution requires running a server, I mentally count it as much more expensive than if it's done locally and synchronously. Are you comparing server vs local desktop software? The author's article is actually comparing server-SaaS vs server-on-premise (or server-self-managed-cloud-vm-container).

kqr 5y ago
I'm comparing anything that requires uptime monitoring to something that does not, in essence.

MereInterest 5y ago

By "requires running a server", do you mean that it requires you personally to run a server, or that it requires the seller of the solution to run a server? Asking because those are two very different costs to me. For the former, it means that there is time and money investment in running the server, but that my continued use is only limited by my willingness to keep the server up. For the latter, it means that the solution may be end-of-lifed at any time, and I have no control over when that happens.

jeffalyanak 5y ago

While there's definitely always a cost to consider when running a server, I think a good portion of that cost can be reduced with the right tooling an expertise. That's not to say that a experienced team can run an infinite number of arbitrary services without cost or anything like that, though. There may be a select few situations where the cost of deployment and maintenance is negligible, but that's going to be the exception rather than the rule.

gurjeet 5y ago

I wrote a few browser based small apps at q.ht [1], in the hopes that once written and tested, I will never have to maintain that code or infrastructure. While most of those tchotchke apps are still still functioning as designed, the PDF generator (that uses pdf.js) in Life-in-Weeks app [2] has somehow broken apart. It doesn't generate the PDFs like it used to. Despite so much of care and effort put into making these decisions, to not have to maintain/upkeep the software, the utopia remains elusive. [1]: http://q.ht http://q.ht (served via Github Pages, see https://github.com/gurjeet/q.ht https://github.com/gurjeet/q.ht) [2]: http://q.ht/life-in-weeks-on-one-sheet/ http://q.ht/life-in-weeks-on-one-sheet/

rhizome 5y ago

>I'm wondering if I'm unnecessarily conservative or other people are underestimating maintenance costs. Check out some of the HN posts where people talk about how much companies spend on AWS and calculate how many sysadmin/devop salaries those bills could pay for (it is commonly >1). Probably even easier would be to find a company that's about 10-15 years old and see how much their tech spend declined when they switched to the cloud. ;)

Havoc 5y ago

A hypervisor on LAN with decent tooling can be a neat. Definitely prefer that over on desktop local for near everything. Once it’s off site then it becomes a hassle cause security and per usage billing and all the other fun surprises that cloud comes with