Is that actually bad? A chain is only as strong as its weakest link, so if my system depends on many sites then even one outage can take me down. Centralizing like this can actually reduce risk.
If you had separate services the CI service database going down would not affect anything else. A centralised database for all the services will take down all the services when it borks
If your priority is profit or cost management then duplicated infrastructure will make no sense
Decentralizing on the other hand makes it possible to replace individual links.
If GitHub goes down you can switch to Gitlab. But you can't do that if you're using GitHub for git and issues and CI and static sites, etc.
wow, when I read this, it is actually much cleaner than what I would use as in the past: the overall system strength is min {i in 0...m} subsystem[i] where m is the total number of subsystems
A sum of constituents is more likely to be a situation where you're fine if at least one of the options works (e.g. a cluster with redundancy).
This will actually get you a semiring (easy to check), although whether that is really useful remains to be seen. It's nice to have anyway.
With git's distributed nature, this would be very much possible.
Also, pushing to a mirror is not exactly the thing you want.
What makes apt easier is that pretty much everybody is just downloading from the source or from a mirror. When the source stops, mirrors don't get updated and everything still works. That's very different from the usage model that people have with Github.
Gihub/Gitlab have extended the Git usage model very much, they are not just git. You can't easily migrate away from them to another git offering (and not even very easily between both).