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 donde aplique.

Como schema de intercambio, OSIRIS JSON normaliza exportaciones de fuentes diversas y permite un consumo portable por herramientas dedicadas a diagramación, documentación, workflows 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 consumidoras. 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 a documentos OSIRIS JSON.
CONSUMERS (herramientas de diagramación, CMDBs, IPAMs, DCIMs, pipelines de documentación) leen y procesan un schema único y bien definido.

Esto desacopla las fuentes de datos de las aplicaciones consumidoras, 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 consumidoras, 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 reto

Los datos de infraestructura se exponen mediante formatos y modelos específicos de vendor, con semánticas inconsistentes para conceptos equivalentes de identidad, propiedades, relaciones y jerarquía. En entornos mixtos que abarcan hyperscalers, public cloud, sistemas on-prem e infraestructura OT, el problema se multiplica. El resultado es tooling fragmentado y a veces de alto costo, 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 costo de mantenimiento

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

Semántica de topología inconsistente

Las relaciones pueden ser implícitas, incompletas o 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 deficiente y los diagramas suelen ser de baja calidad, con íconos 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 las 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, que son difíciles de reemplazar o que quizá no se mantengan con una visión de 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 a 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 formato de documento único y bien definido en diferentes entornos.
verified

Relaciones topológicas 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 específico.
verified

Compatibilidad futura mediante la omisión segura de campos desconocidos

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

Las extensiones tienen soporte nativo

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 de extensión clara para OT y otros dominios conforme crece la adopción.

hub Modelo explícito de relaciones

Representación de primera clase de connections, dependencias, contención y otras relaciones topológicas.

account_tree Constructos de agrupación

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

dns Atribución del provider

Los recursos preservan la trazabilidad hacia 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 específico. No fue diseñado como un sistema de monitoreo 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 monitoreo 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, OpenTelemetry abordan necesidades de telemetría.

close No es despliegue y 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 abordan workflows de despliegue.

close No es gestión de configuración

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

close No es seguimiento de cambios ni historial

OSIRIS JSON representa un snapshot de un momento específico. El seguimiento de cambios a lo largo del tiempo es responsabilidad de los sistemas productores y consumidores.

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

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

close Información de costos y facturación

La facturación detallada y el modelado financiero están fuera del alcance del core schema, aunque metadata relacionada con costos puede incluirse por extension.

Estructura del documento

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

[!NOTE] Este es un esquema de alto nivel del schema OSIRIS JSON. Aquí se omiten los $defs 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 (e.g. VPC, subnet, rack, data center).

Validación e interoperabilidad