Oracle Cloud Application Dependency Management Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Application Development

1. Introduction

What this service is

Application Dependency Management in Oracle Cloud (OCI) is a service for discovering, mapping, and visualizing runtime dependencies between applications, services, and underlying infrastructure (hosts, processes, ports, and network connections). It helps teams understand “what talks to what” in real environments.

One-paragraph simple explanation

When you run an application in production, it rarely stands alone—it calls databases, queues, APIs, identity services, third‑party endpoints, and other microservices. Application Dependency Management helps you automatically discover those relationships and see them as a topology map, so you can troubleshoot faster, plan changes safely, and reduce outages caused by unknown dependencies.

One-paragraph technical explanation

At a technical level, Application Dependency Management collects telemetry (typically via OCI management agents on compute hosts) to identify running software components and infer dependency links based on observed connections and configuration. It then stores that discovered metadata as entities and relationships and provides a UI/API to query and visualize the application topology. This supports operational workflows like impact analysis, incident triage, migration planning, and security reviews.

What problem it solves

Modern systems fail in complex ways because dependencies are not documented, change frequently, and span multiple teams and environments. Application Dependency Management addresses: – Unknown/undocumented dependencies that break during maintenance or migration – Slow incident response when teams cannot quickly identify downstream impact – Risky releases when change impact is unclear – Fragmented application inventories (what is running where, and why)

Important naming note: “Application Dependency Management” can be confused with software package dependency managers (Maven/Gradle/npm/pip) or “artifact dependency” tools. OCI Application Dependency Management is about runtime/system dependencies and topology, not build-time libraries.

2. What is Application Dependency Management?

Official purpose

Application Dependency Management is designed to discover application components and their dependencies in your OCI and hybrid environments, and present them as an understandable topology for operations and engineering teams.

Because product scope can evolve, validate the most current description in the official OCI documentation: – Official docs (start here): https://docs.oracle.com/en-us/iaas/application-dependency-management/home.htm (Verify the exact URL path in current docs if it changes.)

Core capabilities (high-level)

Common, practical capabilities associated with Application Dependency Management include: – Discovery of application components running on hosts (processes/services) – Dependency mapping based on observed communications – Topology visualization (service maps / dependency graphs) – Inventory context (what runs where, relationships between tiers) – Change/impact support (understanding blast radius before changes)

If your tenancy shows additional capabilities (tags, export, integrations), treat those as OCI feature enhancements and confirm in the docs for your region and service version.

Major components (conceptual model)

While OCI implementation details can vary, most environments will include: – Application Dependency Management service (control plane in OCI) – Management Agent (installed on compute instances/hosts to collect discovery data) – Discovered entities (hosts, processes, endpoints, logical apps/services—exact entity types depend on OCI’s model) – Relationships (edges showing dependencies/communications) – Console UI and APIs to view topology and query discovered metadata

Service type

Managed OCI service (control plane managed by Oracle)
Uses agents on hosts for discovery/telemetry in many deployments (verify for your environment)

Scope (regional/global and tenancy boundaries)

OCI services are typically region-scoped while being governed by tenancy-wide IAM. For Application Dependency Management: – Expect compartment-scoped resources and policies (common OCI pattern). – Expect region selection for where you view/manage ADM data. – Verify exact regional behavior (single-region vs cross-region views) in official docs for your tenancy and service limits.

How it fits into the Oracle Cloud ecosystem

Application Dependency Management is commonly used alongside OCI observability and operations services (names and availability can vary by region and tenancy): – Logging / Logging Analytics (log search and analytics) – Monitoring / Alarms (metrics-based alerting) – APM / distributed tracing (request-level tracing; different from topology discovery) – Management Agent service (agent lifecycle and data collection) – Notifications (alert fan-out) – IAM / Compartments / Tagging (governance and access control)

Even though your CSV category is Application Development, in the OCI console this type of service is often positioned under Observability & Management. That’s not a contradiction: dependency visibility is extremely valuable to application developers, platform teams, DevOps, and SREs—especially for microservices and CI/CD-driven environments.

3. Why use Application Dependency Management?

Business reasons

Reduce downtime and incident duration: clearer dependency maps shorten triage time.
Lower change risk: maintenance and migrations become safer with blast-radius visibility.
Improve operational maturity: dependency visibility supports SLOs, postmortems, and continual improvement.
Faster onboarding: new team members can understand the system without tribal knowledge.

Technical reasons

Automatic discovery over manual diagrams: topology changes frequently; manual docs drift.
Supports complex architectures: microservices, service meshes, hybrid connectivity, shared middleware.
Better root-cause workflow: correlate an outage to upstream/downstream dependencies.

Operational reasons

Impact analysis: identify which apps will be impacted by a host reboot, network change, firewall rule, or DB maintenance.
Standardized application inventory: what’s running, where it runs, and who depends on it.
Change management: evidence for CAB/change approvals (what could be affected).

Security/compliance reasons

Network exposure review: discover unexpected outbound calls or lateral traffic paths.
Segmentation and least privilege: dependency maps help define security zones and firewall rules.
Audit readiness: more complete documentation of system interactions.

Scalability/performance reasons

Performance troubleshooting: identify overloaded shared dependencies and noisy-neighbor patterns.
Capacity planning inputs: dependency hot spots highlight shared services that need scaling.

When teams should choose it

Choose Application Dependency Management when you need: – A living topology of dependencies across apps/services/hosts – Improved incident response and change safety – A practical path to dependency discovery without building custom scripts

When they should not choose it

It may not be the best fit if: – You only need build-time dependency governance (use Maven/Gradle/npm/SCA tools instead). – Your environment prohibits host agents and there is no supported agentless discovery path (verify ADM’s supported discovery methods). – You already have an enterprise topology/CMDB tool that is authoritative and integrated (and you don’t want duplication), unless ADM can complement it.

