Che cos’è OSIRIS JSON

OSIRIS (Open Standard for Infrastructure Resource Interchange Schema) definisce un formato JSON vendor-neutral per descrivere risorse infrastrutturali, le loro proprietà e le loro relazioni topologiche in ambienti eterogenei, con un percorso di estensione per OT dove applicabile.

Come schema di interscambio, OSIRIS JSON normalizza gli export provenienti da fonti diverse e ne consente il consumo portabile da parte di strumenti dedicati a diagrammi, documentazione, workflow inventory/CMDB, evidenze di audit e integrazioni, senza richiedere a ciascun consumer di implementare e mantenere parser specifici per vendor.

OSIRIS JSON definisce uno schema JSON canonico che agisce come middleware neutrale tra le fonti di dati infrastrutturali e le applicazioni consumer. Invece di incorporare in ogni strumento logiche di parsing specifiche per vendor, OSIRIS JSON adotta un approccio a livello di traduzione:

PRODUCERS (parser, translator, discovery agent) traducono le rappresentazioni della sorgente/del vendor in documenti OSIRIS JSON.
CONSUMERS (strumenti di diagrammazione, CMDB, IPAM, DCIM, pipeline di documentazione) leggono ed elaborano un unico schema ben definito.

Questo disaccoppia le fonti di dati dalle applicazioni consumer, riducendo la complessità di integrazione da S×C (S sorgenti × C consumer) a P+C (P producer + C consumer).

Questo disaccoppia le fonti di dati dalle applicazioni e riduce la complessità di integrazione. In un ambiente con S sistemi sorgente e C applicazioni consumer, lo sforzo di integrazione passa da mapping diretti S×C a S mapping producer (source > OSIRIS) più C mapping consumer (OSIRIS > application).

La sfida

I dati infrastrutturali vengono esposti attraverso formati e modelli specifici per vendor, con semantiche incoerenti per concetti equivalenti come identità, proprietà, relazioni e gerarchia. In ambienti misti che includono hyperscaler, public cloud, sistemi on-prem e infrastruttura OT, il problema si amplifica. Il risultato è una toolchain frammentata e talvolta costosa, export incoerenti e documentazione con topologie frammentate o di bassa qualità che diventano rapidamente obsolete.

crisis_alert

Conseguenze della frammentazione

crisis_alert

Complessità di integrazione

Gli strumenti devono mantenere adapter, mapping e translator specifici per vendor.
crisis_alert

Costo di manutenzione elevato

Le API e i modelli dati specifici per vendor evolvono, imponendo aggiornamenti continui a parser e integrazioni e facendo esplodere i costi nel tempo.
crisis_alert

Semantica della topologia incoerente

Le relazioni possono essere implicite, incomplete o rappresentate in modo diverso tra le sorgenti, rendendo la topologia difficile da confrontare e riutilizzare.
crisis_alert

Deriva della documentazione

La traduzione manuale è fragile; la documentazione è scarsa e i diagrammi sono per lo più di bassa qualità, con icone incomprensibili e flussi caotici che diventano rapidamente obsoleti.
crisis_alert

Rischio di conoscenza tribale

Senza uno standard condiviso, il contesto critico resta spesso nella testa delle persone. Quando queste se ne vanno, la conoscenza se ne va con loro e i sistemi diventano più difficili da comprendere e gestire.
crisis_alert

Rischio di lock-in

Le organizzazioni possono diventare dipendenti da soluzioni di normalizzazione chiuse, specifiche per vendor o a pagamento, difficili da sostituire o non mantenute con una visione di lungo periodo.

verified

Approccio Open Standard di OSIRIS JSON

verified

Schema di interscambio JSON neutrale

Un formato vendor-neutral per scambiare risorse infrastrutturali e topologia tra sistemi.
verified

I producer traducono gli export delle sorgenti in documenti OSIRIS

Parser/translator/discovery agent mappano le rappresentazioni native nello schema OSIRIS.
verified

I consumer implementano uno schema unico per molte sorgenti

Gli strumenti possono leggere un singolo formato documento ben definito in ambienti differenti.
verified

Relazioni topologiche esplicite e di prima classe

Connection, dipendenze, contenimento e raggruppamenti sono rappresentati direttamente, così che uno snapshot possa descrivere cosa esiste e come si relaziona in un determinato momento.
verified

Compatibilità futura attraverso l'ignorare in sicurezza i campi sconosciuti

I consumer possono ignorare proprietà ed estensioni sconosciute senza compromettere l'elaborazione di base.
verified

Le estensioni sono supportate nativamente

Un meccanismo definito consente a vendor e utenti di arricchire i documenti senza compromettere l'interoperabilità.

Capacità principali

schema Progettazione unificata

Progettato per ambienti IT eterogenei, con un chiaro percorso di estensione per OT e altri domini man mano che l'adozione cresce.

