TL;DR
The underwater cloud city in the image is a useful architecture metaphor, but it should not be read as a literal bill of materials. Azure Local and VMware Cloud Foundation are separate infrastructure platforms with their own control planes, lifecycle models, security boundaries, and automation surfaces.
A resilient hybrid cloud does not force those platforms into one management product. It connects them through a shared enterprise operating model that defines identity, policy, workload placement, network connectivity, observability, security operations, data protection, service delivery, and recovery. The goal is not one pane of glass. The goal is one set of operating rules with clear platform-native execution.
Introduction
The image presents hybrid cloud as an underwater city built to survive enormous pressure. Azure Local forms one section of the habitat. VMware Cloud Foundation domains form another. Above them sit multi-tenant isolation, AI and machine learning workloads, and global connectivity. Below them are the systems that keep the environment alive: control, data services, security operations, power, and cooling.
That visual works because hybrid cloud architecture is rarely tested by the steady state. It is tested by pressure.
Pressure arrives as a failed identity provider, an expired certificate, a disconnected site, a bad lifecycle update, a compromised tenant, a saturated east-west link, a ransomware event, a GPU capacity shortage, or an application owner demanding the same service experience on two very different platforms.
The architectural question is therefore not whether Azure Local and VMware Cloud Foundation can be drawn inside the same picture. The question is whether the enterprise can operate both platforms through a coherent model without erasing the differences that make each platform useful.
The most important correction to the image is also the most useful design lesson: Azure Local is not a generic hardware substrate underneath VMware Cloud Foundation, and VCF domains do not normally run inside an Azure Local cluster.
The architecture should instead be interpreted as two adjacent platform zones inside the same enterprise cloud ecosystem.
Azure Local provides Microsoft-aligned distributed infrastructure, local compute and storage, Azure Arc integration, and Azure-consistent governance and management patterns. VMware Cloud Foundation provides a VMware private cloud model built around vSphere, vSAN, NSX, VCF Operations, VCF Automation, and VCF domain constructs.
They can share enterprise services, physical facilities, network underlay, security operations, data protection standards, and service-management processes. They should not be collapsed into a fictional single control plane.
That distinction protects the design from one of the most common multicloud mistakes: drawing integration where only coexistence exists.
Scope and Architecture Assumptions
This article uses the following assumptions:
- Azure Local refers primarily to hyperconverged deployments managed through Azure and Azure Arc.
- VMware Cloud Foundation refers to the VCF 9.1 architecture family and its fleet, instance, domain, operations, automation, networking, and storage constructs.
- The platforms coexist in the same enterprise operating model but remain separate lifecycle and failure domains.
- Shared services may include enterprise identity, DNS, IP address management, certificate services, SIEM, IT service management, backup, disaster recovery orchestration, configuration repositories, and automation pipelines.
- Global connectivity means routed, policy-controlled connectivity between sites and services. It does not imply that every workload should share a stretched Layer 2 network.
- Multi-tenancy is treated as a layered design problem involving identity, authorization, resource allocation, network policy, data separation, cost accountability, and operational evidence.
This is an operating-model architecture, not a low-level deployment reference design. Every production implementation still requires current compatibility, licensing, hardware, support, and lifecycle validation.
Pressure Reveals Whether the Architecture Is Real
A platform can look unified during normal operations because dashboards are green and network paths are available. The real architecture becomes visible when one dependency fails.
A resilient design should be able to answer questions such as:
- Can Azure Local workloads continue operating when cloud connectivity is impaired?
- Can VCF domains be patched or upgraded without coupling the Azure Local lifecycle to the same change window?
- Can the security operations team correlate alerts from both platforms without losing the native diagnostic context?
- Can a tenant administrator act only inside the intended resource, network, and data boundaries?
- Can an AI workload be moved or rebuilt without creating an uncontrolled data-export path?
- Can the enterprise recover critical services if the shared automation layer is unavailable?
- Can application owners understand which platform is responsible for an incident?
If those answers depend on a single dashboard or a single automation account, the environment is not unified. It is tightly coupled.
The pressure-resistant model is federated. It establishes common policy and evidence requirements while allowing each platform to execute through its native mechanisms.
One Enterprise Cloud, Two Native Control Planes
The shared operating model should sit above the platform control planes, not replace them.
The top block is the enterprise contract. It defines what a compliant service must provide. The two middle paths translate that contract into platform-native controls. The lower shared services support both platforms without pretending to own their internal state.
This is the difference between governance and centralization.
Governance defines outcomes, boundaries, evidence, and accountability. Centralization tries to make every platform behave like the preferred platform. The first approach scales. The second creates brittle integrations and hidden exceptions.
Mapping the Underwater City to a Real Architecture
| Image element | Real architecture meaning | Design question |
|---|---|---|
| Surface vessels and global connectivity | Users, cloud services, partners, remote sites, WAN, and internet dependencies | What remains available when an external path fails? |
| Azure Local habitat | Microsoft-aligned local infrastructure and Azure Arc-managed workloads | Which workloads benefit from local execution with Azure-consistent governance? |
| VMware Cloud Foundation domains | VMware private cloud capacity, lifecycle boundaries, and application-ready infrastructure | Which workloads depend on vSphere, vSAN, NSX, VCF automation, or VMware operational skills? |
| Multi-tenant isolation | Identity, authorization, quotas, network policy, data boundaries, and delegated operations | What prevents one tenant from affecting another tenant’s resources or evidence? |
| AI and machine learning workloads | GPU capacity, model services, data pipelines, registries, inference, and MLOps | Where should data, models, accelerators, and governance controls live? |
| Control plane | Policy decisions, orchestration, lifecycle, inventory, desired state, and change control | Which system is authoritative for each action? |
| Data services | Backup, replication, recovery, databases, object services, and data lifecycle | Is data protected independently of the platform that hosts it? |
| Security operations | Detection, response, vulnerability management, audit, and evidence retention | Can the SOC investigate across platforms without flattening platform detail? |
| Power and cooling | Rack design, electrical capacity, thermal limits, hardware support, and facilities operations | Can the physical environment sustain peak infrastructure and GPU demand? |
| Ocean depth and pressure | Failure, latency, security, compliance, scale, and operational stress | Which dependencies fail first under pressure? |
The table exposes an important point: the shared architecture is not the collection of products. It is the collection of decisions that determine how those products are governed and operated.
Keep Platform-Native Responsibilities Inside Each Platform
A shared operating model does not mean shared ownership of every action. The cleanest model assigns authority at the layer where the best context exists.
Azure Local Native Responsibilities
Azure Local should remain authoritative for its cluster resources, platform lifecycle, Azure resource representation, Azure Arc-enabled workload management, and Microsoft-native governance integrations. Azure Policy, Azure Monitor, Microsoft Defender for Cloud, Azure role-based access control, Azure Resource Manager templates, Bicep, and Azure CLI can participate in that operating path where they are supported and appropriate.
The enterprise should consume the resulting inventory, compliance state, alerts, costs, and service health. It should not bypass the platform by changing low-level state through an unrelated tool simply because that tool offers a common dashboard.
VMware Cloud Foundation Native Responsibilities
VCF should remain authoritative for its fleet, instance, domain, vSphere, vSAN, NSX, VCF Operations, VCF Automation, and lifecycle workflows. A VCF domain is a meaningful infrastructure and lifecycle construct. It should not be reduced to a generic cluster label in an enterprise configuration database.
VCF Automation organizations, projects, namespaces, and associated tenancy designs can provide consumption boundaries, while VCF domains provide infrastructure organization and lifecycle boundaries. Those constructs are related, but they are not interchangeable.
The Enterprise Contract
The enterprise layer should define:
- required identity and privileged-access controls
- minimum logging and telemetry
- service-level objectives
- backup and recovery objectives
- network and data-classification policy
- encryption and certificate requirements
- vulnerability and patch evidence
- cost ownership and tagging
- change and exception workflows
- workload placement criteria
- incident escalation and communications
Each platform then proves compliance through its native implementation.
Do Not Flatten the Platform Models
A common taxonomy is useful, but a fake one-to-one mapping is dangerous.
| Architecture concern | Azure Local expression | VCF expression | Shared enterprise contract |
|---|---|---|---|
| Administrative scope | Tenant, subscription, resource group, role assignment, cluster, custom location | Private cloud, fleet, instance, domain, organization, project, namespace | Named owner, approved role, separation of duties, review cadence |
| Infrastructure lifecycle | Azure Local lifecycle and update workflows | VCF component and domain lifecycle workflows | Maintenance policy, readiness gate, rollback evidence, business approval |
| Resource governance | Azure Resource Manager, policy, quotas, tags, Arc resource model | VCF Automation policies, quotas, projects, blueprints, placement | Standard service classes, cost centers, limits, exception process |
| Network isolation | Physical network design, logical networks, platform and workload controls | NSX segments, gateways, distributed security, VPC and domain design | Addressing, routing, egress, segmentation, inspection, ownership |
| Observability | Azure Monitor, platform health, Defender integrations, logs and metrics | VCF Operations, platform logs, NSX telemetry, domain health | Common severity, retention, correlation, ticket routing, evidence |
| Workload automation | ARM, Bicep, Azure CLI, APIs, Arc-enabled workflows | VCF Automation, APIs, Terraform providers, PowerCLI and platform workflows | Git control, approval gates, secrets, artifact versioning, rollback |
| Recovery | Workload backup, replication, Azure-integrated recovery options, application recovery | VMware and partner backup, replication, recovery, application recovery | RPO, RTO, recovery owner, test frequency, recovery evidence |
The shared contract should normalize intent and evidence, not erase platform semantics.
Shared Services Need Contracts, Not Forced Consolidation
Identity and Privileged Access
The enterprise identity model should provide consistent user lifecycle, multifactor authentication, privileged-access control, break-glass procedures, and access reviews. Platform roles still need to be designed separately because equivalent role names do not guarantee equivalent permissions.
A global cloud administrator role is usually too broad. Delegation should be aligned to platform scope, service ownership, and incident responsibility. Service accounts and automation identities need the same rigor as human administrators, including credential rotation, least privilege, ownership, and termination procedures.
Policy and Governance
Policy should begin as an enterprise statement such as: production workloads must use approved images, encrypted storage, protected management paths, current vulnerability baselines, named owners, tested recovery, and retained audit evidence.
That policy is then translated into Azure and VCF implementations. Some controls can be prevented at deployment. Others can only be detected and remediated. The operating model must distinguish prevention, detection, response, and exception handling.
A policy dashboard without an exception owner is only a reporting system.
Observability and Security Operations
A central SIEM or observability platform can aggregate events from Azure Local, Azure services, VCF, NSX, guest operating systems, identity providers, and network devices. Aggregation is not the same as diagnosis.
The shared telemetry model should preserve:
- platform and resource identity
- tenant and service ownership
- event time and source
- severity and confidence
- change correlation
- network and identity context
- lifecycle status
- ticket and incident linkage
- evidence retention requirements
The SOC should be able to correlate events across platforms, then hand the investigation to an operator who still has native platform context.
Data Protection and Recovery
Data services in the image sit beneath both platforms because data outlives infrastructure. That is the correct mental model.
Backup policies, immutability, replication, retention, recovery orchestration, and restore testing should be governed independently from the platform that hosts the workload. A platform snapshot may support operational recovery, but it is not automatically a complete cyber-recovery strategy.
Recovery design should begin with the application dependency chain. Infrastructure recovery without identity, DNS, secrets, databases, queues, and external integrations can produce a technically running but functionally unusable application.
Network Connectivity
Global connectivity should use explicit routed boundaries, address-management discipline, DNS authority, egress control, and documented failure behavior. Stretching networks across platforms and sites can simplify a migration, but it can also extend failure domains and hide application dependencies.
The default goal should be application reachability, not universal Layer 2 adjacency.
Service Catalog and Automation
A shared service catalog can present a consistent request experience while dispatching work to different platform adapters. The request should contain intent: workload class, data classification, availability target, recovery target, network zone, owner, cost center, and approved software pattern.
The adapter should translate that intent into Azure Local or VCF resources. The catalog should not assume that both platforms expose identical objects or lifecycle behavior.
Multi-Tenant Isolation Is a Layered System
The image places multi-tenant isolation above the infrastructure because tenancy is an end-to-end property. It cannot be delivered by a VLAN, a resource group, a VCF domain, or a project alone.
A credible tenant boundary includes at least four layers:
- Administrative isolation: distinct identities, delegated roles, approval boundaries, and privileged-access controls.
- Resource isolation: quotas, placement, capacity reservations, noisy-neighbor protections, and lifecycle scope.
- Network and data isolation: segmentation, routing, egress, encryption, secrets, storage access, and backup boundaries.
- Operational isolation: separate alerts, costs, logs, tickets, evidence, change calendars, and incident ownership.
The provisioning path should enforce those layers before resources are created.
The request is not complete when the virtual machine or cluster exists. It is complete when ownership, policy, telemetry, protection, cost, and recovery evidence also exist.
AI and Machine Learning Workloads Increase the Pressure
The AI and machine learning label in the image is not just another workload category. Accelerated workloads can amplify every weakness in the operating model.
GPU resources are scarce and expensive. Model artifacts may have licensing and provenance requirements. Training and inference pipelines move sensitive data. Vector stores and model endpoints create new access paths. High-throughput traffic can expose network bottlenecks. Teams often request broad permissions because experimentation moves faster than governance.
Both Azure Local and the VCF ecosystem can support accelerated workload patterns, but the placement decision should not begin with GPU availability alone.
The enterprise should evaluate:
- where the source data is created and governed
- whether data may leave the site or security zone
- latency and availability requirements
- GPU type, memory, partitioning, and scheduling needs
- VM, Kubernetes, or platform-service preference
- model registry and artifact provenance
- secrets, service identities, and network egress
- monitoring, prompt and inference logging, and retention
- recovery expectations for data, pipelines, and model services
- skills and support ownership
- cost allocation and capacity reservation
AI infrastructure is not resilient when the accelerator is available but the data path, identity path, or model supply chain is uncontrolled.
Workload Placement Should Be a Decision, Not a Habit
The right platform is the one that best satisfies the workload’s requirements under the enterprise operating model.
| Decision criterion | Questions to ask |
|---|---|
| Application dependency | Does the workload rely on VMware-specific operations, Microsoft-native services, Kubernetes patterns, licensing, or existing automation? |
| Data gravity and sovereignty | Where is the data created, who owns it, and which locations or services may process it? |
| Latency and connectivity | Can the workload tolerate cloud-control-plane latency, site isolation, or WAN failure? |
| Isolation requirement | Does the workload need dedicated infrastructure, a shared tenant model, specialized network policy, or strict administrative separation? |
| Lifecycle fit | Which platform can patch, upgrade, and support the workload without unacceptable coupling? |
| Automation fit | Which native API, template, pipeline, and skills model can deliver the service reliably? |
| Resilience and recovery | Which platform and recovery design can meet the application RPO and RTO? |
| Observability and security | Can the platform produce the telemetry and control evidence required by operations and risk teams? |
| Cost and capacity | How are licensing, hardware, GPU capacity, storage growth, support, and operational labor allocated? |
| Reversibility | Can the workload be rebuilt, exported, migrated, or retired without creating a permanent dependency trap? |
A placement decision should be recorded with assumptions and review triggers. The answer can change when the application, platform release, connectivity model, cost profile, or regulatory requirement changes.
Build the Shared Operating Model in Deliberate Phases
Establish Authority Before Integration
Identify the authoritative system for identity, inventory, network addressing, DNS, certificates, secrets, vulnerability state, backup policy, cost ownership, service requests, and incident records.
Two tools can display the same data. Only one should own the decision.
Normalize Service Intent and Evidence
Define common service classes and evidence requirements before creating a universal portal. A production service might require a named owner, support tier, data classification, network zone, recovery tier, logging profile, patch window, and cost center.
The platforms can implement those requirements differently, but they should return evidence in a form the enterprise can evaluate.
Federate Identity, Telemetry, and Service Management
Connect platforms to enterprise identity, SIEM, observability, IT service management, and configuration repositories. Preserve native identifiers so incidents and changes can be traced back to the correct platform object.
Build Platform Adapters and Golden Paths
Create separate automation modules for Azure Local and VCF. Reuse enterprise policy, request schemas, naming conventions, metadata, tests, and approval logic. Do not reuse low-level platform actions merely to create visual consistency.
Test Failure and Recovery
Run exercises that remove dependencies:
- disconnect a site from external management services
- revoke or expire an automation credential
- simulate loss of a shared DNS or certificate dependency
- fail a network path
- restore a protected workload into an alternate recovery zone
- isolate a tenant after a suspected compromise
- pause a lifecycle operation and validate rollback
- recover the service catalog from source control and documented state
The design is complete only when the operating model survives the failure of its convenience layers.
A Practical Ownership Model
| Capability | Enterprise authority | Platform execution | Required evidence |
|---|---|---|---|
| Identity and privileged access | Identity and security teams | Azure and VCF role models | Access review, role assignment, break-glass test |
| Network and IP services | Network architecture | Azure Local networking and NSX | Address ownership, route state, policy, flow evidence |
| Platform lifecycle | Platform governance | Azure Local lifecycle and VCF lifecycle | Compatibility check, readiness gate, change record, rollback plan |
| Workload provisioning | Cloud platform team | Azure and VCF automation adapters | Request, approval, code version, deployment result |
| Security monitoring | SOC | Native platform telemetry and controls | Alert, owner, response record, retained logs |
| Data protection | Data protection team | Platform and backup integrations | Policy, immutable copy, restore test, recovery result |
| Cost and capacity | FinOps and platform owners | Native usage and capacity data | Allocation, forecast, exception, reclamation action |
| Incident response | Incident command | Platform specialists and service owners | Timeline, containment, recovery, post-incident actions |
This model creates shared accountability without pretending that every team should operate every platform.
Measure the Operating Model, Not the Diagram
The environment should be measured by outcomes that reveal whether the shared model works:
- percentage of services with a named owner and recovery tier
- percentage of privileged roles reviewed on schedule
- policy compliance before and after deployment
- mean time to identify the correct platform and service owner
- mean time to contain a tenant or workload
- successful restore and recovery-test rate
- lifecycle changes completed without cross-platform incident
- percentage of resources deployed through approved automation
- configuration drift age
- telemetry coverage and evidence retention
- capacity forecast accuracy
- orphaned resource and unused reservation rate
- AI workloads with approved data, model, identity, and egress controls
These measures expose whether the architecture is operationally coherent. A visually unified dashboard does not.
Conclusion
The underwater city is a strong metaphor for hybrid cloud because it makes pressure visible. The habitat survives only when every boundary, control path, life-support dependency, and recovery mechanism has been designed before the emergency.
Azure Local and VMware Cloud Foundation should not be treated as one merged product stack. They should be treated as distinct platform zones connected by a shared enterprise operating model. Each platform keeps authority over its native lifecycle, resources, networking, automation, and diagnostics. The enterprise defines the common contract for identity, policy, observability, security operations, data protection, connectivity, cost, service delivery, and recovery.
That approach produces something more valuable than one pane of glass. It produces one accountable way of operating across multiple control planes.
The architecture succeeds when a workload can be placed deliberately, governed consistently, operated by the right team, isolated under pressure, and recovered with evidence. That is the pressure hull beneath a resilient hybrid cloud.
