TL;DR
Hybrid platform dependency mapping should explain what a business service needs to run, restart, change, and recover. An inventory tells you which resources exist. A useful service map identifies which dependencies are mandatory, when their failure becomes visible, who owns them, and which recovery actions remain possible. Start with one critical transaction, separate runtime dependencies from management and recovery dependencies, and attach evidence to the relationships. Validate the map through controlled failure exercises, then keep an accessible recovery copy outside the failure domain it describes.
On this page
- Start with the Service, Not the Infrastructure Inventory
- Scope, Assumptions, and Mapping Criteria
- A Hybrid Failure That the VM Inventory Will Not Explain
- Maintain Four Views of the Same Service
- Record Dependency Behavior on the Relationship
- Build the Map from Evidence, Not One Discovery Tool
- Break Recovery Loops Before They Become Incident Blockers
- Turn the Service Map into Recovery Gates
- Validate the Map and Keep It Usable
- Conclusion
- External References
Introduction
A hybrid incident can leave every infrastructure team looking at a different version of the truth. The virtualization team sees powered-on virtual machines. The network team sees established connectivity. The cloud team sees available Azure resources. The application team still cannot complete a transaction.
Those observations are not necessarily contradictory. They answer component questions, not the service question: What must work together for this business outcome to succeed?
Hybrid platform dependency mapping connects those views. It should show more than a line between an application server and a database. It should expose the identity path used to obtain credentials, the DNS path used to resolve a private endpoint, the controls that permit the connection, and the administrative path needed when something fails.
The objective is not to create the largest diagram in the architecture repository. It is to give operators enough verified context to decide what is affected, what should be restored first, and which action might make the incident worse.
Start with the Service, Not the Infrastructure Inventory
An inventory remains necessary. It identifies machines, clusters, networks, subscriptions, storage, and ownership. A configuration management database can also hold relationships. Neither becomes an incident-ready service map merely because the objects are connected visually.
The distinction is the question each artifact can answer.
| Artifact | Primary question | What still needs to be established |
|---|---|---|
| Infrastructure inventory | What exists and where does it run? | Which business outcome depends on it? |
| Observed connection map | Which endpoints communicated during collection? | Was the connection necessary, optional, or incidental? |
| Application dependency map | Which components support a transaction? | What changes during startup, failure, or recovery? |
| Operational service map | What must work, under which conditions, and who can restore it? | Whether the recorded behavior remains valid after change |
Microsoft’s Azure Well-Architected guidance on failure mode analysis starts with critical flows, then identifies their components, dependencies, failure effects, and mitigations. That is a useful foundation for hybrid mapping: begin with the outcome and follow its requirements across platform boundaries.
For order entry, the outcome might be a committed order that an authorized user can retrieve. A web page loading is not equivalent. For a batch service, the outcome might be a completed settlement file delivered before its business deadline, not simply a scheduler reporting that a process started.
Define that boundary before collecting more infrastructure data.
Scope, Assumptions, and Mapping Criteria
This article uses an illustrative service spanning VMware Cloud Foundation infrastructure and Azure shared services. It assumes separate application, private cloud, cloud platform, network, identity, and backup ownership. The method applies to other combinations, but the product-specific recovery procedures must match the deployed environment.
The example is a design scenario, not a report of a tested customer incident. Any survival window, fallback behavior, or recovery order must be verified locally.
Use three inclusion criteria. Map a dependency when its failure can prevent the business outcome, prevent an essential administrative action, or prevent recovery. Expand a grouped dependency when different members have different owners, failure domains, or recovery behavior.
That keeps the map useful without drawing every switch port and background connection. A logical database service can remain one node in the business view, while a linked technical view records its replicas, quorum requirements, storage, and failover mechanism.
A failure domain also needs more precision than a location label. Record physical placement, shared network paths, identity providers, administrative scopes, and common configuration deployment paths. Two instances are not independent of a change that updates both simultaneously.
A Hybrid Failure That the VM Inventory Will Not Explain
Consider an order-entry application running on VCF infrastructure. Its SQL Server database is local. The application retrieves a database credential from Azure Key Vault through private connectivity and the enterprise DNS forwarding design.
In this example, the application keeps the credential in memory after startup. Existing database sessions can continue while that credential and their other prerequisites remain valid. A new application process, however, must retrieve the credential before opening its first database connection.
Now introduce a DNS forwarding error affecting the Key Vault resolution path. Existing instances may continue processing orders. A restarted instance cannot retrieve its startup secret. Restarting every application server as a troubleshooting step could therefore convert a limited impairment into a service outage.
The excerpt below separates the transaction path from that startup and refresh path. It is a logical dependency view, not a packet-level topology.
Microsoft’s private endpoint DNS guidance documents the on-premises forwarding and Azure resolver relationships behind this kind of design. A private endpoint appearing in inventory does not establish that the application uses a functioning resolution path to reach it.
The operational lesson is not that caching makes Key Vault optional. It is that dependency criticality changes with the operation and the state of the consumer. Record startup, credential refresh, and existing-session behavior separately. Do not invent an outage tolerance from a cache setting alone.
Maintain Four Views of the Same Service
Trying to show every relationship in one drawing usually hides the distinctions that matter during an incident. Maintain one underlying set of records, but generate views for different operational questions.
Runtime Dependencies
The runtime view describes what the service needs to perform its business function. Include application calls, database access, storage, traffic enforcement, name resolution, and authentication where the specific transaction requires them.
Describe the operation, not just the provider. A dependency may be mandatory for submitting an order but unnecessary for reading an already generated report. A delayed notification might be tolerable even when a delayed database commit is not.
Specify the permitted degraded outcome. “The application still works” is too broad. “Existing orders remain readable, but new submissions are rejected without losing data” is an operationally meaningful statement.
Startup and Refresh Dependencies
The startup view records what a new process or replacement instance needs before it becomes useful: configuration, secrets, images, packages, service registration, database initialization, and initial trust establishment.
Refresh dependencies deserve their own conditions. Credential renewal, configuration reloads, DNS re-resolution, or certificate-related operations may expose an unavailable provider after the application has already been running.
Record the trigger and observed behavior. A configured cache lifetime is not proof of a guaranteed survival period. Cache age, restart timing, revocation, client behavior, and connection state can change the result.
Management and Change Dependencies
The management view covers the ability to provision, reconfigure, inspect, patch, or scale the service. Do not label every management component as a synchronous runtime requirement simply because it manages the workload.
Microsoft distinguishes Azure Resource Manager control-plane operations from resource-specific data-plane operations. A control-plane interruption does not automatically mean the resource’s data plane is unavailable. Conversely, continued data access does not prove that an operator can deploy a replacement or change a route.
Apply that operation-specific approach to VMware management paths. Record which actions require vCenter, which supported local actions remain possible, and what credentials and network access each path requires. Avoid a blanket label such as “VCF down.”
Where Azure Arc-enabled VMware vSphere is deployed on a supported configuration, add its resource bridge and vCenter integration to the management view. Microsoft’s architecture documentation distinguishes that infrastructure-management path from guest-level Arc management. They should not be collapsed into one generic “Azure agent” dependency.
Recovery Dependencies
The recovery view starts with the operator and follows the prerequisites for restoration. It includes privileged access, administrative workstations, backup catalogs, repositories, decryption material, recovery infrastructure, deployment artifacts, and the runbook itself.
Ask a different question from the runtime review: can the team restore the component when the environment that normally supports the recovery tools is unavailable?
The Amazon Builders’ Library describes static stability as designing systems to continue operating without immediately requiring changes from an impaired dependency. For hybrid planning, the corresponding question is whether recovery requires already available capacity or depends on provisioning new capacity through a control plane affected by the same incident.
Record Dependency Behavior on the Relationship
A node can have an owner, location, and health signal. The relationship must explain why another component depends on it.
Use a consistent direction: consumer points to provider. A reverse lookup can then identify potential consumers affected by a provider failure. That result is a candidate impact set, not proof that every consumer is down.
For important relationships, retain the operation, operating mode, failure effect, protocol or interface, alternate provider, evidence source, verification date, and escalation owner. Record latency and capacity requirements when an alternate path must carry production load.
Preserve Required, Alternative, and Conditional Relationships
A flat list of dependencies cannot express redundancy accurately. Distinguish requirements that must all be satisfied from alternatives where one healthy provider is sufficient. Preserve quorum rules for clustered systems rather than treating every member as individually mandatory.
Then examine whether the alternatives share a prerequisite. Two DNS servers can both depend on one forwarding target. Two network paths can share an inspection tier. A replica at another site can still depend on the same administrative identity or deployment configuration.
This is where the map becomes a decision tool. It should explain whether losing a component causes immediate failure, reduced capacity, delayed failure, or loss of a particular recovery option.
A Practical Dependency Record
The following YAML is a proposed internal record format, not a vendor configuration or a deployable policy. It captures the secret-retrieval relationship from the example. Replace the identifiers, owners, and evidence references with your own records; keep unverified values explicitly unknown.
schema_version: 1 service_id: order-entry-prod edge_id: order-api-to-key-vault consumer: order-api-prod provider: order-secrets-vault operation: retrieve-database-credential requirements: startup: required steady_state: conditional credential_refresh: required recovery_restart: required conditions: steady_state_trigger: cache-miss-or-required-refresh failure_effect: cannot-initialize-new-database-session tested_survival_window_seconds: null prerequisite_refs: - order-api-to-corporate-dns - corporate-dns-to-azure-resolver - order-api-to-key-vault-network-path - order-api-to-workload-authentication owners: consumer: business-applications provider: cloud-platform incident_escalation: order-entry-on-call evidence: status: proposed configuration_revision: null observation_window: null last_verified_utc: null test_record: null recovery: runbook_id: RB-ORDER-STARTUP restart_gate: secret-retrieval-validated
The prerequisite references must resolve to separate records. The workload authentication record, for example, should describe how the application obtains authority to read the secret without introducing another undisclosed bootstrap dependency.
Successful adoption means the record identifies a real relationship, its prerequisite references resolve, both owners agree on the behavior, and evidence supports any verified status. Valid YAML alone proves none of those things.
Keep secret values, private keys, and recovery codes out of the map. Store controlled references to their recovery procedures instead.
Build the Map from Evidence, Not One Discovery Tool
Automated discovery is a starting point, not an authority on business meaning. Combine observed behavior, deployed configuration, operational procedures, and owner review.
Collect a Representative Operating Window
Observe the service during ordinary traffic, scheduled processing, maintenance, and relevant business-cycle events. Do not assume a quiet collection period captures month-end jobs, credential rotation, or recovery operations.
Microsoft documents Azure Migrate agentless dependency analysis as collecting TCP connection information. That is useful for identifying candidate server relationships. It is not a complete protocol inventory, a real-time incident monitor, or proof that a connection is essential to the service.
The practical consequence is important: a TCP-derived map cannot establish every DNS, time-service, or other non-TCP dependency. Polling also needs to be considered when interpreting brief connections. An unobserved relationship should remain unobserved, not be silently reclassified as unnecessary.
Agentless also does not mean access-free. Review the collector’s current platform and guest-access prerequisites, obtain the required approvals, and scope its credentials appropriately. Do not grant broad estate-wide privileges merely to make a diagram populate.
Reconcile Observed and Declared Dependencies
Review application configuration, infrastructure as code, DNS forwarding, route and firewall configuration, workload identities, scheduled tasks, and backup procedures alongside the observed map.
Use disagreements as review items. A configured dependency with no observed traffic might belong to a recovery-only path. An observed destination missing from configuration might be an intermediary, inherited setting, or an integration the application owner has not documented.
Preserve stable service identifiers and the identities of the underlying resources. An IP address alone is not durable identity, and a load balancer, proxy, or translated address can hide the provider the consumer actually relies on.
Separate Observation from Validation
Use evidence states such as proposed, observed, configuration-confirmed, and failure-tested. Keep the collection window, configuration revision, and test scope with the evidence.
A relationship tested before an authentication change should not retain an unqualified verified label afterward. Discovery confidence and recovery confidence answer different questions and should remain distinguishable.
Break Recovery Loops Before They Become Incident Blockers
A recovery dependency can be more consequential than the component that originally failed.
Consider a directory and DNS service that must be restored from backup, while the normal backup-console login depends on that same directory and DNS service. The blocked sequence is straightforward:
The solution is not an undocumented bypass. It is an approved, supported recovery entry point with an authentication method, access route, credential custody process, and validation procedure that survive the stated failure.
Microsoft’s emergency-access guidance recommends keeping cloud and on-premises emergency access independent of each other. Cloud-only emergency accounts can remove a dependency on an on-premises federation service. They do not remove the requirement for the cloud identity service itself to be reachable and functioning.
Apply that distinction to every claimed fallback. Record exactly which dependency it avoids and which dependencies remain. A second console using the same identity provider and network path may offer another interface without offering an independent recovery path.
The same review should cover encrypted backups. Repository availability is not enough when the decryption material, catalog, or required authorization cannot be recovered.
Turn the Service Map into Recovery Gates
A dependency graph helps establish prerequisites, but it does not produce a universally correct startup order. Recovery depends on the failure scenario, surviving state, data integrity, and the operations required to restore service.
For the illustrative DNS and secret-retrieval failure, use gates rather than a blanket instruction to restart the application stack.
| Recovery gate | Evidence required | Decision it supports |
|---|---|---|
| Confirm the affected service path | Transaction results, errors, timestamps, and dependency evidence | Distinguish local SQL failure from startup-secret failure |
| Validate the intended DNS path | Correct resolution from the affected execution environment | Determine whether the configured private endpoint can be located |
| Validate secret retrieval | Authorized retrieval using the intended workload identity | Establish whether a new process can initialize |
| Start one controlled instance | Startup, database connection, and a safe transaction test succeed | Decide whether further restarts are justified |
| Restore normal capacity | Service outcomes and dependency load remain within agreed limits | Expand recovery without overwhelming supporting services |
A successful lookup from an administrator’s laptop is not the same test as a lookup from the application network. A successful secret read with an administrator identity is not proof that the workload identity is authorized.
Google’s SRE guidance on cascading failures also highlights slow startup and cold-cache behavior. Recovery testing should therefore examine the load created by restarting instances, not only whether one instance can start successfully.
Define service recovery time against the complete sequence. Do not add every component’s restore time indiscriminately: independent tasks may run in parallel, while authentication, storage, and application prerequisites may impose a serial critical path. Include access, validation, and business acceptance in the exercise, rather than stopping the clock when the last VM powers on.
Validate the Map and Keep It Usable
Choose controlled tests that challenge the map’s important assumptions. Test loss of a selected dependency, loss of a supposed alternate, and a cold start while a normally cached dependency is unavailable. Include slow responses and access denials where they represent realistic failure modes, not only complete outages.
Microsoft’s reliability-testing guidance recommends explicit hypotheses, contained impact, stop conditions, and feedback into failure mode analysis. Begin in representative nonproduction or isolated recovery environments. Production exercises require an approved scope, safeguards, and an executable recovery procedure.
For each exercise, retain the expected impact, actual impact, affected operations, recovery actions, timings, and unexplained behavior. Do not label a test successful merely because the application eventually returned. Establish whether it recovered within the agreed service objective and preserved the required data and security properties.
Treat the map as a controlled operational artifact. The service owner is accountable for the complete view, while platform owners verify their relationships and evidence. Update it when endpoints, authentication, network paths, recovery procedures, or ownership change.
Automate checks for missing owners, unresolved references, stale verification, and changes to critical relationships. Do not automatically delete an edge just because recent telemetry no longer shows it.
Finally, test access to the map itself. Maintain a protected recovery copy that remains available without the primary identity, network, or document platform under examination. Include its revision and export time. Protect the topology as sensitive operational information, but make sure authorized responders can actually retrieve it during the failure it is meant to explain.
Conclusion
Hybrid platform dependency mapping is useful when it changes an operational decision. It should help a team avoid restarting a service that cannot bootstrap, identify a shared dependency behind apparently independent platforms, or establish a recovery path that does not rely on the failed system.
Start with one critical business outcome. Map its runtime, startup, management, and recovery requirements. Attach owners and evidence to the relationships, preserve conditional behavior and alternatives, and validate the assumptions through a controlled exercise.
The deliverable is not simply a diagram of connected infrastructure. It is a service map that lets the next incident team explain what still works, what cannot safely change, and what must be proven before recovery proceeds.
External References
- Microsoft Learn: Architecture strategies for performing failure mode analysis
- Microsoft Learn: Azure control plane and data plane
- Microsoft Learn: Azure Private Endpoint DNS integration Scenarios
- Microsoft Learn: What is Azure Arc-enabled VMware vSphere?
- Microsoft Learn: Dependency analysis
- Microsoft Learn: Analyze server dependencies (agentless)
- Microsoft Learn: Manage emergency access accounts in Microsoft Entra ID
- Microsoft Learn: Architecture strategies for designing a reliability testing strategy
- Amazon Builders’ Library: Static stability using Availability Zones
- Google SRE: Addressing Cascading Failures