Qu’est-ce qu’OSIRIS JSON

OSIRIS (Open Standard for Infrastructure Resource Interchange Schema) définit un format JSON vendor-neutral permettant de décrire des ressources d'infrastructure, leurs propriétés et leurs relations topologiques dans des environnements hétérogènes avec une voie d'extension pour OT lorsque cela s'applique.

En tant que schema d'interchange, OSIRIS JSON normalise les exports provenant de sources diverses et permet une consommation portable par des outils dédiés à la diagrammation, à la documentation, aux workflows d'inventaire/CMDB, aux preuves d'audit et aux intégrations, sans exiger que chaque consumer implémente et maintienne des parsers spécifiques aux vendors.

OSIRIS JSON définit un schema JSON canonique qui agit comme un middleware neutre entre les sources de données d'infrastructure et les applications consommatrices. Au lieu d'intégrer une logique de parsing spécifique aux vendors dans chaque outil, OSIRIS JSON adopte une approche en couche de traduction :

PRODUCERS (parsers, translators, discovery agents) traduisent les représentations source/vendor en documents OSIRIS JSON.
CONSUMERS (outils de diagrammation, CMDBs, IPAMs, DCIMs, pipelines de documentation) lisent et traitent un schema unique et bien défini.

Cela découple les sources de données des applications consommatrices, réduisant la complexité d'intégration de S×C (S sources × C consumers) à P+C (P producers + C consumers).

Cela découple les sources de données des applications et réduit la complexité d’intégration. Dans un environnement comportant S systèmes sources et C applications consommatrices, l’effort d’intégration passe de mappages directs S×C à S mappages de producer (source > OSIRIS) plus C mappages de consumer (OSIRIS > application).

Le défi

Les données d’infrastructure sont exposées via des formats et modèles spécifiques aux vendors, avec des sémantiques incohérentes pour des concepts équivalents tels que l’identité, les propriétés, les relations et la hiérarchie. Dans des environnements mixtes couvrant hyperscalers, public cloud, systèmes on-prem et infrastructure OT, le problème s’amplifie. Le résultat est un tooling fragmenté et parfois coûteux, des exports incohérents et une documentation accompagnée d’une topologie fragmentée ou de faible qualité qui devient rapidement obsolète.

crisis_alert

Conséquences de la fragmentation

crisis_alert

Complexité d'intégration

Les outils doivent maintenir des adapters, des mappages et des translators spécifiques aux vendors.
crisis_alert

Coût de maintenance élevé

Les APIs et les modèles de données spécifiques aux vendors évoluent, imposant des mises à jour continues des parsers et des intégrations et faisant exploser les coûts au fil du temps.
crisis_alert

Sémantique de topologie incohérente

Les relations peuvent être implicites, incomplètes ou représentées différemment selon les sources, rendant la topologie difficile à comparer et à réutiliser.
crisis_alert

Dérive de la documentation

La traduction manuelle est fragile ; la documentation est médiocre et les diagrammes sont souvent de faible qualité, avec des icônes incompréhensibles et des flux chaotiques qui deviennent rapidement obsolètes.
crisis_alert

Risque de connaissance tribale

Sans standard partagé, le contexte critique réside souvent dans la tête des personnes. Lorsqu'elles partent, cette connaissance part avec elles et les systèmes deviennent plus difficiles à comprendre et à exploiter.
crisis_alert

Risque de lock-in

Les organisations peuvent devenir dépendantes de solutions de normalisation fermées, spécifiques aux vendors ou payantes, difficiles à remplacer ou susceptibles de ne pas être maintenues avec une vision de long terme.

verified

Approche Open Standard d'OSIRIS JSON

verified

Schema d'interchange JSON neutre

Un format vendor-neutral pour échanger des ressources d'infrastructure et de la topologie entre systèmes.
verified

Les producers traduisent les exports sources en documents OSIRIS

Parsers/translators/discovery agents mappent les représentations natives vers le schema OSIRIS.
verified

Les consumers implémentent un schema pour de nombreuses sources

Les outils peuvent lire un format de document unique et bien défini dans différents environnements.
verified

