CH13-06: Hybrid Cloud Architecture Scenario

Goal

This chapter has built a hybrid model from dependency flow, connectivity, control planes, migration stages, and operations. This section applies the model to one enterprise migration scenario.

The durable idea is:

A strong hybrid design explains which dependencies cross environments, how they are controlled, and who operates them.

Scenario

A manufacturing company is modernizing internal systems.

It wants to move two applications to Azure:

• A production scheduling application used by plant operations.

• A reporting application used by managers and finance teams.

Several dependencies remain in the data center:

• The ERP system that owns production orders and inventory.

• A SQL Server database used by legacy manufacturing applications.

• Existing identity and group management.

• File exports used by finance and supplier workflows.

• Existing monitoring and security inspection processes.

The company does not want each workload team to create its own network connection. It wants a shared hybrid platform path that can support the first applications and later migrations.

First-Pass Architecture

A reasonable first-pass design is:

On-premises data center
  +-- ERP system
  +-- SQL Server databases
  +-- identity and DNS dependencies
  +-- existing firewalls and monitoring
       |
       v
ExpressRoute for production, VPN for pilot or backup where appropriate
       |
       v
Azure hub network
  +-- gateway
  +-- Azure Firewall or inspection path
  +-- DNS resolver or forwarding pattern
  +-- shared monitoring integration
       |
       v
Workload spokes
  +-- scheduling app spoke
  +-- reporting app spoke
  +-- private endpoints for Azure services
       |
       v
Azure platform services
  +-- App Service or Container Apps
  +-- Azure SQL or Storage where migrated data fits
  +-- Key Vault, Monitor, and Application Insights

The exact services may change, but the responsibility structure is clear: shared connectivity and inspection live in the hub, workloads live in spokes, and dependencies are mapped before migration.

Responsibility Map

The design is not only a network diagram. It is an ownership and dependency map.

Dependency Walkthrough

The scheduling application moves to Azure first. It still calls the ERP system for production orders and inventory status.

The path is:

Scheduling app in Azure spoke
  -> route table sends ERP traffic through hub
  -> Azure Firewall logs and allows approved ERP calls
  -> ExpressRoute carries traffic to data center
  -> on-premises firewall allows spoke address range
  -> ERP API responds through the expected return path

That flow requires:

• DNS for the ERP API name from Azure.

• Routes from spoke to hub and hub to data center.

• Firewall rules on both sides.

• Identity or application credentials for ERP access.

• Logs that connect one user action to the ERP dependency call.

• A runbook for ERP or connectivity outage.

The reporting application has a different dependency pattern. It may ingest extracts or replicated data rather than call ERP synchronously for every report. That difference matters. Reporting can often tolerate scheduled ingestion or eventual consistency better than production scheduling can.

Migration Stages

The company can move in stages:

Each stage should have review criteria. A pilot path should not become the production platform by accident.

Important Trade-Offs

The architecture needs to explain trade-offs clearly.

ExpressRoute or VPN

ExpressRoute fits the long-term production path because several critical workloads will depend on the data center. VPN may still be useful for pilots, backup, or lower-criticality scenarios. The decision depends on requirements, not the name of the service.

Direct Database Access or Data Movement

The scheduling app may need live ERP calls. Reporting may not. If reporting can use replicated or curated data in Azure, it may avoid frequent cross-boundary database queries and reduce latency risk.

Central Inspection or Workload Autonomy

Central inspection gives security visibility and consistent control. It can also create a bottleneck if firewall changes are slow or capacity is undersized. Workload teams need a clear request and exception process.

Temporary or Steady-State Hybrid

Some paths may be temporary during migration. Others may remain for years. Each should have an owner, monitoring, cost visibility, and a review date.

Failure Handling

The design should explain what happens when dependencies fail.

This makes the scenario operational, not just connected.

Common Mistakes

• Designing the network path before mapping application, data, DNS, identity, and batch dependencies.

• Giving every workload its own hybrid connection instead of using a governed shared path.

• Ignoring DNS and private endpoint behavior until testing starts.

• Treating the reporting app and scheduling app as if they need the same data freshness and latency.

• Keeping temporary migration patterns permanently without review.

• Assigning no owner for firewall changes, route changes, DNS forwarding, or hybrid incident coordination.

If Someone Asks You

How would you design a hybrid Azure architecture?

A good answer is:

I would start by mapping dependencies across environments: applications, data, identity, DNS, APIs, file shares, batch jobs, monitoring, and security controls. Then I would design a shared hybrid connectivity path, often using hub-spoke networking with VPN or ExpressRoute based on requirements. The hub would carry shared connectivity, DNS, and inspection, while workload spokes keep applications separated. I would define routing, private access, firewall rules, telemetry, runbooks, owners, migration stages, and exit criteria for temporary paths.

What You Should Remember

Walk dependency by dependency: connectivity, identity, DNS, data, security, operations, and migration stage.

Questions to Check Your Understanding

1. Which dependencies cross environments in the scenario?

2. Why does hub-spoke design help?

3. How does the design support troubleshooting and ownership?