¿Por qué estamos plantillando YAML? (2019)

Artículo original ↗ Discusión en Hacker News ↗

Los ingenieros argumentan que el plantillado de YAML para infraestructura y configuraciones de Kubernetes se ha convertido en un antipatrón: archivos declarativos que antes eran simples han acumulado bucles, condicionales y DSLs específicos del proveedor, convirtiéndose en sistemas frágiles de “yaml-como-lenguaje-de-programación” que son difíciles de validar, depurar y asegurar. Muchos prefieren generar JSON/YAML desde lenguajes de programación reales (TypeScript, Python, Ruby) o desde lenguajes de configuración creados a propósito (Jsonnet, CUE, Dhall, Nix), a menudo combinados con herramientas como CDK, Pulumi o Tanka, para que la lógica viva en código probado mientras el clúster sigue recibiendo manifiestos simples. En el fondo hay una preocupación más amplia de que cada nuevo formato de configuración y motor de plantillas repite el mismo error: reinventar un lenguaje restringido en lugar de aprovechar los existentes y el tooling adecuado para tipos, esquemas y composición.

Por qué se usa YAML y luego se le aplican plantillas

  • Quienes comentan coinciden en que YAML domina en gran medida por inercia y familiaridad: hay ejemplos y herramientas por todas partes, especialmente en Kubernetes y CI.
  • La gente empieza con “solo un YAML simple”, luego añade unas pocas variables, después condicionales/bucles, y termina con un lenguaje de programación de facto.
  • Copiar y pegar fragmentos de la documentación y los blogs es una gran razón por la que la gente se aferra al YAML puro/plantillado en lugar de usar herramientas de nivel más alto.

Críticas al propio YAML

  • Muchos ven YAML como engañosamente “amigable para humanos”: la indentación es frágil, el contexto se pierde fácilmente en archivos largos y la especificación es compleja.
  • El sistema de tipos y las conversiones implícitas (p. ej. no → false / problema de “Norway”, diferencias entre 1.1 y 1.2) son quejas recurrentes.
  • El YAML con plantillas se describe como “programación tipada como cadenas”: difícil de validar, depurar y razonar, con semánticas específicas del proveedor.
  • Algunos defienden YAML para configuraciones de pequeña a mediana complejidad y para personas que no programan (p. ej. front-matter, simple docker-compose), especialmente con validación de esquemas y linters.

Plantillas frente a generación con lenguajes reales

  • Tendencia fuerte: dejar de inventar DSLs de plantillas a medio hacer; usar un lenguaje real (TypeScript, Python, Ruby, Go, etc.) para construir estructuras de datos y emitir JSON/YAML.
  • Beneficios citados: reutilización de bibliotecas y herramientas, verificación de tipos, pruebas unitarias, refactorización más fácil, separación más clara entre “datos tontos” y lógica.
  • Contraargumentos:
    • Permitir que lenguajes arbitrarios se ejecuten en CI/IaC aumenta la superficie de ataque y la complejidad.
    • La configuración debe ser declarativa y restringida; dar poder de Turing completo invita al spaghetti y dificulta las políticas/la validación.

Lenguajes/sistemas alternativos de configuración

  • Mencionados con frecuencia: Jsonnet, Dhall, CUE, Nix, Nickel, herramientas basadas en Starlark (ytt, Bazel/Starlark, Kurtosis), CDK8s, AWS CDK, Pulumi, Tanka, Kustomize.
  • Las opiniones divergen: a algunos les encantan Jsonnet/CUE/Nix/Dhall por su configuración funcional, total o segura por tipos; otros los encuentran demasiado de nicho, difíciles de aprender o carentes de bibliotecas.
  • Varios sugieren “configuración como código con tipos”, más un formato de datos simple y validado como artefacto compilado (a menudo JSON, opcionalmente renderizado a YAML).

Kubernetes, Helm, CI y operadores

  • Los charts de Helm se describen ampliamente como dolorosos: sustitución de texto, manejo de indentación, mensajes de error pobres y necesidad de volver a exponer características de Kubernetes mediante values.yaml.
  • Algunos prefieren Kustomize o manifiestos sin más; otros argumentan que los operadores o CDKs de nivel superior son una mejor abstracción que seguir añadiendo más plantillado YAML.
  • Para CI (GitHub Actions, etc.), muchos recomiendan YAML mínimo que solo haga exec de scripts reales, evitando lógica compleja en archivos de configuración.

Filosofía más profunda de la configuración

  • Tema recurrente: “toda configuración deriva hacia la completitud de Turing”.
  • El debate se centra en dónde debería vivir la lógica, cuánta potencia debería tener la configuración y cómo mantener los sistemas observables, testeables y mantenibles a medida que crece la complejidad.