The availability guarantees are much easier to keep for a small team than for thousands, so you don't really have to worry about that either.
The availability guarantees are much easier to keep for a small team than for thousands, so you don't really have to worry about that either.
What’s your server’s uptime? Is it highly available? How often do you patch? Do you test them first? How do you keep up with security updates from other software on the machine(s).
How is your security team in general? Do they monitor for stolen credentials? Do pen-tests? Watch for network scans and attacks? Look for weird traffic patterns?
Do you have redundant network links? Backup generators? Do you test them? Sure your datacenter SAYS they have them, but remember when Intuit went down for 2 days a few years ago? I bet they had told their bosses they had generator backups.
Is someone always on call? What are they experts in? How do you get support?
GitHub provides a TON of stuff above a cheap VPS or EC2 instance. And that’s not including the network effects of having so many projects in the same site.
Who cares about uptime, when you use a server alone or with a small team? It can be down for 10 hours and you would not even notice.
You don't understand what you need.
> How often do you patch?
I patch the machine multiple times a week with some "apt update && apt upgrade" which takes literally less then a couple of minutes a week.
> Do you test them first?
I don't need to because I'm using ZFS and make a snapshot before upgrades, so in case of a disaster (which already happened multiple times) I can roll back within minutes, which happened multiple times, once when the machine didn't even booted.
> How is your security team in general? Do they monitor for stolen credentials? Do pen-tests? Watch for network scans and attacks? Look for weird traffic patterns?
You don't need any of that. If you think you do, you think you are far more important than you really are. Maybe framework authors or super-popular library writers would need to worry about that, but self-hosting makes you an order of magnitude lower chance of being a target.
> Is someone always on call? What are they experts in? How do you get support?
We might not talk about the same thing...
> And that’s not including the network effects of having so many projects in the same site.
This is the only valid point you came up with.
Maybe the ineconomy of scale? Except it's not really about scale but about customization, so maybe the "economy of customization".
> You don't understand what you need.
Unfortunately, I think this statement is more often true than not, and it's much easier to go with what's popular right now than to form that understanding.
Of course, there's some merit to that strategy if one is new, but I can't believe that many people are that new.
My non self hosted blog ? Maybe a few hours a year, and I don't have to do anything to restore it.
Buying the server, reading the docs, setting it up, buying an URL domain, binding it to the server, getting the backup server, setting it up, testing that everything works, training the team on the new UI, documenting the whole things for when you are not available or it's not your job anymore, blocking one team of 5 devs from working for 2 hours (or a man day of work) because something went wrong just once...
It's not just resources you spend on useless things. It's resources you take __from__ useful things.
Or worst, you are in a company. Now you have to REQUEST a server, ask a sysadmin to set it up, the security team to approve your software, the budget to validate the payment and the blessing of your network authorities.
Then, you change job/client/whatever. What do you do ? Do it again ?
I think it's getting 10 minutes years old to this day.