Designing for High Availability and Disaster Recovery
Design-driven creation, tools, and Conflicting Design patterns in IT Infrastructure
When design drives creation, results are communicable. Design-first mentalities create solutions that individuals can be trained in effectively. Using the design principles as a vehicle to communicate purpose leads to solutions that can be readily maintained and improved. Naturally, when solutions are built upon tools, the ways the tool is designed to be used must be considered in conjunction with the design of the solution it supports.
The tools chosen impose their design assumptions upon the projects in which they are used. As the previous related blog outlines, a design that is cohesive in concept and purpose is the first step in creating a solution that is understandable. Of course, tools employed by a project can incorporate patterns that are anathemic to the project’s design.
Conflict between the initial design and the tools employed creates complexity and reduces the efficacy of the solution. As such, tools must be selected in a way that the use of the tool is cohesive with the design of the project. When cohesion between the tool and the design is achieved, complexity is reduced. In the context of High Availability and Disaster Recovery, the effects of cohesion between design and tools used are readily apparent.
Designing for High Availability and Disaster Recovery assumed to be complex
Designing for High Availability and Disaster Recovery often carries the assumption of complexity. As IT infrastructure design patterns become increasingly present to meet the high standards intrinsic to High Availability and Disaster Recovery, individual infrastructure components attempt to implement patterns within the scope of that individual component.
As components each work to address the concerns of High Availability and Disaster recovery within the context of their role, environments inherit bloat due to components addressing the concerns of High Availability and Disaster Recovery with divergent design principles.
Infrastructure regularly needs to employ multiple design patterns
Tools grow and can develop competing design principles, yet environments require design that is cohesive. Complexity bleeds into infrastructure as previously unrelated tools begin to interfere with one another. As IT systems grow in terms of purpose and standards of availability, the importance of infrastructure that follows a cohesive design and implements complementary tools grows as well. Technological advancements have provided a myriad of strategies for introducing High Availability and Disaster Recovery, and IT Infrastructure has also grown to accommodate design patterns tailored towards other use cases. Just glance at the common cloud design patterns that Microsoft publishes in its documentation. It is easy to see how each pattern is applicable, but it is just as easy to see how patterns can conflict with one another as well. Pattern overlap is difficult to navigate and can make designing IT infrastructure a difficult process. Infrastructure regularly needs to employ multiple design patterns, and in turn, there is more and more need for patterns that “stay out of each other’s way”.
Author: Philip Merry – Software Engineer at SIOS
Reproduced with permission from SIOS