4. Where is Application Dependency Management used?

Industries

Financial services: strict change controls, strong need for impact analysis
Healthcare: compliance-driven documentation, high availability
Retail/e-commerce: complex seasonal scaling, many integrations
SaaS providers: microservices and fast release cycles
Telecom and media: high traffic, distributed systems, hybrid setups
Government: inventory governance and operational visibility

Team types

Application developers and tech leads
Platform engineering and DevOps teams
SRE/operations teams
Security engineering (network segmentation, dependency exposure)
Enterprise architecture (system inventory and modernization planning)

Workloads

Microservices (REST/gRPC/event-driven)
Classic 3-tier apps (web/app/db)
Middleware-heavy stacks (application servers, messaging, caches)
Hybrid apps (on-prem + OCI connectivity)
Shared platform services (identity, logging, gateway, API management)

Architectures

Hub-and-spoke networks with shared services
Multi-tier VCN architectures (public/private subnets)
Kubernetes-based services (verify ADM’s Kubernetes support in docs if required)
VM-based application estates
Migration programs (data center → OCI)

Real-world deployment contexts

Discover dependencies before migrating a legacy app to OCI Compute or OCI Kubernetes.
Map service-to-service calls after decomposing a monolith.
Identify unexpected dependencies that cause “it worked in test” failures.

Production vs dev/test usage

Production: highest value (real dependencies), but requires strict IAM, data governance, and agent lifecycle management.
Dev/test: useful for validating reference architectures and reducing surprises before go-live, but may not reflect all dependencies if traffic is limited.

5. Top Use Cases and Scenarios

Below are realistic, field-tested ways teams use Application Dependency Management.

1) Pre-migration dependency discovery

Problem: You want to migrate an app to OCI, but don’t know all upstream/downstream connections.
Why this service fits: Automated discovery builds a dependency view from real runtime signals.
Example scenario: A Java app on VMs appears to only use Oracle DB, but ADM reveals calls to a legacy LDAP and a third-party payment endpoint.

2) Change impact analysis before patching hosts

Problem: Patching a VM might break other services that rely on it.
Why this service fits: Host-to-service-to-application relationships enable blast-radius assessment.
Example scenario: Before rebooting a middleware host, ADM shows which web frontends and batch jobs connect to it.

3) Incident triage for cascading failures

Problem: A single failure triggers many alerts and teams blame each other.
Why this service fits: Topology clarifies upstream vs downstream dependency chains.
Example scenario: A database latency issue causes timeouts in three microservices; ADM helps identify the common dependency.

4) Reduce undocumented “shadow” integrations

Problem: Teams added integrations without documentation; security wants visibility.
Why this service fits: Dependency discovery highlights communication paths and endpoints.
Example scenario: A service unexpectedly calls an external analytics endpoint from a private subnet.

5) Support microservice decomposition planning

Problem: Breaking a monolith requires understanding internal coupling.
Why this service fits: The dependency graph shows clusters of components that change together.
Example scenario: ADM identifies that “order” and “billing” modules share DB access patterns and should be separated carefully.

6) Validate network segmentation and firewall rules

Problem: You want to tighten security groups/NSGs, but fear breaking traffic.
Why this service fits: Knowing which ports/services are actually used supports least privilege.
Example scenario: ADM shows only 443 and 1521 are needed; other open ports can be closed.

7) Create an application inventory for governance

Problem: Leadership asks, “How many apps do we run, where, and who owns them?”
Why this service fits: Discovered entities plus tags/compartments provide a structured inventory.
Example scenario: A platform team builds an inventory of 120 apps across 6 compartments and assigns ownership tags.

8) Troubleshoot “works on one host but not another”

Problem: Two environments should be identical, but behavior differs.
Why this service fits: Discovered components reveal differences in running processes and dependency endpoints.
Example scenario: ADM shows one environment connects to a different cache cluster endpoint.

9) Identify shared dependency hot spots (reliability risk)

Problem: Many apps rely on a single shared service with unclear criticality.
Why this service fits: The dependency map highlights high-degree nodes (high fan-in).
Example scenario: A shared message broker is a single point of failure for 18 services; it becomes a reliability priority.

10) M&A or consolidation discovery

Problem: You inherit systems during acquisition and need quick situational awareness.
Why this service fits: Automated mapping accelerates discovery without extensive interviews.
Example scenario: Consolidating two environments reveals duplicated services and cross-dependencies that must be separated.

11) Post-incident learning and documentation improvement

Problem: Postmortems lack hard data on dependency chains.
Why this service fits: Dependency graphs help document the causal chain.
Example scenario: The postmortem includes ADM topology snapshots showing the ripple effect of a DNS failure.

12) Validate DR and failover design

Problem: DR tests fail because hidden dependencies aren’t replicated.
Why this service fits: Dependency discovery reveals which external systems must be reachable in DR.
Example scenario: A DR region lacks access to an on-prem license server that the app depends on.

6. Core Features

Because OCI features can evolve and vary by region, validate feature availability in your tenancy’s Application Dependency Management console and official docs. The features below reflect the common, practical capabilities expected from this service category.

1) Automated discovery (via agents)

What it does: Collects runtime/system information from hosts to identify running application components and their connections.
Why it matters: Manual dependency lists are incomplete and outdated.
Practical benefit: Rapid understanding of a new or legacy environment.
Limitations/caveats: Often requires installing and managing an agent. Verify supported OS versions and network requirements in official docs.

2) Dependency mapping (relationship inference)

