Cada pocos meses aparece una nueva lista de herramientas “imprescindibles” para plataformas. Casi siempre está ordenada por tendencias de popularidad y casi nunca explica el criterio operativo: para qué problema sirve, con qué equipo se mantiene y a qué coste a medio plazo. Este no es ese tipo de lista.

Lo que sigue es el stack con el que trabajo de forma cómoda y robusta, junto con las razones de peso por las que cada pieza ocupa ese lugar. No pretende ser una recomendación universal, sino una guía de diseño basada en una pregunta invariable: ¿cuánto coste operativo añade esta herramienta y qué fricción concreta me elimina?

Infraestructura: Terraform (u OpenTofu)

Para aprovisionar infraestructura en la nube busco un estado declarativo, auditable mediante pull requests y perfectamente reproducible en otra cuenta o entorno. Terraform sigue siendo el estándar con mayor ecosistema y documentación madura; OpenTofu se presenta como una alternativa sólida y abierta cuando las licencias importan.

Lo crítico no es la herramienta en sí, sino las normas de uso:

  • Módulos acotados, con una interfaz y variables de entrada muy claras.
  • Estados estrictamente separados por entorno y por dominio, evitando un monolito gigante de estado.
  • Planes de cambio revisados y validados antes de aplicar, sin excepciones.
  • Secretos estrictamente fuera del estado y del repositorio de código.

Como norma general: si el terraform plan no cabe cómodamente en una pantalla, probablemente el módulo esté intentando abarcar demasiadas responsabilidades.

Ejecución: Kubernetes cuando el problema real lo pide

Kubernetes no es la respuesta universal. Para cargas de trabajo pequeñas o aplicaciones con tráfico predecible y aislado, una plataforma de contenedores gestionada suele ser más barata y considerablemente más simple. Kubernetes empieza a aportar valor real cuando confluyen múltiples equipos, necesidades de aislamiento estricto, patrones de despliegue complejos y una capa de plataforma centralizada que evita que cada departamento reinvente la rueda.

Cuando lo despliego, intento que el clúster sea lo más aburrido posible: pocas extensiones de terceros, versiones con soporte a largo plazo, políticas claras y una ruta de actualización limpia y predecible. La creatividad en la capa base de infraestructura siempre se paga en futuras guardias.

Empaquetado y despliegue: Kustomize, Helm y Argo CD

Para configuraciones internas y parametrizaciones propias, Kustomize suele ser suficiente, más transparente y fácil de revisar en código. Helm cobra sentido cuando necesitas empaquetar aplicaciones para distribución externa o cuando consumes un chart oficial mantenido por terceros que no tiene sentido reescribir desde cero. Mezclar ambos sin criterio genera plantillas opacas que nadie comprende.

Para el despliegue continuo utilizo GitOps apoyado en Argo CD: el estado deseado reside en Git, el clúster se reconcilia de forma autónoma y cualquier modificación queda perfectamente trazada. La gran ventaja no es la magia del botón de sincronización, sino que el proceso de revisión, auditoría y rollback es exactamente el mismo que el del código de la aplicación.

Observabilidad: métricas, trazas y logs orientados a síntomas

La observabilidad real no consiste en acumular paneles coloridos (dashboards), sino en tener la capacidad de responder a preguntas críticas que ni siquiera habías previsto durante el diseño inicial. En la práctica, esto se traduce en:

  • Métricas orientadas a SLOs y SLIs, evitando la alta cardinalidad innecesaria.
  • Trazas distribuidas para entender con precisión milimétrica dónde se pierde el tiempo en una petición.
  • Logs estructurados, enriquecidos con contexto y libres de fugas de datos sensibles.
  • Alertas enfocadas en síntomas que afectan al usuario, nunca en métricas internas arbitrarias que nadie sabe cómo accionar a las tres de la mañana.

OpenTelemetry como estándar de instrumentación unificada junto a Prometheus y Grafana es la combinación ideal. El objetivo es desterrar los paneles huérfanos que nadie mira y las alertas ruidosas que terminan silenciadas por costumbre.

CI/CD: el pipeline tratado como un producto

El pipeline de integración y entrega continua es una pieza central de la plataforma. Debe ser rápido, determinista y fácil de extender. Prefiero un conjunto reducido de pipelines genéricos y bien mantenidos antes que una proliferación descontrolada de scripts personalizados por cada repositorio. La lógica reutilizable debe vivir en plantillas compartidas, no copiada y pegada.

Un pipeline saludable tarda minutos en ejecutarse, no horas; falla por motivos comprensibles y no exige bucear entre miles de líneas de logs del runner para averiguar qué ha roto la compilación.

Seguridad y secretos

La seguridad jamás puede ser un control de última hora añadido al final de la cadena. Los secretos deben residir en un gestor dedicado, con políticas de rotación periódica y privilegios mínimos. Las imágenes se escanean de forma sistemática y las políticas de admisión se aplican mediante controles automáticos en el clúster, no confiando en manuales de buenas prácticas que nadie lee.

La regla de oro: si una medida de seguridad depende de que un humano se acuerde de aplicarla, deja de ser un protocolo y se convierte en una simple buena intención.

Lo que dejo fuera a propósito

Evito incorporar herramientas únicamente por el impulso de la moda tecnológica. Si un componente no resuelve una fricción real que sufro hoy, no entra en la arquitectura. Y si entra pero deja de usarse, se elimina sin miramientos. El stack más eficiente y productivo no es el más extenso, sino el que el equipo es capaz de operar con autonomía y sin dependencia de una única persona.

Ese es el criterio fundamental. Las herramientas concretas evolucionan con los años; la exigencia sobre el rigor operativo, nunca.