| lo based methodology almost always results in the | | | | Next contemplate the complexity of integrating |
| use of countless different availability / DR | | | | different availability technologies from numerous |
| technologies from various vendors, with noticably | | | | vendors. Are they certain to interoperate with one |
| different designs, capabilities and limited/no integration | | | | another? Is such interoperability built in (not likely) or |
| points. For example, an online web ordering system | | | | will some degree of customization and manual |
| could deploy network load balancing for front end | | | | scripting (very probably) be needed, so that each tier |
| web servers, some form of data mirroring or | | | | can communicate with the other tiers? If custom |
| clustering for backend database servers, and a 3rd | | | | scripting is required, what happens when even a lone |
| party availabilityalternative for middleware. Point of | | | | piece of the availability architecture changes? Will |
| sale solutions, CRM tools, and even BlackBerry | | | | additional, custom consulting work be required to |
| messaging environments implement a similar | | | | update and re test existing scripts? Last but not |
| prescription, employing alternate technologies for | | | | least, if and when something breaks down, whose |
| each layer in the application stack. | | | | responsibility is it to determine the root cause? With |
| Employing such an approach to implementing an | | | | an array of solutions from different vendors, one |
| availability solution for your company application | | | | must be wary of the anticipated finger pointing that |
| ecosystem has numerous drawbacks. First of all, one | | | | may result when things go wrong. |
| must be aware of the cost implications of utilizing | | | | Of course one alternative is to simply not integrate |
| different technologies within an availability or DR | | | | the solutions, after all, so long as each piece is doing |
| architecture. The most apparent cost is the capital | | | | its job, isnt it safe to deduce that the entire system |
| outlay for the hardware/software itself. By choosing | | | | is operational? Not really. Consider for example the |
| (or being forced) to use different solutions from | | | | deployment of a multi tier, distributed architecture |
| different vendors, there is no option to leverage | | | | across physical sites for DR purposes. If the entire, |
| economies of scale. Most hardware and software | | | | primary production site fails, will the servers start up |
| companies offer volume based pricing incentives for | | | | in the right order and fashion at the remote site, or |
| larger order sizes, but this possibility is obviously | | | | will some degree of interaction be required from an |
| squandered when various alternatives from different | | | | administrator? |
| vendors are employed. | | | | Now examine the more likelytype of failure, when |
| Furthermore if each solution leverages different | | | | just one component instead of an entire site fails. |
| underlying hardware, disk, or OS technologies, an | | | | Unless youve set up a combined HA + DR solution, |
| even larger total cost of ownership will be noticed. Of | | | | possibilities are that the single failed component will |
| course cost extends beyond just hardware and | | | | resume operations at the DR site. But in most cases, |
| software to include implementation, training, | | | | the latency between sites will be too high for any |
| andcontinuing management costs. Think | | | | multi tier application to function correctly. In this |
| aboutdeploying even a relatively simple, three tier | | | | situation, its best to actually fail all of the components |
| application architecture. In the online web ordering | | | | across to the remote site as a single, cohesive unit. |
| example explained previously, one would need to deal | | | | But once again, how does this coordination take |
| with the somewhat unnerving task of mastering not | | | | place? Either we are back to scripting the failover in |
| only the intricacies of SQL clustering, but also | | | | some manner, or else some hands on administrator |
| deployment and management of network load | | | | engagement is necessary. When that |
| balancing and any middleware components needed. | | | | happens,recovery times certainly increase; when |
| For every time a new variation of any of these | | | | recovery times increase, so does the bottom line |
| solutions is made, theres the added cost of relearning | | | | cost of the outage to the business. |
| a new technology. | | | | |