What it does: Builds relationships between components (service-to-service, host-to-service, client-to-server).
Why it matters: Dependencies are the primary input for impact analysis and triage.
Practical benefit: “If we change X, what breaks?” becomes answerable.
Limitations/caveats: Mapping quality depends on observed traffic and discovery signals; low-traffic systems may show incomplete graphs.

3) Topology visualization

What it does: Displays entities and relationships as interactive maps/graphs.
Why it matters: Humans understand complex systems faster visually than from raw lists.
Practical benefit: Faster troubleshooting and stakeholder communication.
Limitations/caveats: Very large estates can produce complex graphs; you’ll need filtering by compartment/app/environment.

4) Application-centric views

What it does: Groups discovered components into logical “applications” or service groupings (exact model depends on OCI ADM).
Why it matters: Teams operate on “apps,” not just hosts.
Practical benefit: Easier ownership, tagging, and operational workflows.
Limitations/caveats: Grouping may require manual refinement to match your org’s boundaries.

5) Infrastructure context (hosts, ports, endpoints)

What it does: Associates application components with infrastructure resources (where they run, what they listen on, where they connect).
Why it matters: Many incidents are infrastructure-triggered but application-impacting.
Practical benefit: Clearer handoffs between app and infra teams.
Limitations/caveats: In containerized environments, host-level discovery may not see inside containers unless explicitly supported—verify Kubernetes/container support.

6) Search and filtering

What it does: Find entities by name/type/attributes and filter maps to reduce noise.
Why it matters: Large environments require efficient navigation.
Practical benefit: Quickly locate critical services during incidents.
Limitations/caveats: Search fields and query capabilities vary; confirm in your console.

7) Integration with IAM and compartments

What it does: Uses OCI IAM policies and compartments for access control and resource organization.
Why it matters: Enterprises need separation of duties and least privilege.
Practical benefit: Teams can see only the dependencies relevant to their compartment.
Limitations/caveats: Misconfigured policies can block discovery data access.

8) Auditability (via OCI audit/logging patterns)

What it does: Administrative actions can typically be audited via OCI’s audit capabilities.
Why it matters: Governance and compliance require traceability.
Practical benefit: You can review changes to configurations, keys, and access.
Limitations/caveats: Confirm which ADM actions are captured and where (Audit service) in official docs.

9) APIs/automation (where supported)

What it does: Enables automation for listing entities, managing resources, or integrating with internal tools.
Why it matters: Large orgs need repeatable, scripted workflows.
Practical benefit: CI/CD-adjacent workflows (e.g., update app groupings after deployments).
Limitations/caveats: API surface may not cover every console feature; verify in OCI SDK/CLI docs.

7. Architecture and How It Works

Service architecture (high level)

A typical setup looks like this: 1. You create/configure Application Dependency Management resources in a compartment. 2. You deploy Management Agents on compute instances (or supported hosts). 3. Agents collect discovery signals (processes, connections, config metadata—exactly what is collected depends on the service design and settings). 4. Agents send data to OCI endpoints over secure channels. 5. Application Dependency Management stores the discovered entities and relationships. 6. You view dependency maps in the OCI Console or query via APIs (if available).

Request/data/control flow

Control plane: Console/API actions to configure ADM, install keys, access policies, and views.
Data plane: Agent → OCI ingestion endpoints → ADM storage/model → UI rendering/search.

Integrations with related services

Common OCI-native integrations/patterns: – IAM for authentication/authorization (users, groups, policies) – Compartments for resource isolation and organization – VCN and security rules to allow agent egress to OCI endpoints – Logging for operational visibility (where supported) – Monitoring/Alarms for health signals (agent health, service metrics—verify availability)

Dependency services

You commonly depend on: – OCI Management Agent service (for agent lifecycle, keys, registration) – OCI IAM for policies – Network egress from monitored hosts to OCI service endpoints (via internet/NAT/Service Gateway depending on the service’s endpoint type—verify for your region)

Security/authentication model

Human access: OCI Console/CLI authenticated via IAM (user/password+MFA, federation, API keys).
Agent access: typically uses agent keys/registration and service-managed identity mechanisms (exact flow: verify in Management Agent + ADM docs).

Networking model

Most deployments require: – Outbound connectivity from monitored hosts to OCI ingestion endpoints. – DNS resolution and time sync (NTP) for reliable TLS. – If hosts are in private subnets, you may need NAT Gateway or other approved egress design. Some OCI services can be reached using a Service Gateway when they are on Oracle Services Network—verify whether ADM ingestion endpoints support this pattern in your region.

Monitoring/logging/governance considerations

Track agent health, version drift, and host coverage.
Govern via compartments and tags (env, owner, cost center, app name).
Ensure auditability for changes to install keys, policies, and access.

Simple architecture diagram (Mermaid)

flowchart LR
  Dev[Dev/SRE in OCI Console] -->|IAM Auth| ADM[Application Dependency Management]
  Host1[Compute Instance / Host] -->|Management Agent (telemetry)| ADM
  ADM --> Topology[Dependency Map / Topology View]

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Tenancy[OCI Tenancy]
    subgraph CompA[Compartment: Prod-Apps]
      ADM[Application Dependency Management]
      MAService[Management Agent Service]
    end

    IAM[IAM: Users/Groups/Policies]
    Audit[Audit]
    Log[Logging/Logging Analytics (optional)]
  end

  subgraph Network[VCN: Private Subnets]
    AppVM1[App VM 1\nManagement Agent]
    AppVM2[App VM 2\nManagement Agent]
    DbVM[DB VM\n(optional agent)]
    NAT[NAT Gateway or Approved Egress]
  end

  DevOps[DevOps/SRE] -->|Federation/API Keys| IAM
  IAM --> ADM

  AppVM1 -->|Register/Heartbeat| MAService
  AppVM2 -->|Register/Heartbeat| MAService
  DbVM -->|Register/Heartbeat| MAService

  AppVM1 -->|Discovery Telemetry| ADM
  AppVM2 -->|Discovery Telemetry| ADM
  DbVM -->|Discovery Telemetry| ADM

  AppVM1 --> NAT --> ADM
  AppVM2 --> NAT --> ADM
  DbVM --> NAT --> ADM

  ADM --> Audit
  ADM --> Log

