Two application servers can share the same cause of failure

A second application server can take over from a failed process. Whether the customer can keep working also depends on shared components. The next investment should therefore address a named failure rather than just increase the server count.

Microsoft recommends considering redundancy across compute, data and networking along critical workflows. Duplicating the application layer does not answer the question about the complete workflow.

Make the shared path visible

In the fictional example, customers open a project list. Two application instances on separate virtual machines read the same database for it. A single self-managed load balancer sits in front of them. It distributes requests; this example does not mean a managed entry service with internal redundancy. No session data needed for continued use is stored only on one application instance.

The identifiers in the table belong only to this example. Initially there is no replacement for the database or load balancer. The table describes expected effects, not measured availability.

Which failure the second instance can cover

Even the first case is an expectation to test. If the remaining machine is overloaded or routing does not work, its mere existence is insufficient. Two VMs can also share a location, power supply or other infrastructure; the actual failure domains must match the requirement.

Address the shared data layer specifically

If the project list must remain available during database failure, the data layer needs a suitable approach to availability and failover. Acceptable data loss, consistency and the behaviour of ongoing writes must be clarified. A second database process alone does not prove safe continued operation either.

Microsoft distinguishes live replicas from point-in-time backup copies. A backup supports a recovery path; it is not automatically an immediately available running replacement database. Replication does not replace tested recovery after an unintended data change. The measures needed depend on the business objective.

Decide through the affected user workflow

Microsoft’s failure analysis follows each critical workflow and its internal and external dependencies. For our example, the three table cases should be tested separately in an approved test environment. Record detection, behaviour while loading the project list, recovery and the responsible role.

If an agreed recovery path adequately covers a database interruption, the extra application instance may still be useful for process failures or maintenance. If the business requires continued operation during database or entry-path failure, those gaps remain. An availability percentage cannot be derived from the number of machines.

Sources

• Microsoft — Architecture strategies for designing for redundancy

• Microsoft — Architecture strategies for performing failure mode analysis

• Microsoft — Redundancy, replication, and backup