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.
The chain is still the same length when centralised and may be weaker. Separate services would use separate databases but it would make sense to consolidate resources when centralised
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
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
Depends on how it's done, if it's one authority with many mirrors it can be more reliable. Take for example `apt` in debian, you can always find a mirror online.
With git's distributed nature, this would be very much possible.
Will you also mirror CI infrastructure, issues, pages, documentation, API-consulting scripts, etc?
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).
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