8. Prerequisites

Account/tenancy requirements

An active Oracle Cloud tenancy with permissions to use Observability/Management services.
A compartment strategy (at minimum: a lab compartment).

Permissions / IAM roles

You typically need permissions to: – Create/manage Application Dependency Management resources in a compartment – Create/use Management Agent install keys (if required by the agent onboarding flow) – View management agents and discovered entities/topologies

OCI IAM is policy-based. The exact policy statements can change; use the policy examples from the official docs for: – Application Dependency Management – Management Agent

Start from the docs and apply least privilege: – ADM docs: https://docs.oracle.com/en-us/iaas/application-dependency-management/home.htm
– Management Agent docs (verify the current doc landing page in OCI docs)

Billing requirements

Ensure your tenancy has a valid billing setup.
If the service is included in a broader SKU, charges may still apply for related components (compute instances, NAT gateway, logging ingestion/storage).

CLI/SDK/tools needed

For this tutorial you can use only the OCI Console, but optionally: – OCI CLI: https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm – SSH client to access compute instances – Basic Linux tools (systemctl, curl)

Region availability

OCI service availability varies by region. Confirm that Application Dependency Management is available in your chosen region:
OCI services list / console availability (verify in your console and official docs).

Quotas/limits

Expect quotas for number of agents, discovery capacity, or entity counts (varies).
Check Service Limits in OCI Console and ADM documentation.

Prerequisite services

For the hands-on lab, you will need: – OCI Compute (one small VM) – VCN with a subnet and security rules that allow SSH and outbound access – Management Agent capability (installable on the chosen OS)

9. Pricing / Cost

Current pricing model (how to verify)

Pricing for OCI services is published on Oracle’s official pricing pages, and many services are also supported by the OCI cost estimator.

Use these official starting points and locate Application Dependency Management pricing in your region: – Oracle Cloud Pricing landing page: https://www.oracle.com/cloud/pricing/ – Oracle Cloud cost estimator: https://www.oracle.com/cloud/costestimator.html – OCI price list (often referenced for detailed SKUs): https://www.oracle.com/cloud/price-list/ (Verify current structure/links)

Pricing and SKUs can be region-dependent, edition-dependent, and can change. Always validate against the official pricing pages for your tenancy and region.

Pricing dimensions to expect (common cost drivers)

Even when ADM itself is priced simply, the total cost typically includes:

Management agent coverage – Some OCI management/observability services are priced by number of monitored hosts/agents or by resource hours. – Verify whether ADM charges per agent, per host, per discovered entity, or is bundled.
Compute instances – Your monitored VMs (and any lab VMs) incur Compute cost.
Network egress – If agents send data over the internet/NAT, NAT gateway usage and outbound traffic can create costs. – Cross-region traffic can be more expensive.
Logging and storage – If you enable logging ingestion, analytics, or long retention, you may pay for ingestion, indexing, and storage (service dependent).
Operational overhead – Time spent managing agents, patching, and troubleshooting is an indirect cost.

Free tier

Oracle Cloud has a Free Tier program, but inclusion varies by service and region. Check: – Free Tier overview: https://www.oracle.com/cloud/free/ (Verify whether ADM is included; many management services are not part of Always Free.)

Hidden or indirect costs (common surprises)

NAT Gateway: hourly + data processing charges (service-specific; verify current rates).
Logging Analytics: ingestion and storage can grow quickly if enabled broadly.
Large estates: topology data volume and management overhead increases with scale.

Cost optimization strategies

Start with a small scope: one compartment, one environment (prod or staging), a limited set of hosts.
Use private networking patterns where possible (Service Gateway vs NAT) if supported for the service endpoints—verify.
Use tags to track cost by app/team (CostCenter, Environment, Owner).
Avoid enabling high-volume logging/analytics without retention and sampling plans.

Example low-cost starter estimate (qualitative)

A low-cost lab typically includes: – 1 small compute instance – Minimal log retention – Only required outbound connectivity

Your major cost will usually be the compute instance and any NAT/data processing (if used). Exact numbers vary by region and shape—use the cost estimator and your region’s price list.

Example production cost considerations

In production, plan for: – Number of monitored hosts (agents) – Multiple environments (prod + preprod + DR) – Logging retention requirements – Network architecture (private subnets with controlled egress) – Operational staffing for agent lifecycle

10. Step-by-Step Hands-On Tutorial

This lab is designed to be realistic, safe, and low-cost, and to teach the operational workflow: deploy a host, install the management agent, enable discovery, and view dependencies in Oracle Cloud Application Dependency Management.

Because OCI can generate tenancy-specific install commands/keys, this tutorial uses a mix of exact steps and console-provided commands. Wherever the exact command is tenancy/region-specific, you will copy it directly from the OCI Console.

Objective

Deploy a simple web workload on an OCI compute instance, install the OCI management agent, and use Application Dependency Management to discover and visualize basic application dependencies (host → web service → outbound calls).

Lab Overview

You will: 1. Create a compartment and basic network/compute resources. 2. Install a small web service (Nginx) and generate traffic. 3. Create an Agent Install Key (if required) and install the OCI Management Agent. 4. Enable/verify discovery and view topology in Application Dependency Management. 5. Validate that the host and service relationships appear. 6. Clean up resources to avoid ongoing costs.

