Existe un chiste nerd, de esos bien de nicho, que enumera las tres cosas más difíciles en la ciencia de la computación: Definir el TTL (Time-To-Live) para la invalidación de caché, nombrar las cosas y saber si un array empieza en 0 o en 1. Ok, el chiste puede ser “poco gracioso” para algunos, pero toca una verdad profunda de nuestro día a día. En este post, vamos a sumergirnos en la segunda dificultad: el desafío de dar nombres significativos y consistentes a variables, recursos y componentes de software.

En el desarrollo moderno, especialmente en la creación de automatizaciones y arquitecturas de microservicios, lidiamos con un ecosistema complejo: múltiples herramientas, cada una con sus convenciones, y variables que transitan por diversos scripts, entornos y sistemas. La falta de estandarización se transforma rápidamente en deuda técnica y confusión operacional. Considera el siguiente escenario de ejemplo para un nuevo Content Management System (CMS):

• 08 repositorios
• 08 microservicios
• 08 builds
• 02 bases de datos
• 05 colas de mensajes
• 01 API Gateway externo
• 03 entornos de despliegue: DEV, QA, PROD

Hagamos una cuenta rápida del mínimo de ítems únicos que necesitan un nombre/identificador (y que serán replicados por los entornos):

$$ (( 08 microservicios + 02 Bases de datos + 05 Colas + 01 API gateway ) \times 3 Entornos) + 08 Repos* + 08 builds* ) $$ $$ (( 8 + 2 + 5 + 1) ×3) + 8 + 8 $$ $$ 48+8+8 = 64 $$

(*) Los repos y los nombres de los artefactos de builds no se repiten, en este caso simplificado.

Estamos hablando de 64 nombres únicos como mínimo, y eso sin contar las variables de entorno para almacenar contraseñas, llaves y otros artefactos que también necesitan una nomenclatura consistente. ¿Logras percibir el valor de la estandarización? ¿Alguna vez te pusiste a pensar en cuánto más simple sería tu trabajo si todo siguiera un modelo consistente?

Tener estándares no es burocracia, es tener eficiencia y claridad. Sin eso, los problemas aparecen en la gestión de la evolución del proyecto en los siguientes momentos:

• El debug se convierte en arqueología de código Pierdes horas buscando una variable llamada nomeServidor_v2 en un entorno y servidor-nome-prod en otro. Lo que debería ser un debug rápido se vuelve una excavación en busca de lógica perdida.

• El riesgo de error aumenta Cuando cada persona adopta su propia convención, la probabilidad de un error de tipeo o de una referencia incorrecta durante un deploy crece exponencialmente. Es el tipo de falla que nadie quiere descubrir en producción.

• La productividad se desploma y la colaboración se evapora Sin un estándar, los proyectos se convierten en “feudos” donde solo el autor entiende lo que está pasando. Un nuevo miembro del equipo tarda días — a veces semanas — en entender la estructura del código.

• El mantenimiento se convierte en una pesadilla Lo que debería ser un código de IaC limpio y reutilizable se vuelve un laberinto de scripts rotos y nombres confusos. Cada nueva feature exige refactorizaciones caras y demoradas.

Sin estandarización, no hay escalabilidad. Si queremos pipelines robustos, código legible y colaboración real, necesitamos estándares, especialmente en aquello que parece más trivial: la nomenclatura. Definir convenciones claras para nombres de variables, recursos, archivos y etapas de pipeline transforma un amontonamiento de scripts en un sistema cohesivo, previsible e idempotente. Al final, es eso lo que separa una automatización frágil de una infraestructura más confiable.

Principales estándares de nomenclatura

La estandarización no se resume solo a definir qué nombrar, sino también el formato a utilizar. Existen cuatro estilos de nomenclatura clásicos y ampliamente aceptados en el universo de la Tecnología de la Información. Saber cuándo aplicar cada uno de ellos es crucial para la legibilidad del código y la interoperabilidad de la arquitectura:

Camel case (camelCase)

Este formato utiliza la primera palabra en minúscula y cada palabra subsiguiente comenzando con una letra mayúscula. Es ideal para mantener nombres compactos y legibles.

Dónde es común: Variables, parámetros de función y propiedades en lenguajes como JavaScript, TypeScript, Go, y también en la serialización de datos (ej: JSON).

Por qué usarlo: Es el estándar de facto para variables en muchos lenguajes front-end y back-end, promoviendo claridad en el contexto del código.

Ejemplos: instanceType, userName, maxRetries.

Snake case (snake_case)

En este estilo, todas las palabras se escriben en minúscula y separadas por guiones bajos (_).

Dónde es común: Lenguajes como Python y Ruby, variables de entorno, estructuras de automatización como Terraform y Ansible, y archivos de configuración (ej: YAML).

