Redundant Implementation

How can the reliability and availability of a service be increased?

Problem A service that is being actively reused introduces a potential single point of failure that may jeopardize the reliability of all compositions in which it participates if an unexpected error condition occurs.
Solution Reusable services can be deployed via redundant implementations or with fail-over support.
Application The same service implementation is repeated or supported by infrastructure with redundancy features.	Impacts Extra governance effort is required to keep all redundant implementations in synch and properly represented within service registries.
Principles Service Autonomy	Architecture Service

Table 6.19 – Profile summary for the Redundant Implementation pattern.

Problem

Agnostic services are prone to repeated reuse by different service compositions. As a result, each agnostic service can introduce a single point of failure for each composition. Considering the emphasis on repeated reuse within service-orientation, it is easily foreseeable for every complex composition to be comprised of multiple agnostic services and therefore run the risk of multiple failure points.

With a means of guaranteeing the reliability and availability of agnostic services, the robustness of the entire service inventory is constantly at risk.

Figure 6.84 – When a highly reused service becomes unexpectedly unavailable, it will jeopardize all of its service consumers.

Solution

Multiple implementations of agnostic services with high reuse potential or providing critical reusable functionality can be installed to guarantee high availability even when unexpected exceptions or outages occur.

Figure 6.85 – Having redundant implementations of agnostic services provides fail-over protection should any one implementation go down.

Application

The application of this pattern does not always require actual, separate redundant service implementations. Common infrastructure extensions, such as fail-over or clustering, can be leveraged to increase the overall reliability and availability of agnostic services.

Impacts

While this pattern improves the reliability and scalability of service inventories as a whole, it clearly brings with it some tangible impacts. The foremost of which is an increased purchasing and maintenance cost to the inventoryŐs underling infrastructure.

Additional hardware requirements and administration effort will be needed for each redundant implementation. Furthermore, additional governance responsibilities are added in order to keep all redundant implementations in synch, should the service be refactored or extended.

Relationships

Agnostic services naturally have the most concurrent usage demands and therefore have the greatest need for autonomy and fail-over support. This is why the Redundant Implementation pattern is important to services defined via the Entity Abstraction and Utility Abstraction patterns. However, even non-agnostic services realized via the Inventory Endpoint pattern may require Redundant Implementation due to reliability or security requirements.

The Composition Autonomy pattern will often repeatedly apply Redundant Implementation to ensure that as many services participating in the composition can achieve increased levels of isolation.

To establish a redundant deployment of a service that requires access to shared data sources will usually demand the involvement of the Service Data Replication pattern. And, as with most patterns, the effects of this pattern support Capability Recomposition, in particular in the areas of increased reliability and performance.

Figure 6.86 – The Redundant Implementation patternŐs goal of supporting the Service Autonomy design principle affects several other more specialized (autonomy-related) patterns.

Case Study Example

Case study content is not available on this Web site.