Step 1: Create a lab compartment

In OCI Console, open the navigation menu and go to Identity & Security → Compartments.
Click Create Compartment.
Name: adm-lab
Description: Application Dependency Management lab
Click Create Compartment.

Expected outcome: You have a dedicated compartment for lab resources and access control.

Step 2: Create a VCN (or use an existing one)

If you don’t already have a suitable network: 1. Go to Networking → Virtual Cloud Networks. 2. Select compartment: adm-lab 3. Click Create VCN. 4. Choose VCN with Internet Connectivity (wizard). 5. Name: adm-lab-vcn 6. Create.

Expected outcome: You have: – A VCN – A public subnet (or private subnet + NAT, depending on the wizard) – An Internet Gateway and route tables/security lists as created by the wizard

Verification: – Confirm the subnet has a route to the Internet Gateway if it is public. – Confirm security list allows SSH (TCP 22) from your IP (tighten to your IP/CIDR).

Step 3: Create a small Compute instance

Go to Compute → Instances.
Select compartment: adm-lab
Click Create instance.
Name: adm-lab-vm
Image: Oracle Linux (choose a current supported version)
Shape: choose a small/low-cost shape suitable for your tenancy.
Networking: select adm-lab-vcn and a subnet.
SSH keys: upload your public key.
Click Create.

Expected outcome: VM is running and you have its public IP (or private IP if using bastion/VPN).

Verification (SSH):

ssh -i ~/.ssh/<your_key> opc@<VM_PUBLIC_IP>

If you cannot SSH: – Ensure security list/NSG allows inbound TCP/22 from your IP. – Ensure you used the correct username (opc is typical for Oracle Linux images).

Step 4: Install a simple web service and generate dependency signals

On the VM:

Install and start Nginx:

sudo dnf -y install nginx
sudo systemctl enable --now nginx

Allow HTTP in the VM firewall (if enabled):

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --reload

Confirm Nginx is serving locally:

curl -I http://localhost

Generate outbound traffic to create observable dependencies (simple example):

curl -sS https://www.oracle.com/ > /dev/null
curl -sS https://docs.oracle.com/ > /dev/null

Expected outcome: Nginx is running and there is at least some inbound/outbound network activity that a discovery tool could observe.

Verification:

sudo systemctl status nginx --no-pager
ss -lntp | grep ':80' || true

Step 5: Create an Agent Install Key (if your OCI workflow requires it)

Many OCI agent onboarding flows use an Install Key to authorize agent registration.

In OCI Console, locate Management Agent (often under Observability & Management).
Go to Install Keys (name may vary).
Select compartment: adm-lab
Click Create Install Key.
Name: adm-lab-install-key
Create.

Expected outcome: You have an install key available for agent installation.

Verification: The key appears in the list and is in an “Active” state (or similar).

If your tenancy does not use install keys (workflow differs), follow the official Management Agent installation steps shown in your console for your region.

Step 6: Install the OCI Management Agent on the VM

In OCI Console, go to Management Agent → Downloads (or similar).
Select: – OS: Oracle Linux (or your selected image OS) – Compartment: adm-lab – Install Key: adm-lab-install-key (if required)
Copy the exact install command displayed by OCI for your environment.

Run that command on the VM via SSH.

Expected outcome: The management agent installs and starts.

Verification (generic): Check that an agent service is running (service name may vary; verify in your install output):

sudo systemctl status | grep -i agent || true
ps -ef | grep -i agent | head

Also verify in the OCI Console: – Management Agent → Agents – Compartment: adm-lab – Confirm the VM appears and status is “Active” (or “Healthy”).

Common issues: – No outbound connectivity (private subnet without NAT/egress) – DNS resolution problems – Time drift (TLS failures) – Missing IAM permissions to create/use install keys or register agents

Step 7: Enable discovery for Application Dependency Management

In OCI Console, open Application Dependency Management.
Select compartment: adm-lab.
Create/enable the necessary ADM configuration: – You may need to create an “Application” or “Discovery configuration” (names vary by current OCI UI).
Associate the discovered host/agent with the ADM discovery scope.

Expected outcome: ADM begins processing discovery data from the agent.

Verification: – Look for newly discovered entities such as: – The host (adm-lab-vm) – A web server process/service (Nginx) – Outbound endpoints (e.g., oracle.com) if the service models external dependencies (this varies—verify your ADM output)

Discovery results can take several minutes to appear. If nothing appears after 15–30 minutes, use the troubleshooting section.

Step 8: View topology and relationships

In Application Dependency Management, open the Topology or Map view.
Filter by compartment adm-lab and (if available) by application/group.
Click nodes to see attributes and relationships.

Expected outcome: You can visually trace relationships such as: – Host → Nginx service/process – Nginx → clients (if captured) – Host/app → outbound connections (if captured)

Validation

Use the checklist below:

Agent is healthy in OCI Console.
The VM shows as a discovered entity in ADM.
At least one service/process is discovered (Nginx or similar).
A relationship exists between the host and the discovered service.
Topology view renders without permission errors.

Optional validation on-host:

curl -I http://localhost
ss -lntp | grep ':80' || true

Troubleshooting

Issue: Agent does not appear in the console

Confirm you used the correct compartment when creating the install key and installing.
Confirm outbound connectivity from VM:

curl -I https://www.oracle.com

Confirm DNS works:

getent hosts docs.oracle.com

Confirm time sync:

timedatectl status

Issue: Agent appears but ADM shows no discovered entities

