El peor aliado interno de DevOps que prefieres que un SaaS lo reemplace
Un script que empezó como una solución rápida se convirtió en un monstruo de 4.000 líneas que consume tiempo y recursos, generando cero valor comercial.
El relato comienza con un ingeniero que, hace tres años, decidió que no valía la pena pagar $300 al mes por una herramienta y construyó un bash script junto a un Dockerfile y una GitHub Action de fin de semana.
Con el tiempo, el script se transformó en una mezcla de shell, Python y cronjobs sin control de versiones, con permisos de IAM sin registrar. Cuando el ingeniero dejó la empresa, el código quedó abandonado y el equipo quedó con un “helpdesk” no remunerado que necesita responder cada error de build.
La situación se complicó cuando AWS descontinuó una API que el script utilizaba, Terraform empezó a desviarse y el equipo se vio obligado a pasar la mitad del sprint depurando una herramienta que no aporta valor a la empresa.
El post de Reddit invita a los lectores a compartir su experiencia con herramientas internas de DevOps que se convirtieron en un dolor de cabeza. Se mencionan ejemplos comunes: entornos efímeros, pipelines de migración de bases de datos, sincronización de secretos o wrappers personalizados para ECS/EKS.
Se cuestiona por qué no se optó por soluciones de mercado: ¿fueron demasiado costosas? ¿Exigían claves raíz IAM? ¿Estaban sobre‑ingenierizadas o fallaban en casos extremos? Y, sobre todo, ¿qué requeriría de la empresa para que un SaaS lo sustituyera sin generar más costos?
Para los administradores de sistemas, arquitectos y responsables de infraestructura, la historia es una advertencia: las herramientas internas pueden escalar fuera de control y generar una carga operativa que eclipsa su valor. Evaluar la viabilidad de comprar o desarrollar una solución SaaS puede ahorrar tiempo, reducir la deuda técnica y mejorar la fiabilidad de los entornos.
La comunidad responde con relatos de herramientas que se convirtieron en “glue” de la infraestructura y que, a la larga, se convirtieron en un activo negativo.
La lección es clara: antes de construir una solución interna, verifica si existe un producto de mercado que cubra el caso de uso y que se integre con tu stack. Si el caso es único, documenta y versiona el código, establece controles de IAM y automatiza la depuración para evitar que el proyecto se convierta en un monstruo de mantenimiento.
El debate sigue abierto en Reddit, donde los usuarios comparten sus historias y soluciones.