Por qué usarlo: Es un estándar altamente legible para nombres largos y es históricamente preferido en sistemas Unix-like, además de ser excelente para scripts de shell y automatización.

Ejemplos: instance_type, user_name, max_retries.

Pascal case (PascalCase)

Semejante al Camel Case, pero todas las palabras — incluyendo la primera — inician con letra mayúscula.

Dónde es común: Nombres de Clases, Tipos y Módulos en lenguajes orientados a objetos, como C#, Java e incluso clases en Python.

Por qué usarlo: Permite que los desarrolladores distingan rápidamente los tipos definidos (clases) de las instancias (variables), lo cual es fundamental para la arquitectura de software.

Ejemplos: InstanceType, UserName, MaxRetries.

Kebab case (kebab-case)

El formato Kebab Case utiliza palabras en minúscula separadas por guiones (-).

Dónde es común: Nombres de Archivos, Directorios, recursos web (como URLs), nombres de plugins y en identificadores dentro de Kubernetes (como labels).

Por qué usarlo: Es el estándar más limpio y amigable para contextos de configuración (ej: YAML y JSON), además de ser fácilmente interpretado por navegadores y sistemas de archivos.

Ejemplos: instance-type, user-name, max-retries.

El estándar de variables en herramientas de IaC/DevOps

Terraform

Terraform adopta el estándar snake_case para variables y recursos.

variable "instance_type" { 
	description = "Tipo da instância EC2" 
	type = string 
	default = "t3.medium" 
} 
resource "aws_instance" "web_server" { 
	ami = "ami-123456" 
	instance_type = var.instance_type 
}

Ansible

Ansible también sigue el snake_case. Esto vale para variables, playbooks y roles.

vars:
  app_port: 8080
  db_host: "database.internal"
  max_connections: 100

Kubernetes

En Kubernetes, los nombres siguen el estándar kebab-case para objetos y snake_case o camelCase para llaves internas de configuración (dependiendo del contexto). No se puede hablar mal de K8s porque es el consentido del universo, peeero podría tener un solo estándar, ¿no, jefe? Sí, pero hay una explicación ;).

• En el formato kebab-case

apiVersion: v1 
kind: Service 
metadata: 
	name: web-service 
spec: 
	selector: 
		app: web-server 
	ports: 
		- port: 80 
		  targetPort: 8080

• En el formato camel y snake

data: 
	max_retries: "5" 
	logLevel: "info"

CURIOSIDAD - ¿Alguna vez te preguntaste por qué Kubernetes utiliza el formato kebab-case (nombres con guiones, como my-service-api) para servicios, deployments y otros objetos? La razón es simple: dentro de Kubernetes existe un DNS interno. Cuando los objetos se crean, generan automáticamente registros de DNS para permitir la comunicación entre los componentes del clúster. El formato kebab-case es el más compatible con las reglas de nombres de dominio, garantizando que esos registros sean válidos y se resuelvan correctamente.

Conclusión

En el contexto de Infraestructura como Código (IaC), donde la infraestructura se trata como software, estandarizar y seguir convenciones de nomenclatura va mucho más allá de la estética: es un imperativo de ingeniería que se traduce directamente en eficiencia y ganancias de negocio.

Al adoptar y aplicar de forma consistente un estándar de nombres dependiendo de la herramienta, tu equipo empieza a percibir resultados inmediatos en los siguientes ítems:

• Desarrollo más rápido, con un código previsible e intuitivo, nadie pierde tiempo “descifrando” scripts antiguos. El foco vuelve a ser lo que realmente importa: nuevas features e innovación.

• Menos errores y más confiabilidad, la consistencia reduce las fallas de referencia en variables y recursos, garantizando idempotencia, estabilidad y deploys más seguros.

• Onboarding acelerado, los nuevos ingenieros entienden rápidamente el estándar y logran contribuir desde temprano. La colaboración fluye porque todos hablan la misma “lengua técnica”.

• Código más limpio y sostenible, un código IaC estandarizado es más fácil de mantener y evolucionar. Esto reduce la deuda técnica y permite que la infraestructura escale con previsibilidad y seguridad.

Al final de cuentas, el veredicto es simple: tener disciplina en la nomenclatura es una de las inversiones de menor costo y mayor retorno en un pipeline de DevOps. Es la base de cualquier proyecto de IaC que busca escala, consistencia y excelencia operacional.

¡Un abrazo!

¡Larga y próspera vida a todos!

Referencias

• https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
• Terraform Language - Variables
• Ansible Documentation - Variables
• Kubernetes Documentation - Environment Variables
• GitLab CI/CD - Predefined variables reference
• Azure Pipelines - Define variables

Entre em contato: