Thus far, this series has explored parallels between technical design and rhetoric. The “rhetoric” of a technical solution, the strategy of communicating meaning and purpose, is presented via the design patterns and concepts. The design patterns and concepts exist as a conceptual foundation, upon which the meaning is translated into an applied form when put into practice during implementation.

As previously discussed, the continuity and integrity of this conceptual foundation are paramount to ensuring that solutions are kept up to a standard that is conducive to maintenance, improvement, and long-term reliability. External factors influencing a solution’s design challenge the goal of upholding the conceptual foundations put forth in a solution’s design. These external factors can conflict with the standing principles, and thus, tools, applications, and platforms used in a solution must be chosen mindfully.

In the third and final part of this blog series, modularity and abstraction will be explored as a means to put boundaries in place and ensure that projects with a wide scope can continue to reap the benefits of a well-formed, rhetorically sound design.

High Availability Design Principles: Why Modularity and Abstraction Matter

Before addressing modularization and abstraction as strategies, it is important to understand why these should be implemented. Starting broadly with an analogy, a speaker trying to convince their audience to agree with their plan might first need to outline multiple foundational points. In doing so, each pillar of their argument’s foundation gets put forth and justified.

The speaker first must set up the “A implies B” and “C implies D” basis, upon which they can form the argument “B and D imply E”. This strategy ensures that the reasoning in which “A implies B” does not cross-contaminate and detract from the separate point “C implies D”. This strategy is frequently used because it allows each component of the speaker’s argument to stand independently of others. If the argument “C implies D” is flawed, it can be reconciled while the argument “A implies B” remains sound.

The reason for this structure is the same reason why technical systems are decentralized – a problem in a point of sale system can be remediated without the need to expand the remediation efforts to the databases, APIs, network architecture, and so on. The strategies referenced above are, of course, in reference to the concepts of modularity and abstraction.

Modularity in High Availability Architectures

First, addressing modularity, this is the practice of creating systems from components that are self-contained. In the rhetorical sense, the arguments “A implies B” and “C implies D” are simply modules of reasoning that get assembled into the argument as a whole.

More technically, modularized components (such as the point of sale system in the previous example) allow issues to be addressed entirely within the module where the issue originates.  Each module in the solution acts as a building block, and a problem in a single building block can be resolved without dismantling the entire solution.

Abstraction as a Strategy for Scalable Infrastructure Design

Closely related to modularity is “abstraction”. Abstraction is the practice of ensuring the design of the overall solution is independent and agnostic to the design of the modules that compose the overall solution.

Further, abstraction as a design strategy also holds that each module is independent and agnostic to the design of every other module. When a solution is designed to use abstracted elements, these elements can be reused and applied in use cases that allow for understanding to be amplified throughout the project.

Designing High Availability That “Stays Out of the Way”

When designs are built of modular components, boundaries are drawn. These boundaries ensure that each module can “Stay out of the way” of the other modules. When the components are abstracted, the contents of each module can be understood more easily.

In turn, the boundaries serve as a structure by which the design can be understood, and the abstraction within these boundaries serves as an entry point to understand the foundations of the use case. The structure provided via modularity and abstraction mirrors the role of rhetoric in providing a framework by which purpose is understood.

Managing Complex Network Architectures with Modular HA Solutions

As technical solutions are being developed to address more complex problems, the need for a solid framework in that solution’s design grows as well. Network architecture, often the culmination of many solutions that are complex in their own right, serves as a fantastic example of the increasingly complex problem and growing requirement for solid frameworks in design. Furthermore, network architecture often suffers from continual growth as it has to absorb the sprawling web of systems that contribute to the purpose of a growing business.

Layered on top of this, the solution architecture must then employ solutions for High Availability and/or Disaster Recovery. This creates a hot spot for design conflicts to arise, but can be easily mitigated with the strategies of modularization and abstraction.

Applying Modularity and Abstraction with SIOS High Availability Software

The benefits of High Availability software can be achieved without the baggage of complexity and hacked solutions. SIOS LifeKeeper, as an example of a design-compliant High Availability tool, is created in a way that the principles of its operation can mesh seamlessly with the environment in which it is used.

LifeKeeper is modular, as it does not impose requirements outside of the LifeKeeper-protected systems. LifeKeeper also facilitates the abstraction of infrastructure components to bite-sized elements – systems that work together to ensure availability are grouped into a “cluster”.

Through this abstraction, the rhetoric of the environment remains strong – understanding the makeup of one cluster lays the foundation to understand all clusters. Layers of the design can be understood for their purpose; there is no need for asterisks and special considerations on how implementations differ across the design. As the clusters act independently of other clusters or external solution components, a boundary can be drawn where the design elements of each respective layer are contained, avoiding conflict with other layers of the infrastructure.

Building Long-Term Resilient Infrastructure with SIOS Protection Suite

As with any software or tool, SIOS Protection Suite (SIOS LifeKeeper and/or SIOS DataKeeper) influences the design of environments in which they are used. Though these patterns are brought in by virtue of having a LifeKeeper and DataKeeper protected environment, SIOS LifeKeeper and SIOS DataKeeper carefully selected the patterns in use to ensure that these patterns enable abstraction and modularity within the solution as a whole. As a result of the layered abstraction enabled by both LifeKeeper and DataKeeper, the introduction of these utilities facilitates integration with the IT infrastructure that maintains cohesion in the solution’s design.

As a result of the design patterns employed, clusters protected by SIOS Protection Suite (LifeKeeper and/or DataKeeper) compose an abstract and modular element that fits seamlessly into existing designs and solutions. LifeKeeper and DataKeeper do more than simplify the administration of single systems or each respective cluster; LifeKeeper and DataKeeper work with the principles at play in a deployment.

Creating infrastructure becomes simplified and more efficient as the use of SIOS Protection Suite allows for a simple method of understanding the system’s role in the design, while at the same time providing a simple method for implementing High Availability and Disaster Recovery. Administrators may use LifeKeeper and DataKeeper as a tool to improve their ability to understand, operate, and improve upon the solution for years to come.

See how high availability can support your infrastructure’s design—without adding complexity. Request a demo today!

Author: Philip Merry, CX Software Engineer at SIOS

Reproduced with permission from SIOS