Wait 10–30 minutes; first discovery can take time.
Ensure the agent is allowed/associated with ADM discovery scope.
Ensure the VM actually runs services and has network activity (you installed Nginx and generated outbound traffic).
Check agent logs on the VM (log location varies; use install output and official docs to locate exact paths).

Issue: Permissions errors in ADM console

Recheck IAM policies for your user/group.
Ensure you have permissions for both ADM and Management Agent operations in the target compartment.

Cleanup

To avoid ongoing charges:

Terminate the compute instance: – Compute → Instances → adm-lab-vm → Terminate – Choose Delete attached boot volume (if you don’t need it).
Remove ADM resources created in the compartment (if any): – Delete discovery configurations/app groupings as applicable.
Delete the install key (optional): – Management Agent → Install Keys → Delete
Delete the VCN (if created only for this lab): – Networking → VCNs → adm-lab-vcn → Delete
(The wizard typically deletes subnets/gateways with the VCN if allowed.)
Delete the compartment (optional; only if it contains no needed resources).

11. Best Practices

Architecture best practices

Model by environment: separate compartments for dev, test, prod so topology maps remain meaningful.
Start with critical paths: prioritize discovery on tier-0 services (identity, databases, gateways).
Use topology for change planning: make dependency maps part of your pre-change checklist.

IAM/security best practices

Apply least privilege: separate roles for:
Agent installers/operators
ADM viewers
ADM administrators
Use groups and compartments rather than individual permissions.
Require MFA/federation for console access where possible.

Cost best practices

Keep discovery scope focused; don’t onboard every host “just because.”
Avoid high-cost logging/analytics retention without a policy.
Review NAT/data processing if agents send data via NAT from private networks.

Performance best practices

Ensure monitored hosts have stable DNS and time sync to avoid ingestion issues.
Avoid frequent agent reinstallations; standardize agent lifecycle and updates.

Reliability best practices

Treat dependency maps as operational metadata: keep them current via continuous discovery.
Use topology to identify single points of failure and high fan-in dependencies.

Operations best practices

Standardize installation using automation (scripts, configuration management, golden images).
Track coverage: which hosts/apps are onboarded and which are not.
Establish an escalation runbook: “If service X fails, check dependencies Y and Z.”

Governance/tagging/naming best practices

Tag discovered/managed resources with:
Application
Environment
Owner
CostCenter
Name install keys and discovery configurations with environment and region, e.g., prod-adm-install-key-us-ashburn-1.

12. Security Considerations

Identity and access model

OCI IAM controls who can view/manage Application Dependency Management and Management Agents.
Prefer:
Federated identity (SSO)
Group-based policies
Separation of duties

Encryption

Data in transit: agent to OCI endpoints should use TLS (standard for OCI services).
Data at rest: OCI services generally encrypt data at rest; confirm ADM’s encryption specifics in official docs.

Network exposure

Minimize inbound exposure:
Use private subnets and bastion/VPN where appropriate.
Restrict SSH to trusted IPs.
Ensure outbound rules allow only required endpoints/ports for agent communication.

Secrets handling

Avoid storing long-lived secrets on hosts.
If agent install uses tokens/keys:
Treat them as secrets
Rotate/revoke if exposure occurs
Limit their scope (compartment/environment)

Audit/logging

Use OCI Audit to track administrative actions.
Where possible, log agent lifecycle events (install/uninstall/upgrade) using your OS management tooling.

Compliance considerations

Data residency: confirm where ADM stores and processes metadata (region).
PII: dependency data is typically metadata, but service names/URLs can include sensitive info; apply governance and access control.

Common security mistakes

Overly permissive IAM policies (“manage all-resources in tenancy”).
Installing agents broadly without clear ownership and lifecycle controls.
Leaving SSH open to the internet for convenience.
Ignoring egress controls and endpoint allowlists.

Secure deployment recommendations

Use compartments and least privilege.
Prefer private networking with controlled egress.
Maintain an agent lifecycle plan (updates, decommissioning, ownership).
Periodically review topology for unexpected external dependencies.

13. Limitations and Gotchas

Because details vary by region and service version, confirm exact limits in official docs and in OCI Service Limits. Common gotchas include:

Discovery completeness depends on traffic: quiet systems may show incomplete dependency edges.
Agent requirement: if ADM requires a management agent, environments that forbid agents may not be eligible.
Container visibility: host-based discovery might not fully represent container-level services unless explicitly supported.
Private subnet egress: agents need outbound connectivity to OCI endpoints; missing NAT/egress breaks ingestion.
Graph complexity at scale: large environments require strong filtering, naming, and tagging to remain usable.
IAM misconfiguration: missing permissions for install keys/agent registration commonly blocks onboarding.
Regional boundaries: discovery data might be region-bound; multi-region estates need multi-region planning.
Change management: uninstalling agents or terminating hosts can leave stale entities until the system reconciles them (behavior varies; verify retention/aging behavior in docs).

14. Comparison with Alternatives

Application Dependency Management overlaps with observability, CMDB, and tracing tools, but the value proposition is specifically dependency discovery and topology.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
OCI Application Dependency Management	OCI-centric dependency discovery and topology	Native OCI integration (IAM/compartments), practical topology focus	May require agents; feature scope depends on region/tenancy; not a build dependency tool	You run workloads on OCI and need runtime dependency maps for ops and change management
OCI APM / Distributed Tracing (service name varies)	Request-level tracing across microservices	Deep latency breakdowns, trace correlation	Not a full topology inventory by itself; requires instrumentation	You need performance traces and code-level visibility
OCI Logging / Logging Analytics	Log search, analytics, security investigations	Powerful for debugging and auditing	Doesn’t automatically build dependency graphs	You need log-centric troubleshooting and compliance
ServiceNow CMDB / ITOM Discovery	Enterprise CMDB and governance	Mature CMDB model, enterprise workflows	Integration overhead, licensing, may be complex	Large enterprises needing a CMDB as source of truth
Dynatrace / AppDynamics / Datadog Service Map	Full-stack observability + service mapping	Strong auto-discovery, AIOps features	Vendor cost, agent overhead, cross-platform lock-in	You want a single commercial platform across multiple clouds
AWS X-Ray / Service Map	AWS-centric tracing and service maps	Deep AWS integrations	AWS-only focus	Workloads are primarily on AWS
Azure Application Insights / Application Map	Azure-centric app topology	Azure integration, developer tooling	Azure-only focus	Workloads are primarily on Azure
OpenTelemetry + Jaeger/Tempo + custom topology	Self-managed observability stacks	Flexibility, open standards	You build/maintain it; topology inventory is non-trivial	You need portability and can invest in platform engineering

