Cada vez que tengo que tocar directamente la consola de AWS, Firebase o cualquier panel de un hyperscaler, me invade la misma sensación: estoy manipulando algo frágil. Algo que dentro de unos meses no recordaré cómo monté. Algo que, aunque documente con capturas de pantalla, podría no poder reproducir si la interfaz cambia.
Esa sensación no es paranoia. Es una señal de que estoy creando infraestructura snowflake: un sistema único, irrepetible, que depende de mi memoria y de circunstancias concretas que no volverán a darse.
En el post sobre el principio RPS introduje piedra, papel y tijeras como tres formas de tomar decisiones técnicas. Este post aplica ese marco a la infraestructura: snowflake como falsa piedra, IaC mal adoptada como falsa papel, IaC suficiente como papel auténtico —y, en un extremo aparte, IaC ambiciosa como tijeras.
Qué es un snowflake
En ops, un snowflake (copo de nieve) es un servidor, un entorno o una configuración tan particular que no puede reproducirse de forma fiable. No hay dos iguales. Cada uno es único, como un copo de nieve.
Suele asociarse a la consola de AWS: años de clickops, recursos creados a mano, reglas de seguridad que «alguien añadió en su día» y nadie se atreve a tocar. Pero el problema es más amplio.
No es solo la consola de AWS
Cualquier hyperscaler con interfaz gráfica puede generar snowflakes:
- AWS Console — el caso más famoso.
- Firebase / Google Cloud Console — wizards que dejan una estructura difícil de replicar paso a paso.
- Azure Portal, Oracle Cloud, y el resto — mismo patrón: clics sin fuente de verdad versionada.
Si montaste un proyecto en Firebase usando la interfaz gráfica y mañana tienes que levantarlo de cero, ¿podrías reproducir exactamente la misma estructura? ¿Con los mismos permisos, las mismas reglas, los mismos servicios auxiliares? La duda ya es síntoma.
Tampoco hace falta interfaz gráfica
El snowflake no requiere wizards ni paneles web. Basta con SSH a un VPS e ir instalando cosas a golpe de apt o dnf, ajustando firewalls, editando ficheros de configuración, reiniciando servicios… hasta que el sistema funciona y nadie sabe ya qué pieza sostiene qué.
Me ha pasado en máquinas virtuales: tantos retoques manuales relacionados con el firewall, con permisos o con servicios auxiliares, que ante un problema acabo tirando de backup en lugar de intentar reproducir el sistema. Porque no confío en poder levantarlo de nuevo a mano, ni yo ni nadie del equipo.
En esos momentos he lamentado no haber usado herramientas de IaC desde el principio.
Falsa piedra
En el principio RPS, piedra es pragmatismo consciente: resolver rápido, asumiendo que el coste de equivocarse un poco es bajo y que la decisión es reversible.
La falsa piedra parece piedra, pero no lo es. Es hacer las cosas de una forma concreta porque «así se ha hecho siempre» o «así lo hace todo el mundo». Es el exceso de confianza de pensar que somos más listos de lo que realmente somos: que recordaremos perfectamente ese setup en la consola de AWS, que las capturas de pantalla bastarán, que «ya lo documentaré».
La falsa piedra acumula deuda técnica operativa: no la deuda del código mal diseñado, sino la deuda de un sistema que solo existe en una versión concreta, en una cabeza concreta, en un momento concreto.
No es que piedra sea mala. Es que confundimos velocidad aparente con pragmatismo real. La piedra auténtica asume limitaciones; la falsa piedra las ignora.
Un modo de operar, no un tipo de hosting
En el post RPS mencioné que VPS, cloud y bare metal pueden mapearse a piedra, papel y tijeras. Pero el snowflake no es un cuarto tipo de infraestructura. Es una forma de gestionarla:
- Un VPS puede ser piedra limpia (script reproducible, imagen base estándar) o un snowflake (años sin reiniciar, configuración artesanal sin documentar).
- Un cloud puede ser papel (IaC, políticas, auditoría) o un snowflake (consola, clics, excepciones «temporales» que nunca se eliminan).
El error no es elegir VPS o cloud. Es cómo lo configuras: sin fuente de verdad, sin idempotencia, sin asumir que los desastres suceden.
Dónde importa y dónde no
No todo snowflake es un crimen. Hay contextos donde tiene sentido:
- Prototipos desechables con vida corta y presupuesto de destrucción.
- Homelabs pensados para experimentar y romper cosas — ahí la fragilidad puede ser parte del aprendizaje.
Pero hay contextos donde duele:
- Cuando hay dinero en juego — costes de downtime, SLA, clientes.
- Cuando el sistema no se puede permitir depender de una persona — conocimiento tribal, vacaciones, rotación de equipo.
- Cuando un desastre exige levantar todo desde cero y no hay un manual para dummies ni automatización que lo haga sin demandar el 100% de tu atención.
La pregunta no es «¿snowflake sí o no?». Es «¿puedo permitírmelo en este contexto?».
IaC en el principio RPS
La IaC (Infrastructure as Code) describe infraestructura en ficheros versionados — Terraform, OpenTofu, Pulumi, Ansible — en lugar de depender de clics o de memoria. Es el camino natural para salir del snowflake. Pero en RPS no es automáticamente «la respuesta correcta».
Falsa papel: IaC mal adoptada
La trampa simétrica a la falsa piedra es la falsa papel: parece ingeniería seria, pero no lo es. Adoptas Terraform u OpenTofu porque «es lo profesional», pero sin estado remoto, sin flujo de revisión, sin entender el modelo declarativo. El apply lo hace una persona en local; los módulos los copió alguien hace meses y nadie los entiende.
Crees que has dejado atrás el snowflake. En realidad has cambiado un snowflake manual por un snowflake con ficheros .tf encima: otra fragilidad, con más complejidad de por medio.
Papel: IaC suficiente
Cuando IaC se hace con disciplina —versionado, revisión, estado compartido, entornos reproducibles— se convierte en papel auténtico: pagas trabajo inicial a cambio de estabilidad, previsibilidad y control del riesgo. Tienes un manual para dummies — o mejor aún, un pipeline que levanta el entorno sin que tengas que recordar cada paso.
Aceptas tus limitaciones humanas: no vas a acordarte de todo dentro de seis meses, y no pasa nada, porque la fuente de verdad está en el repositorio.
Tijeras: IaC ambiciosa
Hay un tercer escenario, distinto de la falsa papel y del papel suficiente: IaC ambiciosa a propósito. Multi-entorno, módulos compartidos, policy-as-code, plataformas internas, bare metal autogestionado. Es tijeras en el sentido RPS: máximo potencial a largo plazo, más complejidad, más riesgo — pero elegido conscientemente cuando el contexto (escala, equipo, compliance) lo justifica. No es el siguiente paso natural tras escapar del snowflake; es una apuesta distinta.
Herramientas (mención, no tutorial)
No voy a entrar en detalle ahora — habrá posts para eso — pero sí quiero nombrar el ecosistema:
- OpenTofu — fork open source de Terraform, tras el cambio de licencia de HashiCorp. Mi recomendación como base declarativa.
- Terraform — el estándar de facto; conviene conocerlo, pero hoy miraría primero OpenTofu para proyectos nuevos.
- Pulumi — permite describir infraestructura con lenguajes imperativos (TypeScript, Python, Go…). Interesante si vienes de scripts manuales y te cuesta el HCL declarativo.
- Ansible — orientado a configuración de sistemas ya existentes; complementa bien a OpenTofu/Pulumi (provisión + configuración).
Todas son puentes en el sentido RPS: reducen el coste de recuperarte después. Ninguna es bala de plata; todas exigen disciplina (versionado, revisión, pruebas).
Elegir con consciencia
No escribo esto para demonizar la consola ni para decir que todo debe ser IaC desde el día uno. Escribo para nombrar la sensación — esa fragilidad al tocar algo que no controlas del todo — y para situarla en un marco que ayude a decidir.
A veces la falsa piedra basta: un MVP, un entorno personal, una prueba que mañana tirarás. A veces no: producción, datos de clientes, sistemas que deben sobrevivir a tu memoria.
La habilidad no está en evitar siempre el snowflake. Está en saber cuándo lo estás creando, qué estás sacrificando, y si el contexto lo permite. Y en aceptar que, cuando no lo permita, necesitas un manual para dummies — o la automatización que lo haga innecesario.