hub Modello di relazioni esplicito

Rappresentazione di prima classe di connection, dipendenze, contenimento e altre relazioni topologiche.

account_tree Costrutti di raggruppamento

Supporto per raggruppamenti logici e fisici che riflettono strutture organizzative e architetturali reali senza imporre una tassonomia unica.

dns Attribuzione del provider

Le risorse preservano la tracciabilità verso il proprio sistema/provider sorgente, utilizzando al contempo una rappresentazione standardizzata e vendor-neutral.

extension Estendibilità

Un meccanismo definito per proprietà specifiche per vendor e custom resource type senza compromettere la compatibilità.

verified_user Validazione a tre livelli

Validazione strutturale (schema), semantica e di dominio che migliora coerenza e qualità dei dati quando viene applicata la toolchain di validazione.

Principi di progettazione

Formato snapshot statico

OSIRIS JSON è un formato di interscambio basato su snapshot statici. Cattura ciò che esiste e come si relaziona in un determinato momento. Non è stato progettato come sistema di monitoraggio real-time, strumento di deployment o motore Infrastructure-as-Code.

Cosa NON è OSIRIS JSON

close Non è telemetria e monitoraggio real-time

OSIRIS JSON descrive topologia e stato dell'inventario, non metriche time-series, log o dati di osservabilità. Progetti come Prometheus, Grafana, Zabbix e OpenTelemetry affrontano gli aspetti di telemetria.

close Non è deployment e orchestrazione dell'infrastruttura

OSIRIS JSON non è un linguaggio infrastructure-as-code né una specifica di deployment. Progetti come Terraform, CloudFormation o TOSCA Oasis coprono i workflow di deployment.

close Non è gestione della configurazione

OSIRIS JSON non definisce né impone la configurazione desired state per le risorse. Sistemi di configuration management come Ansible, Puppet, Chef e Salt assolvono a questo scopo.

close Non è tracciamento delle modifiche e storico

OSIRIS JSON rappresenta uno snapshot puntuale. Il tracciamento delle modifiche nel tempo è responsabilità dei sistemi producer e consumer.

close Non è autenticazione, autorizzazione e policy di accesso

OSIRIS JSON può trasportare metadati che descrivono confini o ownership, ma non definisce meccanismi o policy di access control.

close Informazioni di costo e fatturazione

La fatturazione dettagliata e la modellazione finanziaria sono fuori dall'ambito del core schema, anche se metadati relativi ai costi possono essere inclusi tramite estensione.

Struttura del documento

I documenti OSIRIS sono oggetti JSON. Nella Specification v1.0.0, l’oggetto top-level è definito attorno a tre campi: version, metadata e topology. Un campo $schema opzionale può essere incluso per fare riferimento allo schema URI.

[!NOTE] Questo è uno schema di alto livello di OSIRIS JSON. I $defs sono omessi qui per migliorare la leggibilità del top-level; fai riferimento all’URI canonico per lo schema completo.

Il core schema di OSIRIS JSON definisce:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema#",
  "$id": "https://osirisjson.org/schema/v1.0/osiris.schema.json",
  "title": "Core OSIRIS JSON Schema v1.0",
  "description": "OSIRIS Open Standard for Infrastructure Resource Interchange Schema. This schema encodes baseline interoperability requirements; additional semantic rules (e.g. referential integrity, uniqueness) are validated by tooling.",
  "type": "object",
  "required": [
    "version",
    "metadata",
    "topology"
  ],
  "properties": {
    "$schema": {
      "type": "string",
      "description": "Optional JSON Schema dialect reference for OSIRIS documents.",
      "format": "uri"
    },
    "version": {
      "type": "string",
      "description": "OSIRIS specification version of this document (semver). For the v1.0 schema endpoint, any 1.x.y is allowed.",
      "pattern": "^1\\.[0-9]+\\.[0-9]+$"
    },
    "metadata": {
      "$ref": "#/$defs/metadata"
    },
    "topology": {
      "$ref": "#/$defs/topology"
    }
  },
  "additionalProperties": true,
  "$defs": {
    "osirisType": { },
    "providerName": { },
    "namespaceKey": { },
    "tags": { },
    "freeformObject": { },
    "extensions": { },
    "provider": { },
    "resource": { },
    "connectionDirection": { },
    "connectionType": { },
    "connection": { },
    "group": { },
    "topology": { },
    "metadataGenerator": { },
    "metadataScope": { },
    "metadata": { }
  }
}

topology.resources

Entità infrastrutturali identificabili in modo univoco, con proprietà e attribuzione del provider.

topology.connections

Relazioni esplicite e direzione tra risorse (rete, dipendenza, contenimento, flusso dati, ecc.).

topology.groups

Collezioni logiche o fisiche che organizzano le risorse (ad es. VPC, subnet, rack, data center).

Validazione e interoperabilità