| This silo based methodology pretty much always | | | | availability technologies from multiple vendors. Are |
| results in the use of countless different availability / | | | | they guaranteed to interoperate with one another? |
| DR technologies from various vendors, with | | | | Is such interoperability built in (not likely) or will some |
| noticeably different designs, capabilities and limited/no | | | | level of customization and manual scripting (very |
| integration points. For example, an online web | | | | likely) be required, so that each tier can communicate |
| ordering system might make use of network load | | | | with the other tiers? If custom scripting is required, |
| balancing for front end web servers, some form of | | | | what happens when even a single piece of the |
| data mirroring or clustering for backend database | | | | availability architecture changes? Will extra, custom |
| servers, and a 3rd party availability alternative for | | | | consulting work be required to update and re test |
| middleware. Point of sale solutions, CRM tools, and | | | | existing scripts? Last but not least, if and when |
| even BlackBerry messaging environments implement | | | | something breaks down, whose responsibility is it to |
| a similar prescription, employing different technologies | | | | establish the root cause? With an array of solutions |
| for each and every layer in the application stack. | | | | from different vendors, one must be wary of the |
| Taking such an approach to executing an availability | | | | inevitable finger pointing that may result when things |
| solution for your company application ecosystem has | | | | go bad. |
| several drawbacks. Initially, one must be aware of | | | | Of course one choice is to simply not integrate the |
| the cost implications of utilizing assorted technologies | | | | solutions, after all, so long as every part is doing its |
| within an availability or DR architecture. The most | | | | job, isn't it safe to assume that the total system is |
| obvious cost is the equity outlay for the hardware | | | | operational? Not really. Consider for example the |
| software alone. By selecting (or being forced) to use | | | | deployment of a multi tier, distributed architecture |
| different solutions from different vendors, there is no | | | | across physical sites for DR purposes. If the entire, |
| possibility to leverage economies of scale. Most | | | | primary production site fails, will the servers start up |
| hardware and software companies offer volume | | | | in the correct order and fashion at the remote site, |
| based pricing incentives for larger order sizes, but this | | | | or will some amount of interaction be necessary from |
| opportunity is obviously squandered when multiple | | | | an administrator? |
| alternatives from different vendors are used. | | | | Now consider the more likely type of failure, when |
| Additionally if each solution leverages different | | | | just one component instead of an entire site fails. |
| underlying hardware, disk, or OS technologies, an | | | | Unless you've deployed a combined HA + DR |
| even higher total cost of ownership will be realized. | | | | solution, possibilities are that the single failed |
| Of course cost extends beyond just hardware and | | | | component will resume operations at the DR site. But |
| software to include implementation, training, and | | | | in most cases, the latency between sites will be too |
| ongoing management costs. Consider deploying even | | | | high for any multi tier application to function correctly. |
| a pretty basic, three tier application architecture. In | | | | In this scenario, its best to actually fail all of the |
| the online web ordering example explained previously, | | | | components across to the remote site as a single, |
| one would need to deal with the somewhat daunting | | | | cohesive unit. But once again, how does this |
| task of learning not only the intricacies of SQL | | | | coordination take place? Either we are back to |
| clustering, but also deployment and management of | | | | scripting the fail over in some way, or else some |
| network load balancing and any middleware | | | | hands on administrator engagement is required. When |
| components needed. Each time a new version of any | | | | that arises, recovery times certainly increase; when |
| of these solutions is made, there's the additional cost | | | | recovery times increase, so does the bottom line |
| of relearning a different technology. | | | | expense of the outage to the business. |
| Then consider the complexity of integrating disparate | | | | |