YAML ganó la configuración haciendo que la estructura pareciera notas

XML resolvió el intercambio, pero hizo que la configuración simple pareciera marcado de documentos. Los creadores de YAML partieron de la premisa opuesta: un archivo de datos debería parecerse a los datos, no a etiquetas que envuelven los datos.

La especificación 1.0 describía YAML como un lenguaje de serialización Unicode, multiplataforma y amigable para humanos, destinado a archivos de configuración, mensajería, persistencia y depuración. Su truco central era la estructura visual: sangría para el alcance, dos puntos para los pares y guiones para las listas.

Esa elección envejeció perfectamente en el mundo DevOps. YAML.org lo describe ahora como el estándar de facto para la configuración de infraestructura en herramientas como Kubernetes, Docker Compose y Terraform. La característica ganadora no fue la potencia; fue la facilidad de revisión.

Dejar que los datos se muestren por sí mismos

La sangría hizo que los datos anidados fueran escaneables sin etiquetas de cierre.

Las asignaciones, secuencias y escalares coincidían con las estructuras nativas de los lenguajes de scripting populares.

El texto plano hizo que las configuraciones fueran fáciles de comparar, revisar y pegar en la documentación.

El formato se mantuvo independiente del lenguaje, de modo que cada herramienta pudo adoptarlo sin ser su dueña.

Para los formatos editados a mano, la legibilidad no es decoración. El formato que las personas pueden revisar en una solicitud de extracción se convierte en el formato que los equipos estandarizan.

YAML se convirtió en un lenguaje de configuración predeterminado en las herramientas nativas de la nube y los sistemas de CI/CD. Su legibilidad permisiva también trajo trampas, pero la lógica de adopción se mantuvo: la infraestructura pasó a ser texto que los humanos podían editar.