I'm so damn tired of the "host it locally" mentality. Not everyone has the resources to host all of that locally.
For example, most open source projects.
But even outside of that, we use github for issue tracking, the new project management kanban stuff, a CI server, reading documentation (which is offline, but the online versions are nicer on the eyes), and a ton more. Not to mention that StackOverflow and other discussion forums tend to be used by many.
Yes you can host all of that locally, but we don't have a few hundred thousand a year to spend on some sysadmins to maintain all of that, and we don't have the time or money to run the machines, vet the software, and keep it up more reliably than github does for next to nothing.
And I'm so damn tired of people complaining about cost to run stuff locally. The true cost of not having some basic stuff setup locally, even for backup purposes is when situation like this happens. It does not take long time or resources to download all of the libraries, with corresponding docs to a local server, or even your laptop. It is not complicated to have all of the new issues sent to an email to have a version of them available at all times. And you don't need a sysadmin to administer all of that.
>And you don't need a sysadmin to administer all of that.
I disagree with that. If you have a server, you need a sysadmin. End of story.
Who is going to secure the system and setup ssh keys? who is going to run updates? who is going to monitor for security issues? who is going to run backups? who is going to secure those backups? who is going to oversee the installation of the network, the battery backups, the racks, the server hardware, etc... Who will swap out bad disks? Who will recover the system when it goes down? Who is going to double the hardware and setup high availability (remember, you are competing with github for uptime here)? And god help you if you have one guy that does all of this. What happens if he gets hit by a bus?
An on-prem server isn't a "backup", it's a liability. And without the resources to maintain it, it's going to become a nightmare. I've been there, and I won't ever do it again.
I'm either going to pay to do it right, or give it to someone who will. And if that means a few hours of downtime every year or so, then that's a wonderful tradeoff for me.
> It does not take long time or resources to download all of the libraries, with corresponding docs to a local server, or even your laptop. It is not complicated to have all of the new issues sent to an email to have a version of them available at all times.
Luckily github (and alternatives) provide all of that. It sends us emails and slack messages on everything, so if it's down, we can still read, and we all have our local repos. But reading is different than working.
If you have any substantial business, you already have a sysadmin on your team. He's not doing his job if he has no local versions of almost everything that is online. He should be staging everything locally, before deploying to the cloud. The currently very popular way of deploying everything live, without any testing, or staging is one of the reasons behind current crappy state of the internet.
I disagree, with very large companies, you have no "local" sysadmin, and no local versions of anything. Especially if your IT department is actually its own company.
If self-hosted, somewhere, you could still be screwed by having Dyn as your DNS provider.
If dev-machine-hosted, then uh, your issue tracker is no longer an issue tracker. Your build server is not a build server. All the services besides Git are not meant to operate offline in a decentralized/distributed fashion.
Library documentation, sure, that could be local. Otherwise, your assertion that all of this tools infrastructure can somehow be replicated, easily, in a way that makes the difference between working online or offline effectively zero, is nonsense.
First of all I'm not saying that the whole infrastructure could be replicated, only critical parts, and parts that can be easily hosted locally.
Second, pointing to a new machine is as simple as updating IP in your hosts file, or dns server.
Third, you can use vmware or any other virtualization stack to replicate your infrastructure locally. In fact that's the best way to build things - create virtual network, use it for testing, troubleshooting and debugging, and deploy only when everything is working.
All I'm saying is that if you're company is making any kind of money, and your development environment depends 100% on online services, you're doing it wrong.
Not that I'm saying that you're completely wrong, but you're oversimplifying the problem and the solution to it. Your last statement is not necessarily true; you have to balance the cost and how much of a PITA it is to set up and maintain vs how much money would be lost by disgruntled customers for a single rare outage. Granted, it depends on the kind of business you are running, but not every business is so fragile. In fact, I'd say that most(as in >50%) are not that fragile. Even better when you can simply put the blame on someone else, which everyone can do in our case right now.
I'm under the impression that you say self-hosted ~= dev-machine-hosted ?
If that's the case, i think you're misguided : imho, the internet as it was designed was conceived so that everyone has its little self-hosted thing, with dev-machine just for the purpose of, well, test and dev, with the latter goal of it being self-hosted.
Just look how email is technically designed and how it was meant to work, and we use it now, relying mostly on Gmail or Outlook, or worse, using Facebook for emails : we put all our eggs in the same basket.
If I were running a business, here are the options as I'd see them:
Option A) Spend no money and experience an outage maybe once a year, if that. And the problem works itself out.
Option B) Spend money and gain technical debt to avoid a problem that happens maybe once a year, if that.
Which one would you pick? I mean, maybe if everything you have is closed-source or you are guaranteeing 99.9% uptime to your customers, perhaps option B makes sense. Otherwise, the choice seems fairly obvious to me.
What's your source that you "experience an outage maybe once a year" ??
I work in IT infrastructure and I see attacks literally every day, moreover, most people just setup a quick LAMP or MEAN stack to prove their concept, and then they leave it like that, so most of the time, no, the problem don't just "work itself out".
