Can't wait to find out what happened here. This seems to be a massive outage. Interesting how fragile things become when so much technology is concentrated into just a few companies.
Back when things were more decentralized individual websites and services would have issues much more regularly because the individual software and hardware stacks weren't as robust and fault-tolerant, but then usually the problem would always be limited to a single website/service.
And only when they're not in Kansas, anymore.
MS engineers are waiting for an online purchase of a new $400 keyboard with the Copilot key to complete and planning to run to the data center to plug the keyboard.
However, the Bing outage is preventing the purchase to go through, because the payment somehow relies on Bing suggestions to load for obscure reasons.
I also appreciate that you prevented me from countering using a guard like "if RDP is enabled and working", and that a follow up answer actually provides the missing piece xD.
Note they seem to have managed to fix the Bing frontend hours ago, but DDG is still dead in the water. Priorities... :-)
I can see arguments for both sides. Your point and then the hidden failure modes without central observability and ownership. Nothing exists in isolation.
All else being equal: Yes.
It's like asking if a RAID1 is more resilient than a single drive.
You will have a better chance at uptime with a RAID than a single drive so you hopefully don't have to climb up ventilation ducts, walk across broken glass, and kill anyone sent to stop you on your quest to reconnect those cables that were cut.
With RAID1, there's also nothing specific to the RAID configuration inherent in the way the data is encoded on the disk. You might have to carefully replicate your configuration to access the filesystem from a failed RAID0 array, but you can just pull and individual disk out of a RAID1 array and use it normally as a standalone disk.
A distributed system without redundancy would rather be something like data stripped across disks without parity.
And that actually makes it less resilient, because failure of one component can bring down the whole system and the likelihood of failure is statistically higher because of the higher number of components.
The term "distributed" has been traditionally applied to the original design of the TCP/IP protocol, various application-layer protocols like NNTP, IRC, etc., with the common factor being that each node operates as a standalone unit, but with nodes maintaining connectivity to each other so the whole system approaches a synchronized state -- if one node fails. the others continue to operate, but the overall system might become partitioned, with each segment diverging in its state.
The "RAID0" approach might apply to something like a Kubernetes cluster, where each node of the system is an autonomous unit, but each node performs a slightly different function, so that if any one node fails, the functionality of the overall system is blocked.
That second approach seems more consistent with what we traditionally label as "distributed" -- for example, the original design of the TCP/IP protocol, along with lots of application-layer protocols like NNTP and IRC, have each node operating autonomously but synchronized to other nodes so the whole system approaches a common data state. If one node fails, the other nodes all continue to operate, but might cause the overall system to become partitioned, leading to divergent states in each disconnected segment.
The CAP theorem comes to mind: the first approach maintains availability but risks consistency, the second approach maintains consistency but risks availability. But the second approach seems like a variant implementation strategy for what is still effectively a centralized system -- the overall solution still exists only as a single instance -- so I usually think of the first approach when something is described as "distributed".
>likelihood of failure is statistically higher because of the higher number of components
Yes, absolutely true, but resiliency for a distributed system is not necessarily like your example of data stripped without parity, unless we're specifically talking about distributed storage.
If you want a resilient system redundancy and automatic failover systems are really important, along with solid error handling.
Think about a distributed data store for example. You may spread all your data across multiple distributed areas, but if each area is managing a shard of data and they aren't replications then you still lose functionality when any one region goes down. If you instead have a copy complete copy of data in each region, and a system to automatically switch regions if the primary goes down, your system is much more resilient to outages (though also more complex and expensive).
If tomorow mastodon.social disappear the network might lose 80% of it's content but recovery could be possible even if the server never come back.
Distribution alone doesn't really make a difference, though pairing it was redundancy and failovers is going to get pretty far.
The case of mastodon.social is really a question of whether the value there is the network and protocol itself or the user created content posted there. If its the user content, the value is lost when the one host goes away. If the value is the network and protocol then yes, the value of the network is still there even though the data is gone. It does raise an interesting question of whether Mastodon is really considered distributed or not, the network is and hosts are using a shared protocol but the data isn't really distributed.
One point I find interesting too is that distributed network often allows more agency to external actors. For example if you believe that the resiliency of the mastodon.social instance is not enough for you then you can decide to host you own server with your preferred criteria.
I can host my own server and make my own rules, but every other admin can just ban my instance.
When everybody is using the exact same tech, the fall out of an incident can be huge because it will affect everybody everywhere at the same time. Superficially it might seem efficient and smart, but the end result is fragility.
Diversity of species is what nature ended up with as the ultimate solution: the individual species do not matter, but life as a whole will be able to flourish. With technology, we're now moving the other way: every single thing gets concentrated into one of the few cloud providers. Resilience decreases, fragility increases.
It's actually a hallmark of building fault tolerant systems and ecosystems. Pity the economists and MBA's can't be convinced of it. Otherwise there'd be less push to create TBTF institutions.
A distributed system can be more resilient, but it also adds complexity, making it (sometimes) less reliable.
A single system with a lot of internal redundancy can be more reliable than a poorly implemented distributed system, which is why at a smaller scale it’s often better to scale vertically until a single node can’t handle your needs.
Distributed systems are more of a necessity than “the best way”. If we could just build a single node that scaled infinitely, that would be more reliable than a distributed system.
Only if they've prioritized the "availability" component from the CAP theorem.