Qué es OSIRIS JSON

OSIRIS (Open Standard for Infrastructure Resource Interchange Schema) define un formato JSON vendor-neutral para describir recursos de infraestructura, sus propiedades y sus relaciones topológicas en entornos heterogéneos, con una ruta de extensión para OT cuando corresponda.

Como schema de intercambio, OSIRIS JSON normaliza exportaciones de fuentes diversas y permite un consumo portable por herramientas dedicadas a diagramación, documentación, flujos de inventario/CMDB, evidencia de auditoría e integraciones, sin requerir que cada consumer implemente y mantenga parsers específicos de vendor.

OSIRIS JSON define un schema JSON canónico que actúa como middleware neutral entre las fuentes de datos de infraestructura y las aplicaciones consumers. En lugar de incrustar lógica de parsing específica de vendor en cada herramienta, OSIRIS JSON adopta un enfoque de capa de traducción:

PRODUCERS (parsers, translators, discovery agents) traducen representaciones de source/vendor en documentos OSIRIS JSON.
CONSUMERS (herramientas de diagramación, CMDBs, IPAMs, DCIMs, pipelines de documentación) leen y procesan un único schema bien definido.

Esto desacopla las fuentes de datos de las aplicaciones consumers, reduciendo la complejidad de integración de S×C (S fuentes × C consumers) a P+C (P producers + C consumers).

Esto desacopla las fuentes de datos de las aplicaciones y reduce la complejidad de integración. En un entorno con S sistemas fuente y C aplicaciones consumers, el esfuerzo de integración pasa de mapeos directos S×C a S mapeos de producer (source > OSIRIS) más C mapeos de consumer (OSIRIS > application).

El desafío

Los datos de infraestructura se exponen mediante formatos y modelos específicos de vendor, con semánticas inconsistentes para conceptos equivalentes como identidad, propiedades, relaciones y jerarquía. En entornos mixtos que abarcan hyperscalers, public cloud, sistemas on-prem y infraestructura OT, el problema se agrava. El resultado es tooling fragmentado y a veces de alto coste, exportaciones inconsistentes y documentación con topología fragmentada o de baja calidad que rápidamente queda desactualizada.

crisis_alert

Consecuencias de la fragmentación

crisis_alert

Complejidad de integración

Las herramientas deben mantener adapters, mapeos y translators específicos de vendor.
crisis_alert

Alto coste de mantenimiento

Las APIs y los modelos de datos específicos de vendor evolucionan, obligando a actualizaciones continuas de parsers e integraciones y disparando los costes con el tiempo.
crisis_alert

Semántica de topología inconsistente

Las relaciones pueden ser implícitas, incompletas o estar representadas de forma distinta entre fuentes, lo que hace que la topología sea difícil de comparar y reutilizar.
crisis_alert

Deriva de la documentación

La traducción manual es frágil; la documentación es pobre y los diagramas son de baja calidad la mayor parte del tiempo, con iconos incomprensibles y flujos caóticos que rápidamente quedan obsoletos.
crisis_alert

Riesgo de conocimiento tribal

Sin un estándar compartido, el contexto crítico suele vivir en la cabeza de las personas. Cuando esas personas se van, ese conocimiento se va con ellas y los sistemas se vuelven más difíciles de entender y operar.
crisis_alert

Riesgo de lock-in

Las organizaciones pueden volverse dependientes de soluciones de normalización cerradas, específicas de vendor o de pago, difíciles de reemplazar o que quizá no se mantengan con una visión a largo plazo.

verified

Enfoque Open Standard de OSIRIS JSON

verified

Schema de intercambio JSON neutral

Un formato vendor-neutral para intercambiar recursos de infraestructura y topología entre sistemas.
verified

Los producers traducen exportaciones de source en documentos OSIRIS

Parsers/translators/discovery agents mapean representaciones nativas al schema OSIRIS.
verified

Los consumers implementan un schema para muchas fuentes