15. Real-World Example

Enterprise example (regulated financial services)

Problem: A bank is migrating 200+ VM-based applications into OCI. Change approvals require clear impact analysis, but dependency documentation is outdated.
Proposed architecture:
Use compartments per environment and LOB (line of business)
Install management agents on migrated hosts
Use Application Dependency Management to build topology for each app
Integrate operational workflows with incident management (process-level, not necessarily tool-level integration)
Why this service was chosen:
Native OCI governance (IAM, compartments)
Automated discovery reduces manual documentation burden
Supports migration planning by revealing hidden dependencies
Expected outcomes:
Faster migration waves with fewer cutover surprises
Reduced outage risk during patching and network changes
Improved audit evidence for change approvals

Startup/small-team example (SaaS on OCI)

Problem: A small SaaS team runs 20 microservices on VMs/managed services. Incidents are frequent because dependencies aren’t documented and ownership is informal.
Proposed architecture:
Start with onboarding only tier-0 and tier-1 services
Use ADM topology to create an “ops view” of critical dependency paths
Use tags for owner and environment
Why this service was chosen:
Quick visibility without building an internal dependency registry
Helps a small team respond faster during incidents
Expected outcomes:
Shorter incident triage time
Better prioritization of reliability work (identify shared bottlenecks)
Clearer onboarding for new engineers

16. FAQ

1) Is Oracle Cloud Application Dependency Management a package/library dependency tool (like Maven or npm)?
No. It is focused on runtime/system dependencies between running components (services, hosts, endpoints), not build-time library dependencies.

2) Do I need to install an agent?
In many OCI setups, dependency discovery relies on a Management Agent installed on hosts. Confirm the exact requirements and supported platforms in the official docs for your region.

3) Can it map dependencies for Kubernetes workloads?
Possibly, but visibility depends on what OCI ADM supports (host-based vs container-aware discovery). Verify Kubernetes/container support in the ADM documentation.

4) How long does discovery take to show results?
Initial discovery often takes minutes, sometimes longer depending on agent health, network, and service processing. If nothing appears after 15–30 minutes, check agent status and permissions.

5) What’s the difference between APM and Application Dependency Management?
APM typically provides request traces and performance details (latency, spans). Application Dependency Management focuses on topology and dependency relationships.

6) Does ADM work for hybrid or on-prem hosts?
If the agent can run on those hosts and connect outbound to OCI endpoints, hybrid discovery may be possible. Confirm supported OS/network requirements in the docs.

7) Does it support multi-region architectures?
OCI services are often region-scoped. You may need to manage discovery per region. Verify multi-region behavior and cross-region viewing in the official docs.

8) Is the dependency map always accurate?
It can be incomplete if traffic is low, blocked, encrypted in a way that prevents inference, or if the discovery scope is limited. Use it as a strong signal, not a perfect truth.

9) Can I export the dependency map?
Some services provide export or API access. Confirm export options and APIs in your tenancy’s console and the official docs.

10) Does ADM store sensitive data?
Typically it stores metadata about components and connections. Still, metadata can be sensitive (hostnames, endpoints). Apply least privilege and compartment isolation.

11) What IAM permissions do I need?
You need permissions to manage/view ADM resources and to onboard/operate management agents. Use the official IAM policy examples from Oracle docs and tailor to least privilege.

12) How do I keep the map current?
Maintain continuous discovery: keep agents healthy, update them, and ensure network connectivity. Treat discovery as an ongoing operational capability.

13) What causes agents to stop reporting?
Common causes: outbound network changes, DNS failures, time drift, expired/revoked install authorization, or agent service stopped.

14) Can I use ADM to design firewall rules?
It can help by showing real dependencies, but you should validate with network flow logs, security reviews, and staged enforcement.

15) What’s the first thing to onboard?
Start with one critical application in a non-production environment to validate policies, networking, and operational workflow—then expand.

16) How does ADM help with DR planning?
It reveals dependencies that must be available during failover (external services, on-prem endpoints, shared databases). This reduces DR test surprises.

17. Top Online Resources to Learn Application Dependency Management

