Skip to content

Design Principles

Introduction

Designing applications for the Azure hybrid continuum requires thinking beyond traditional cloud-native or on-premises patterns. The principles in this chapter are derived from the Azure Well-Architected Framework but extended and adapted for hybrid and sovereign cloud scenarios where connectivity, control, and compliance requirements vary dramatically.

These principles form the foundation for building workloads that can operate successfully across all positions on the continuum—from fully cloud-native to completely air-gapped environments. Each principle addresses specific challenges that emerge when applications must span multiple infrastructure models.

Core Design Principles

Design for Portability

Principle: Build applications that can move across the continuum without fundamental redesign.

In hybrid architectures, workloads may need to migrate between deployment models due to regulatory changes, cost optimization, or business requirements. Portability is not just about containerization—it's about abstracting infrastructure dependencies and externalizing environment-specific configuration.

Implementation strategies:

  • Container orchestration as compute abstraction: Use Kubernetes as the common compute layer across all environments. Containers provide a consistent runtime whether running in Azure Kubernetes Service (AKS), Azure Local, or air-gapped Kubernetes distributions.

  • Abstract PaaS service interfaces: When using Azure PaaS services in connected environments, implement adapters that can be replaced with alternative implementations. For example: 

    Application Code → MessageBusInterface → Azure Service Bus (connected)
                                      → NATS/RabbitMQ (disconnected)

  • Environment-agnostic configuration: Use Helm charts, Kustomize, or similar tools to manage environment-specific configuration. Never hardcode cloud endpoints, DNS names, or infrastructure details in application code.

  • Standard protocols over proprietary APIs: Prefer open standards (PostgreSQL wire protocol, S3-compatible object storage APIs, MQTT for IoT) over cloud-specific APIs.

Portability in Practice

A financial services application designed for portability might use PostgreSQL (running in Azure Database for PostgreSQL in the cloud, or self-hosted on Azure Local) rather than Azure Cosmos DB, specifically because PostgreSQL can run anywhere without API changes.

Assume Disconnection

Principle: Even connected workloads should be designed to survive connectivity loss.

Connectivity is never guaranteed. ExpressRoute circuits fail, VPNs drop, and networks partition. Applications designed with disconnection tolerance are inherently more resilient.

Implementation strategies:

  • Circuit breakers for cloud dependencies: Use the Circuit Breaker pattern to detect cloud service failures and automatically fail over to local behavior. Libraries like Polly (.NET) or resilience4j (Java) implement this pattern.

  • Local caching with expiration: Cache critical data (configuration, reference data, authentication tokens) locally with appropriate TTLs. Applications should continue functioning with stale data when fresh data is unavailable.

  • Eventual consistency models: Design data synchronization to tolerate delays and network partitions. Use conflict resolution strategies (last-write-wins, vector clocks, CRDTs) appropriate to your business logic.

  • Queue-based load leveling: Buffer work in local queues during connectivity disruptions. When connectivity returns, drain queues to cloud services.

  • Static stability: Systems should not require connectivity to the cloud management plane to remain operational. Configuration changes should not be required to maintain steady-state operation.

Disconnection Tolerance in Retail

A retail point-of-sale system designed for disconnection tolerance continues processing transactions during internet outages, storing transactions locally and synchronizing with the cloud when connectivity returns. Payment processing uses store-and-forward queues.

Automate Everything

Principle: Manual processes don't scale across multiple environments and deployment models.

Operating workloads across the hybrid continuum requires consistency that only automation can provide. Manual operations lead to configuration drift, security vulnerabilities, and operational incidents.

Implementation strategies:

  • Infrastructure as Code (IaC) for all environments: Use Terraform, Bicep, or Pulumi to define infrastructure declaratively. Apply the same IaC practices to Azure Local deployments as you do to Azure resources.

  • GitOps for application deployment: Use ArgoCD, Flux, or similar tools to manage application deployments. Git becomes the source of truth for desired state across all Kubernetes environments.

  • Automated testing across connectivity models: Include disconnection tests in CI/CD pipelines:

  • Unit tests with mocked cloud services
  • Integration tests with network fault injection

  • Chaos engineering tests that simulate connectivity loss

  • Automated compliance scanning: Use tools like Azure Policy, Open Policy Agent (OPA), or Kyverno to enforce compliance policies across environments automatically.

  • Configuration validation gates: Validate configuration changes before deployment. Test Helm charts, validate Kubernetes manifests, and check for common misconfigurations.

