OSIRIS JSON IT Infrastructure Examples

To help you understand how the OSIRIS JSON specification maps raw, vendor-specific infrastructure configurations to a unified, vendor-neutral schema, we have provided a set of reference JSON files. These examples represent common enterprise topologies across cloud, hybrid, and on-premises architectures.

Each example demonstrates the application of the three core pillars of the OSIRIS schema:

• resources: The discrete inventory items (VMs, subnets, routers) with their unique identifiers and properties.
• connections: Explicit directional edges (containment, network routing, storage dependency) linking those resources.
• groups: Logical and physical boundaries (AWS accounts, Azure resource groups, geographic regions, VRFs).

---

Exploring the IT Example Catalog

Browse the catalog below to find the schema configuration that aligns with your environment. You can open or download the raw JSON files directly:

Cloud Provider (Minimal)

A minimal, entry-level cloud snapshot designed to show the core envelope structure. Ideal for developers writing their first producer parser.

Open the minimal cloud example

Hyperscalers (AWS, Azure, Multi-Cloud)

Examples of native public cloud topologies, showcasing how ARM resource IDs and AWS ARNs map into a single canonical ID structure.

• Minimal Hyperscalers Infrastructure
• AWS Three-Tier Web Application
• Microsoft Azure Resource Group Hierarchy
• Multi-Cloud Web Application (AWS + Azure)

Hybrid Cloud Infrastructure

A complex topology showcasing cross-domain connections. It demonstrates how to link on-premises resources (hypervisors, physical switches) to public cloud endpoints via ExpressRoute or VPN Gateways.

Open the hybrid cloud example

On-Premises Hardware & Networks

Classic data center architectures containing physical assets. These show how to map physical network interfaces, switch-to-switch links (LLDP/CDP), and virtualization layers.

• Minimal On-Premises Infrastructure
• Arista Spine/Leaf network topology

---

Architectural Patterns Illustrated

When reviewing these OSIRIS JSON examples, pay special attention to the following design patterns:

1. Canonical Resource Naming

OSIRIS encourages a prefix-based, globally unique naming convention for resource IDs (e.g., aws::arn:aws:ec2:... or azure::/subscriptions/...). This ensures that when multiple snapshots from different providers are merged, resources never experience naming collisions.

2. Explicit Topology Relationships

Instead of forcing consumers to infer routing or containment based on subnets or folders, connections are declared as explicit objects:

• contains: Demarcates physical or logical containment (e.g., a Subnet containing a Virtual Machine).
• network: Indicates that data flow is possible between two interfaces or nodes.
• dependency: Represents logical coupling (e.g., an App Service Web App bound to a backend SQL Database).

3. Graceful Degradation under Partial Data

Enterprise environments are rarely perfectly documented. The OSIRIS specification supports partial data mapping. If a producer cannot query a remote peering link due to permissions, it represents the remote end as a stub resource with status: unknown, allowing the connection edge to survive the organizational boundary.