Configuración como datos

(Sección: Arquitectura y Protocolos)

1) Idea y diferencia de «configuración como código»

La configuración como datos (Configuration as Data, CaD) es una representación de la configuración como un modelo tipificado, declarativo, validable, independiente del código ejecutable y administrado como datos empresariales: con versiones, esquemas, migraciones, auditorías y pruebas.
A diferencia de la «configuración como código», donde la lógica de generación de configuraciones vive en patrones/scripts, CaD elimina el imperativo de la fuente de la verdad: sin bucles, condiciones y lógica oculta dentro de las configuraciones. Todos son datos puros + esquema estricto + políticas.

Objetivos clave: previsibilidad, capacidad de diff, seguridad de cambio, retrocesos rápidos, capacidad de entrega progresiva y control automático de cumplimiento.

2) Principios de «confección como datos»

1. Declaratividad e inequívocos: describimos el estado deseado, no los pasos de logro.
2. Seguridad y esquemas: JSON Schema/Protobuf/Avro/OpenAPI para contratos estrictos.
3. Inmutabilidad del artefacto: se versionan y firman las instantáneas (provenance).
4. Validación y política: en paipline, sintaxis → semántica → policy-as-code (OPA, reglas).
5. Observabilidad de las confecciones: impresión de la versión en logs/métricas/tracks.
6. División de la responsabilidad: datos (configuración), esquema (contrato), política (restricciones), controlador (implementación).
7. Modularidad y capas: niveles globales, regionales, tenantes-, de producto, de fiche, con un merge y prioridades predecibles.

3) Simulación de configuración: esquema como contrato

Las familias de entidades son: enrutamiento, límites, fichflags, tarifas, segmentos AB, cuotas, reglas de riesgo, configuraciones, etc.
Tipos: enum/oneOf explícitos, rangos, regex, integridad referencial (ref/ID).
Versionar esquemas: 'v1 → v1beta2 → v2' (deprecation-plan, migraciones).
Defaulting/Mutation: defectos seguros en la fase de validación; orden de aplicación determinista.
Constraint-s: restricciones empresariales (por ejemplo, 'rateLimit <= 2000 rps' en tenant).

yaml apiVersion: config. example. io/v1 kind: RateLimitPolicy metadata:
scope: tenant:acme spec:
targets:
- service: checkout endpoint: /api/pay method: POST limit:
unit: second value: 500 burst: 200 strategy: tokenBucket

4) Capas, herencia y resolución de conflictos

Иерархия: `global → region → environment → tenant → product → cohort → user`.
Reglas del merge: declarativo - «el último ganó» (override) o estratégico (merge/patch/replace per field).
Validación en las intersecciones: prohibimos las claves en conflicto, exigimos override explícito.
La visualización de la configuración effective final es obligatoria (diffs deterministas).

5) Ciclo de vida de configuración (paradigma GitOps)

1. Origen de la verdad: repositorio con datos + esquemas + políticas.

• validación de sintaxis (lint),
• validación por diagrama,
• comprobaciones/pruebas semánticas,
• policy-as-code (por ejemplo, OPA/Rego),
• migraciones seguras (véase § 7),
• firma y publicación.
• 3. Promoción: ring-0/.../ring-n' entre directorios 'dev/qa/staging/prod' o anillos' ring-0/.../ring-N'.
• 4. Entrega: los controladores/operadores aprietan los snapshots frescos, aplican a través de un ciclo reconcible.
• 5. Auditoría y reversibilidad: todos los cambios se rastrean; retroceso - revert commit/rollback snapshot.

6) Entrega y distribución de confecciones

Estática (pull-on-start): envíe el snapshot al inicio, reinicie para la actualización.
Dinámico (watch/stream): etcd/Consul/ZooKeeper, Kubernetes API/CRD, servicio propio de Config.
Protocolos: gRPC/NAT con ETag/If-None-Match, long-poll/watch, snapshots + diffs incrementales.
Almacenamiento en caché: snapshots locales con TTL y firma; cambio atómico (doble amortiguación).
Secuencia: strong (leader/quórum) vs eventual (edge/IoT). Para sistemas críticos, quórum + RA.
Ranuras globales: por regiones/anillos (ring-deploy), con un límite de zones simultáneos.

7) Migraciones de datos de configuración

• Expand: introduzca nuevos campos con valores predeterminados sin romper los consumidores.
• Migrate: backfils/convertidores (scripts proveedores de migración, idempotencia).
• Contrato: eliminamos lo obsoleto cuando todos los controladores están en la nueva versión del esquema.
• Regla de compatibilidad: la vieja lógica entiende lo nuevo, lo nuevo, lo viejo en un período de transición.

8) Política, cumplimiento y seguridad

Policy-as-code: Rego/Conftest/OPA Gatekeeper - prohibiciones de valores peligrosos (por ejemplo, 'timeout = 0', desactivación de TLS, cuotas ilimitadas).
RBAC/ABAC: quién puede cambiar qué secciones y en qué capas.
Aprobación multilateral (cuatro ojos) para segmentos sensibles (pagos/límites).
Secretos: Almacenamos fuera de las configuraciones compartidas (KMS, Vault, SOPS), en la configuración - sólo referencias/referencias.
Firmas y confianza: verificación de suministros (attestations), prohibición de francotiradores sin firmar.
Saneamiento: protección contra inyección en plantillas y bajo renderizado.

