Layer 8

When ‘high availability’ isn’t good enough.

I found myself in an interesting conundrum the other day as I was talking to a consultant who was trying to architect a system for me. Now, this guy is a top professional in his field, used to doing this for the Fortune 3.5 or whoever, and he produced a real work of art in the modern style that we call “high availability.” It had synchronization, it had failover, it had clustering, it had all the latest and greatest cornices and articulation and latticework and EVERYTHING.

I couldn’t use it.

Not just because it was too expensive a solution, and not just because of other oddities unique to our environment, but because that level of complexity made it unsupportable by the staff we have in-house.

So we went back to the drawing board, and talked about what WOULD work, and what we came out with was not high availability, but high recoverability. We settled for fewer moving parts, but backfilled with compromises like backups of the VMs so that we could replace them more quickly. Yes, we would have downtime, but with any luck it would be briefer downtime than if we had to bring him back in from the other side of the country to troubleshoot something that only he and a few others at his altitude understood. And with a simpler, more supportable architecture, hopefully that would prevent downtime on the front end to begin with.

So high availability and high recoverability are two sides of the coin that our friend Christofer “SQUIRREL!” Hoff would call “survivability.” (See? I *do* listen to you now and again. )