At the time that you made your comment, I think it had the potential to be accurate for a lot more people because at that time my understanding is that the outage was ongoing.
With the incident now resolved, I have the benefit of hindsight to say it was down for a total of two hours, which is well within error budget to maintain 99.5% monthly uptime, and since this isn't part of a larger pattern (so far), they're within budget for 99.95% yearly.
I think that for most companies that aren't already heavily invested in a highly available container runtime platform, the cost of this kind of downtime will be less than the cost of self-hosting something better. Especially if they're not in a situation where registry downtime implies an equal amount of customer-facing service downtime.
Not really, you're just trading one kind of downtime for another. You're not gonna get much meaningful improvement unless you implement actual redundancy. Docker makes this a giant PITA because they want you to use docker.io. It should be as easy as adding a second hosted registry or an additional private registry to the Docker search path (and it is that easy on Red Hat builds of Docker) but the official builds don't support it.
Readit News
https://status.docker.com/pages/incident/533c6539221ae15e3f0...
Well now I know.
With the incident now resolved, I have the benefit of hindsight to say it was down for a total of two hours, which is well within error budget to maintain 99.5% monthly uptime, and since this isn't part of a larger pattern (so far), they're within budget for 99.95% yearly.
I think that for most companies that aren't already heavily invested in a highly available container runtime platform, the cost of this kind of downtime will be less than the cost of self-hosting something better. Especially if they're not in a situation where registry downtime implies an equal amount of customer-facing service downtime.