9) Observabilidad, SLO y gestión de riesgos

Las etiquetas de configuración en telemetría son: '{config _ digest, config_version, ring, scope}' en logs/métricas/tries.
Golden-métricas de cañones de configuración: tiempo de aplicación, porcentaje de éxito, número de retrocesos, tiempo de consistencia.
Gates al rodar las configuraciones: como para el código - pasos canarios y auto-parada para la degradación de SLO.
Dogfooding: primero internal/beta-cohorta.

10) Hot-reload, la transaccionalidad y la seguridad de la aplicación

Conmutación atómica: la nueva configuración se prepara en memoria → una sola conmutación atómica.
Dry-run: validamos y simulamos la aplicación (incluyendo el conflicto de campos/políticas).
Falta parcial: la estrategia es «todo o nada» para los componentes relacionados o una descripción clara de las degradaciones.
Backoff/Retry: en caso de error de aplicación, retroceso y repetición seguros con retardo exponencial.

11) Fichflagi como un subconjunto de las confecciones

Los fichflags son datos de configuración con políticas especiales: segmentación por segmentos, restricciones de radio de encendido, kill-switch.
Requisitos: semántica determinista de segmentación, auditoría, impagos seguros, compatibilidad de versiones cliente/servidor.

12) Herramientas y medios

Medios: JSON/YAML/TOML/Protobuf/Avro (para entrega en red - más comúnmente Protobuf/JSON).
Renderizado/composición: Kustomize/Helm/Jsonnet (como generadores, pero el total son datos puros).
Almacenamiento/bus: Git, registros OCI (como artefactos), almacenamiento compatible con S3, etcd/Consul/KV.
Controladores: operadores propios, agentes GitOps, proveedores de configuración Sidecar.
Política: OPA/Rego, mecanismos similares a Kyverno.

13) Hojas de cheques

Diseño

• Esquema en primer lugar (JSON Schema/Proto), se describen los tipos/restricciones/impagos.
• Se han documentado las migraciones y versionaciones de esquemas.
• La jerarquía de capas y la estrategia del merge están definidas y probadas.

Pipeline

• Lint → schema-validate → semantic tests → policy-check → sign → publish.
• Dry-run y la visualización de la configuración efectiva para los revisores.
• Ranura canaria de confecciones con autogates por SLO.

Pro

• Hay 'config _ digest' en los logs/métricas.
• Revertir la configuración con el mismo botón que el deplo de código.
• Los snapshots/backups de los decomisos y el historial de auditoría están disponibles y verificados.

14) Anti-patrones frecuentes

Imperativo en la configuración: las condiciones/scripts/plantillas con lógica son invisibles e impredecibles.
Mezcla de secretos y configuración compartida en un solo archivo/repositorio.
Valor opaco: no está claro de dónde proviene el valor final.
Falta de esquema: «vale todo» ⇒ errores en la venta.
Ediciones globales sin anillos/Canarias: degradación instantánea para todos.
Deriva de los alrededores: revisiones manuales en el rantime más allá de la fuente de la verdad.
Larga TTL en caché de config sin mecanismo de invalidez forzada.

15) Scripts (bocetos)

A. Ajuste fino de los límites de tráfico por región

1. PR con los cambios de 'RateLimitPolicy' a 'ring-0' (clientes internos).
2. Verificaciones automáticas: esquema/directiva (límite ≤ 2k rps).
3. Promoción en 'ring-1' (5% de los usuarios), monitoreo p95/error rate.
4. Extensión a 'ring-N', fijación de snapshot, cierre de tareas.

B. Actualización de la cuadrícula tarifaria (finificación)

fuerte semántica y política empresarial: doble revisión, promoción en dos pasos, tiempo-ventana de entrada, auditoría y posibilidad de retroceso instantáneo.

C. Global Fichflag de pagos con indicador de configuración con kill-switch: orientación «employees → beta → 10% → 100%», parada automática cuando la tasa de pago successful cae por debajo del umbral.

16) Integración con Zero-Downtime y entrega progresiva

Los configuradores canarios están sincronizados con los anillos de lanzamiento.
Compatibilidad de versiones: primero los campos de expansión, luego el código, luego los apretones.
Shadow-confites: cálculo paralelo de soluciones (por ejemplo, límite) para comparar con combate.

17) Resumen

El enfoque «configuración como datos» transforma la configuración de archivos frágiles a modelos de dominio confiables con contratos claros, validación y políticas. Esta es la base de las divisiones previsibles, los experimentos seguros y la respuesta rápida a los incidentes. Formalice los esquemas, separe los secretos, implemente GitOps y los cañones de configuración canarios, y la configuración dejará de ser un riesgo al convertirse en un activo gestionado de la plataforma.