> Most folks overestimate their need for availability and lack a willingness to accept risk.
I disagree. More specifically, I think, instead, many [1] folks just don't make that assessment/estimate in the first place.
They just follow what they perceive to be industry best practices. In many ways, this is more about social proof than a cargo cult, even though the results can resemble the latter, such as elsewhere in this thread with a comment complaining they had a "resilient" setup in a single cloud that was shut down by the provider.
> There are distinct benefits that come with avoiding "HA" setups. Namely simplicity and speed.
Indeed, and, perhaps more importantly, being possible at all, given time ("speed") and money ("if you can afford it").
The same could be said of "scalability" setups, which can overlap in functionality (though I would argue that in cases of overlap the dual functionality makes the cost more likely to be worth it).
None of this is to say, though that "HA" is synonymous with "business continuity". It's much like the conceptual difference between RAID and backups, and even that's not always well understood.
[1] I won't go so far as to say "most" because that would be a made up statistic on my part
Agreed for the most part. Availability for very many is a binary operation. They either do none of it or all of it.
A clever man once said, "you own your availability".
An exercise in BC planning can really pay off. If infra is code, and it and the data are backed up reasonably well, then a good MTTR can obviate the need for a lot of HA complexity.
> Availability for very many is a binary operation. They either do none of it or all of it.
I assume I'm missing some meaning here, particularly since the premise of much of the discussion in the thread is that there can be high availability at one layer, but it can rendered irrelevant by a SPoF at another (especially when the "layer" is the provider of all of ones infrastructure).
Do you consider that a version of "none"? Or are you pointing out that, despite the middle ground under discussion, the "binary" approach is more common, if not more sensible?
The binary approach is that it either isn't considered or people opt in for all of it without consideration for what is actually needed. The Google SRE book goes into this at length. For each service, they define SLOs and make a considered decision about how to meet them.
Oh, so what you're saying is that they're no considering the notion that there may be a medium-availability (for lack of a better term) solution, which could be perfectly adequate/appropriate?
I disagree. More specifically, I think, instead, many [1] folks just don't make that assessment/estimate in the first place.
They just follow what they perceive to be industry best practices. In many ways, this is more about social proof than a cargo cult, even though the results can resemble the latter, such as elsewhere in this thread with a comment complaining they had a "resilient" setup in a single cloud that was shut down by the provider.
> There are distinct benefits that come with avoiding "HA" setups. Namely simplicity and speed.
Indeed, and, perhaps more importantly, being possible at all, given time ("speed") and money ("if you can afford it").
The same could be said of "scalability" setups, which can overlap in functionality (though I would argue that in cases of overlap the dual functionality makes the cost more likely to be worth it).
None of this is to say, though that "HA" is synonymous with "business continuity". It's much like the conceptual difference between RAID and backups, and even that's not always well understood.
[1] I won't go so far as to say "most" because that would be a made up statistic on my part