Automation Requirement

In sovereign cloud scenarios where manual access may be restricted by regulation, automation is not optional—it's the only feasible operational model.

Secure by Default

Principle: Apply Zero Trust principles across the continuum with security as a first-class design concern.

Security cannot be added as an afterthought in hybrid architectures. The expanded attack surface—multiple networks, multiple identity providers, varying physical security controls—requires defense in depth.

Implementation strategies:

  • Encrypt everything: Data at rest (disk encryption, database TDE), data in transit (TLS 1.3, mTLS for service mesh), and data in use (confidential computing with AMD SEV-SNP or Intel TDX where applicable).

  • Identity-centric security: Use Entra ID for connected environments, with identity federation to on-premises Active Directory. For air-gapped environments, implement local identity providers with equivalent security controls (MFA, conditional access policies).

  • Network segmentation and micro-segmentation: Use network policies in Kubernetes to enforce pod-to-pod communication rules. Implement separate VLANs for management traffic, storage traffic, and application traffic on Azure Local.

  • Least-privilege access everywhere: Apply RBAC consistently across Azure subscriptions, Kubernetes clusters, and administrative access. Use Azure Managed Identities or Kubernetes service accounts rather than static credentials.

  • Supply chain security: Sign container images with Cosign or Notary. Scan images with Trivy or similar tools. Maintain Software Bills of Materials (SBOM) for audit requirements.

Zero Trust Across the Continuum

Zero Trust principles—verify explicitly, use least-privilege access, assume breach—apply equally whether workloads run in public cloud or air-gapped data centers. The implementation tools change, but the principles remain constant.

🔗 Working Example: Contoso Insurance Sample Application

See these design principles in action at ContosoInsurances-NativeToLocal — demonstrating portable containers across three deployment models, Bicep IaC for all environments, zero-trust networking (NSGs, private endpoints, Calico network policies), and OpenTelemetry-based distributed tracing.

Observe Everything

Principle: Comprehensive observability is essential for operating hybrid workloads effectively.

You cannot manage what you cannot measure. Observability—the combination of metrics, logs, traces, and profiles—is critical for understanding system behavior, diagnosing issues, and ensuring reliability across diverse environments.

Implementation strategies:

  • Structured logging with consistent formats: Use JSON-formatted logs with consistent field names across all services. Include correlation IDs for distributed tracing.

  • OpenTelemetry for instrumentation: Use OpenTelemetry SDKs to instrument applications consistently. OpenTelemetry collectors can send telemetry to Azure Monitor in connected environments or Prometheus/Loki in disconnected environments without code changes.

  • Multi-environment monitoring strategies:

  • Connected: Azure Monitor, Application Insights, Log Analytics
  • Hybrid: Local Prometheus/Grafana federating metrics to Azure Monitor

  • Disconnected: Fully local observability stack (Prometheus, Grafana, Loki, Tempo)

  • Service Level Indicators (SLIs) and Service Level Objectives (SLOs): Define SLIs (request latency, error rate, throughput) and SLOs (99.9% of requests < 200ms) that are measurable in all environments.

  • Alerting that works offline: For critical alerts in disconnected environments, implement local notification systems (email via local SMTP relay, SMS via hardware modem, or integration with on-premises notification systems).

Unified Observability

Tools like Grafana can provide a unified view across environments by querying multiple Prometheus datasources (one per environment) simultaneously. Operators see a consistent interface regardless of where workloads run.

graph TB
    Center["⭐ Hybrid Design<br/>Excellence"]

    Portability["🔄 Design for Portability<br/>• Standard APIs<br/>• Abstraction layers<br/>• Container-first"]

    Disconnection["🔌 Assume Disconnection<br/>• Local caching<br/>• Static stability<br/>• Eventual consistency"]

    Automation["⚙️ Automate Everything<br/>• IaC (Terraform/Bicep)<br/>• GitOps (Flux/ArgoCD)<br/>• Self-healing systems"]

    Security["🔐 Secure by Default<br/>• Zero Trust<br/>• Defense-in-depth<br/>• Supply chain security"]

    Observability["👁️ Observe Everything<br/>• OpenTelemetry<br/>• Multi-env monitoring<br/>• Structured logging"]

    Center --- Portability
    Center --- Disconnection
    Center --- Automation
    Center --- Security
    Center --- Observability

    Portability <-.->|Enables| Automation
    Portability <-.->|Simplifies| Observability

    Disconnection <-.->|Requires| Automation
    Disconnection <-.->|Demands| Observability

    Automation <-.->|Enforces| Security
    Automation <-.->|Enables| Observability

    Security <-.->|Protects| Portability
    Security <-.->|Validated by| Observability

    Observability <-.->|Informs| Automation
    Observability <-.->|Monitors| Security

    style Center fill:#0078d4,stroke:#005a9e,stroke-width:4px,color:#fff,font-size:16px
    style Portability fill:#50e6ff,stroke:#0078d4,stroke-width:3px
    style Disconnection fill:#50e6ff,stroke:#0078d4,stroke-width:3px
    style Automation fill:#50e6ff,stroke:#0078d4,stroke-width:3px
    style Security fill:#50e6ff,stroke:#0078d4,stroke-width:3px
    style Observability fill:#50e6ff,stroke:#0078d4,stroke-width:3px