Resource Type	Name	Why It Is Useful
Official documentation	OCI Application Dependency Management Docs	Authoritative feature scope, concepts, IAM, and workflows. https://docs.oracle.com/en-us/iaas/application-dependency-management/home.htm
Official pricing	Oracle Cloud Pricing	Official pricing entry point; locate ADM SKU details. https://www.oracle.com/cloud/pricing/
Pricing calculator	Oracle Cloud Cost Estimator	Build region-specific estimates (compute, network, monitoring). https://www.oracle.com/cloud/costestimator.html
Official price list	Oracle Cloud Price List	SKU-level reference (verify ADM listing). https://www.oracle.com/cloud/price-list/
Official CLI docs	OCI CLI Installation and Usage	Useful for scripting agent/compartment operations (where supported). https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm
Architecture center	Oracle Architecture Center	Reference architectures and best practices patterns. https://docs.oracle.com/en/solutions/
Official YouTube	Oracle Cloud Infrastructure (OCI) YouTube	Product walkthroughs and service explanations (search for ADM/observability). https://www.youtube.com/@OracleCloudInfrastructure
Tutorials/labs	Oracle LiveLabs	Hands-on labs for OCI services; search for observability/management labs. https://livelabs.oracle.com/
Community learning	Oracle Cloud Customer Connect	Practical discussions, Q&A, and announcements (validate against docs). https://community.oracle.com/customerconnect/categories/oci
SDK docs	OCI SDK Documentation	Programmatic access patterns (verify ADM API availability). https://docs.oracle.com/en-us/iaas/Content/API/Concepts/sdks.htm

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website
DevOpsSchool.com	DevOps engineers, SREs, platform teams	DevOps practices, cloud operations, observability basics	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate engineers	SCM/DevOps fundamentals, toolchain concepts	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud operations teams	Cloud ops practices, monitoring, automation	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, reliability-focused teams	SRE practices, incident response, SLOs/SLIs	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops and engineering teams	AIOps concepts, observability-driven operations	Check website	https://www.aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps/cloud training content (verify exact offerings)	Beginners to advanced DevOps learners	https://rajeshkumar.xyz/
devopstrainer.in	DevOps coaching/training platform (verify exact offerings)	DevOps engineers and students	https://www.devopstrainer.in/
devopsfreelancer.com	DevOps freelance/training services (verify exact offerings)	Teams needing targeted help	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support and guidance resources (verify exact offerings)	Ops teams needing practical support	https://www.devopssupport.in/

20. Top Consulting Companies

Company Name	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify offerings)	OCI onboarding, observability setup, automation	Agent onboarding strategy, compartment/IAM design, dependency mapping rollout	https://cotocus.com/
DevOpsSchool.com	DevOps consulting and training services	DevOps transformation, monitoring/ops practices	Standardizing agent installs, operational runbooks, governance and tagging	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting services (verify offerings)	CI/CD, cloud operations, reliability practices	Building rollout plans for discovery, aligning topology with incident response	https://devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before this service

OCI fundamentals: tenancies, regions, compartments, VCNs
IAM fundamentals: groups, policies, least privilege
Basic Linux administration: services, networking, firewall
Observability basics: logs, metrics, traces, topology, SLO concepts

What to learn after this service

OCI Logging/Logging Analytics (if used in your org)
OCI Monitoring/Alarms and operational dashboards
Distributed tracing and instrumentation (OpenTelemetry, OCI APM if applicable)
Network security design (NSGs, security lists, egress control)
Reliability engineering: incident management, postmortems, SLOs

Job roles that use it

DevOps Engineer
Site Reliability Engineer (SRE)
Cloud Engineer / Cloud Operations Engineer
Platform Engineer
Solutions Architect / Cloud Architect
Security Engineer (dependency exposure and segmentation reviews)

Certification path (if available)

Oracle certification programs evolve. If you want an OCI-aligned path: – Start with OCI foundations/architect tracks and then specialize in observability/operations topics.
Verify current OCI certification offerings here: https://education.oracle.com/ (search for OCI certifications relevant to observability and operations).

Project ideas for practice

Dependency mapping for a 3-tier app: VM web + VM app + managed DB; document blast radius for each tier.
Change impact report: pick a host patch window; use topology to list impacted services.
Security segmentation exercise: tighten NSGs/security lists based on observed dependencies.
Migration readiness checklist: map dependencies for a legacy app and propose a phased migration plan.

22. Glossary

ADM (Application Dependency Management): OCI service for discovering and visualizing runtime dependencies between application components.
Topology: A graph/map showing components (nodes) and relationships (edges).
Dependency: A relationship where one component relies on another (e.g., service A calls DB B).
Blast radius: The scope of impact caused by a change or failure in a component.
Management Agent: Host-installed software that collects telemetry for OCI management/observability services (exact capabilities vary).
Compartment: OCI logical container for organizing and isolating resources and access control.
IAM Policy: Statement-based permissions defining who can do what in OCI.
VCN (Virtual Cloud Network): OCI private network construct with subnets, route tables, gateways, and security rules.
NSG (Network Security Group): OCI security construct to apply virtual firewall rules to VNICs.
Egress: Outbound traffic leaving a subnet/host to reach external endpoints/services.
Service Gateway: OCI gateway enabling private access to supported Oracle services without public internet (availability depends on service).
NAT Gateway: Provides outbound internet access for private subnet resources without inbound exposure.
SLO/SLI: Reliability targets (Objectives) and measurements (Indicators).
CMDB: Configuration Management Database—inventory of IT assets and relationships.
Distributed tracing: Observability technique tracking requests across services using trace IDs and spans.

23. Summary

Application Dependency Management (Oracle Cloud) helps teams discover and visualize runtime dependencies between applications and infrastructure. It matters because modern systems change constantly, and undocumented dependencies are a leading cause of outages and failed migrations.

In the Oracle Cloud ecosystem, Application Dependency Management typically fits alongside management agents, IAM/compartments, and observability services. Cost depends on your pricing model (verify in the official pricing pages) and is often driven by monitored hosts/agents plus indirect costs like compute, NAT, and logging retention.

Use it when you need topology visibility for operations, change management, migrations, and security reviews. Avoid treating it as a build dependency tool; it is designed for runtime dependency mapping.

Next learning step: validate your region’s official documentation and pricing, then run a small pilot: onboard one application, confirm discovery accuracy, and operationalize topology reviews as part of incident response and change planning.

rajeshkumar

Category