Relations de topologie explicites et de première classe

Connections, dépendances, conteneurs et regroupements sont représentés directement afin qu'un snapshot puisse décrire ce qui existe et comment cela se relie à un instant donné.
verified

Compatibilité ascendante grâce à l'ignorance sûre des champs inconnus

Les consumers peuvent ignorer les propriétés et extensions inconnues sans casser le traitement de base.
verified

Les extensions sont prises en charge nativement

Un mécanisme défini permet aux vendors et aux utilisateurs d'enrichir les documents sans rompre l'interopérabilité.

Capacités principales

schema Conception unifiée

Conçu pour des environnements IT hétérogènes, avec une voie d'extension claire pour OT et d'autres domaines à mesure que l'adoption progresse.

hub Modèle de relations explicite

Représentation de première classe des connections, dépendances, conteneurs et autres relations de topologie.

account_tree Constructions de regroupement

Prise en charge du regroupement logique et physique reflétant les structures organisationnelles et architecturales réelles sans imposer une taxonomie unique.

dns Attribution du provider

Les ressources conservent la traçabilité vers leur système/provider source tout en utilisant une représentation standardisée et vendor-neutral.

extension Extensibilité

Un mécanisme défini pour les propriétés spécifiques aux vendors et les custom resource types sans rompre la compatibilité.

verified_user Validation à trois niveaux

Validation structurelle (schema), sémantique et de domaine améliorant la cohérence et la qualité des données lorsqu'un outil de validation est appliqué.

Principes de conception

Format de snapshot statique

OSIRIS JSON est un format d'interchange de snapshot statique. Il capture ce qui existe et comment cela se relie à un instant donné. Il n'a pas été conçu comme un système de monitoring en temps réel, un outil de déploiement ou un moteur Infrastructure-as-Code.

Ce que N’EST PAS OSIRIS JSON

close Ni télémétrie ni monitoring en temps réel

OSIRIS JSON décrit l'état de la topologie et de l'inventaire, et non des métriques de séries temporelles, des logs ou des données d'observabilité. Des projets comme Prometheus, Grafana, Zabbix, OpenTelemetry répondent aux besoins de télémétrie.

close Ni déploiement ni orchestration d'infrastructure

OSIRIS JSON n'est ni un langage infrastructure-as-code ni une spécification de déploiement. Des projets comme Terraform, CloudFormation ou TOSCA Oasis répondent aux workflows de déploiement.

close Ni gestion de configuration

OSIRIS JSON ne définit ni n'impose de configuration desired state pour les ressources. Les systèmes de gestion de configuration comme Ansible, Puppet, Chef, Salt remplissent ce rôle.

close Ni suivi des changements ni historique

OSIRIS JSON représente un snapshot ponctuel. Le suivi des changements dans le temps relève de la responsabilité des systèmes producers et consumers.

close Ni authentification, ni autorisation, ni politiques d'accès

OSIRIS JSON peut transporter des metadata décrivant des frontières ou l'ownership, mais il ne définit ni mécanismes ni politiques de contrôle d'accès.

close Informations de coût et de facturation

La facturation détaillée et la modélisation financière sont hors du périmètre du core schema, bien que des metadata liées aux coûts puissent être incluses par extension.

Structure du document

Les documents OSIRIS sont des objets JSON. Dans la Specification v1.0.0, l’objet de premier niveau est défini autour de trois champs : version, metadata et topology. Un champ $schema optionnel peut être inclus pour référencer l’URI du schema.

[!NOTE] Il s’agit d’un aperçu de haut niveau du schema OSIRIS JSON. Les $defs sont omis ici pour améliorer la lisibilité au niveau supérieur ; référez-vous à l’URI canonique pour le schema complet.

Le core schema OSIRIS JSON définit :

{
  "$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és d'infrastructure identifiables de manière unique avec des propriétés et l'attribution du provider.

topology.connections

Relations explicites et direction entre ressources (network, dependency, containment, data flow, etc.).

topology.groups

Collections logiques ou physiques qui organisent les ressources (par ex. VPC, subnet, rack, data center).

Validation et interopérabilité