Mapping to Well-Architected Framework Pillars

These hybrid-specific principles align with and extend the five pillars of the Azure Well-Architected Framework:

WAF Pillar Hybrid Principle Key Adaptation
Reliability Assume Disconnection Resilience extends to network partitions and connectivity loss, not just component failures
Security Secure by Default Zero Trust applies across varying connectivity models; supply chain security is critical for air-gapped
Cost Optimization Design for Portability Portability enables workload placement optimization based on cost models
Operational Excellence Automate Everything, Observe Everything Automation and observability scale across multiple environments with varying management capabilities
Performance Efficiency Design for Portability Abstractions must not sacrifice performance; local caching improves performance under disconnection

Design Principle Trade-offs

Every design principle involves trade-offs:

Portability vs. Feature Richness: Abstracting cloud services to enable portability means forgoing some cloud-native features. A portable message queue implementation might not support all Azure Service Bus features.

Disconnection Tolerance vs. Complexity: Circuit breakers, local caching, and queue-based load leveling add complexity to application architecture. Teams must balance resilience against development and operational complexity.

Automation vs. Initial Effort: Building comprehensive automation requires significant upfront investment. Teams must evaluate the break-even point based on the number of environments and frequency of deployments.

Security vs. Performance: Encryption, mTLS, and identity verification add latency and computational overhead. Security controls must be proportionate to risk.

Observability vs. Cost: Comprehensive telemetry generates significant data volumes. Storage and processing costs must be managed through sampling, retention policies, and selective instrumentation.

Applying Principles Across the Continuum

The application of these principles varies by deployment model:

Public Cloud (Azure): - Portability: Containers, abstracted service interfaces - Disconnection: Circuit breakers for cross-region dependencies - Automation: Azure DevOps, GitHub Actions, Infrastructure as Code - Security: Azure Entra ID, Defender for Cloud, Key Vault - Observability: Azure Monitor, Application Insights

Connected Azure Local: - Portability: Kubernetes on Azure Local with Arc connectivity - Disconnection: Local data caching, queue buffering for cloud sync - Automation: GitOps with Arc-enabled Kubernetes, Azure Policy - Security: Hybrid identity with Entra ID, Defender for Cloud - Observability: Hybrid monitoring (local Prometheus + Azure Monitor)

Disconnected/Sovereign: - Portability: Standard Kubernetes distributions, open-source services - Disconnection: Full local autonomy, synchronization only during connection windows - Automation: GitOps on private Git repositories, local CI/CD - Security: Local identity provider, local vulnerability scanning - Observability: Fully local observability stack (Prometheus, Grafana, Loki)

Principles in Action

A telecommunications company building 5G edge applications applies all five principles: containerized workloads run on Azure Local at cell towers (portability), continue operating during backhaul outages (disconnection tolerance), deploy via GitOps (automation), use mTLS between all services (security), and send telemetry to both local Grafana and Azure Monitor when connected (observability).

Conclusion

These five design principles—portability, disconnection tolerance, automation, security by default, and comprehensive observability—form the foundation for successful hybrid architectures. They guide decisions at every level: technology selection, application design, operational processes, and organizational structure.

While applying all principles simultaneously can be challenging, each principle independently improves system quality. Teams should prioritize principles based on their specific requirements: regulatory environments prioritize security and disconnection tolerance, while multi-tenant SaaS providers prioritize portability and automation.

The principles are not prescriptive recipes but guiding lights. The specific implementation will vary based on technology choices, team capabilities, and business constraints. What remains constant is the need to think holistically about how applications behave across the full spectrum of the hybrid continuum.

Next: Resilience →