Las herramientas pueden leer un único formato de documento bien definido en distintos entornos.
verified

Relaciones de topología explícitas y de primera clase

Connections, dependencias, contención y agrupación se representan directamente para que un snapshot pueda describir qué existe y cómo se relaciona en un momento dado.
verified

Compatibilidad futura mediante la omisión segura de campos desconocidos

Los consumers pueden ignorar propiedades y extensions desconocidas sin romper el procesamiento básico.
verified

Las extensions están soportadas de forma nativa

Un mecanismo definido permite a vendors y usuarios enriquecer documentos sin romper la interoperabilidad.

Capacidades principales

schema Diseño unificado

Diseñado para entornos IT heterogéneos, con una ruta clara de extensión para OT y otros dominios a medida que crece la adopción.

hub Modelo explícito de relaciones

Representación de primera clase de connections, dependencias, contención y otras relaciones de topología.

account_tree Constructos de agrupación

Soporte para agrupación lógica y física que refleja estructuras organizativas y arquitectónicas reales sin forzar una taxonomía única.

dns Atribución del provider

Los recursos conservan la trazabilidad hasta su sistema/provider de origen mientras usan una representación estandarizada y vendor-neutral.

extension Extensibilidad

Un mecanismo definido para propiedades específicas de vendor y custom resource types sin romper la compatibilidad.

verified_user Validación de tres niveles

Validación estructural (schema), semántica y de dominio que mejora la consistencia y la calidad de los datos cuando se aplica tooling de validación.

Principios de diseño

Formato de snapshot estático

OSIRIS JSON es un formato de intercambio de snapshots estáticos. Captura qué existe y cómo se relaciona en un momento dado. No fue diseñado como un sistema de monitorización en tiempo real, una herramienta de despliegue ni un motor de Infrastructure-as-Code.

Qué NO es OSIRIS JSON

close No es telemetría ni monitorización en tiempo real

OSIRIS JSON describe el estado de la topología y del inventario, no métricas de series temporales, logs ni datos de observabilidad. Proyectos como Prometheus, Grafana, Zabbix y OpenTelemetry cubren las necesidades de telemetría.

close No es despliegue ni orquestación de infraestructura

OSIRIS JSON no es un lenguaje infrastructure-as-code ni una especificación de despliegue. Proyectos como Terraform, CloudFormation o TOSCA Oasis cubren los flujos de despliegue.

close No es gestión de configuración

OSIRIS JSON no define ni impone una configuración desired state para los recursos. Sistemas de gestión de configuración como Ansible, Puppet, Chef y Salt cumplen ese propósito.

close No es seguimiento de cambios ni historial

OSIRIS JSON representa un snapshot puntual. El seguimiento de cambios a lo largo del tiempo es responsabilidad de los sistemas producers y consumers.

close No es autenticación, autorización ni políticas de acceso

OSIRIS JSON puede transportar metadata que describa límites o ownership, pero no define mecanismos ni políticas de control de acceso.

close Información de costes y facturación

La facturación detallada y el modelado financiero quedan fuera del alcance del core schema, aunque metadata relacionada con costes puede incluirse mediante extension.

Estructura del documento

Los documentos OSIRIS son objetos JSON. En la Specification v1.0.0, el objeto de nivel superior se define en torno a tres campos: version, metadata y topology. Se puede incluir un campo $schema opcional para referenciar el schema URI.

[!NOTE] Este es un esquema de alto nivel del schema OSIRIS JSON. Los $defs se omiten aquí para facilitar la legibilidad del nivel superior; consulta el URI canónico para ver el schema completo.

El core schema de OSIRIS JSON define:

{
  "$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

Entidades de infraestructura identificables de forma única con propiedades y atribución del provider.

topology.connections

Relaciones explícitas y dirección entre recursos (network, dependency, containment, data flow, etc.).

topology.groups

Colecciones lógicas o físicas que organizan recursos (por ejemplo, VPC, subnet, rack, data center).

Validación e interoperabilidad