Chief Architect Thinking - System Design - Difference Between Deployment Stamps and Disaster Recovery (DR)

Deployment Stamps and Disaster Recovery (DR) concepts are closely related, but they are not the same thing. Think of it this way: Deployment Stamps are a powerful tool or strategy that can make your Disaster Recovery plan much, much better.

Let's break down how they're related and how they're different:

What is Disaster Recovery (DR)?

Disaster Recovery is your overall plan for how your system will recover from a major, unexpected event that causes widespread failure. This could be anything from a natural disaster (like a hurricane hitting a data center), a major power outage, a massive network failure, or even a widespread software bug.

The goal of DR is to:

• Minimize downtime: Get your system working again as quickly as possible.

• Minimize data loss: Make sure you don't lose too much customer data.

DR plans often involve backups, secondary locations, and specific steps to switch over to a recovery site if the main one fails.

What are Deployment Stamps (Again)?

As we discussed, Deployment Stamps means building multiple, complete, and identical copies of your business application, each capable of running on its own. These copies are designed to be independent.

How are Deployment Stamps Related to Disaster Recovery?

Deployment Stamps are a fundamental way to build in resilience that makes your DR almost automatic for many scenarios. They are a pattern that enables strong DR.

Here's how they relate:

1. Built-in Readiness: With stamps, you already have identical copies of your application running (or ready to run) in different places. This means you're not trying to build a recovery site after a disaster; you already have multiple operational sites.

2. Faster Recovery (Often Zero Downtime): If one stamp fails due to a disaster, traffic can simply be rerouted to the other healthy stamps. For users, this can often mean near-zero downtime or just a brief hiccup while traffic switches. This makes your system extremely resilient.

3. Reduced Impact: A disaster affecting one stamp doesn't affect your entire application. This limits the "blast radius" of any event, a core DR goal.

4. Active-Active DR: Stamps allow you to easily set up an "active-active" DR strategy, where all your stamps are handling live user traffic simultaneously. If one fails, the others just pick up the slack. This is the highest level of DR and availability.

5. Proactive Resilience: Instead of reacting to a disaster, stamps build resilience into the core architecture of your application, making it less prone to single points of failure.

How are Deployment Stamps Different from Disaster Recovery Concepts?

While stamps are a fantastic DR enabler, DR is a much broader concept. Here's where they differ:

1. Scope:

   • Deployment Stamps: Focus on the application itself and its direct dependencies (like its database). They are an architectural pattern for deploying your application.

   • Disaster Recovery: Covers the entire IT infrastructure and business processes. This includes things beyond just your application, such as networking, firewalls, identity management systems, physical hardware, and even human procedures for recovery.

2. Data Strategy:

   • Deployment Stamps: A stamp means you have multiple instances of your application. While each stamp might have its own data, stamps alone don't define your data backup, restore, and synchronization strategy. You still need to plan how data is backed up, consistently maintained across stamps, and how you'd recover from data corruption. This is a core DR concern.

   • Disaster Recovery: Explicitly defines data backup schedules, recovery point objectives (RPO – how much data can you afford to lose?), and recovery time objectives (RTO – how quickly can you get the system back?).

3. Testing and Procedures:

   • Deployment Stamps: They enable the possibility of easy failover.

   • Disaster Recovery: Requires formal DR drills and testing to ensure that switching between stamps (or other recovery methods) actually works when a real disaster hits. It defines the specific steps and responsibilities for incident response.

4. Failure Scenarios:

   • Deployment Stamps: Best for failures that affect one independent unit (like a regional outage or a localized software bug).

   • Disaster Recovery: Also considers scenarios that might affect all stamps (e.g., a critical bug introduced across all stamps, a widespread security breach, or a fundamental design flaw that affects all instances). In such cases, you might need to roll back to a prior state from backups, which is a DR concept beyond just having multiple stamps.

In Simple Terms:

• Having Deployment Stamps is like having multiple, identical, fully-stocked stores in different locations. If one store burns down, your business can keep running from the others instantly.

• Disaster Recovery is the entire plan for what to do if a store burns down. This includes how to get the exact inventory count, insurance claims, how to get a new store built, and what emergency steps your staff take. The multiple stores (stamps) make this plan much easier and faster to execute for your customers.

So, Deployment Stamps are a powerful implementation strategy that significantly improves your system's availability and resilience, thereby making your overall Disaster Recovery plan much more effective and proactive. They are a part of a modern DR strategy, but not the entire strategy itself.