Depender de la nube de otro: lo que aprendimos operando en una sola máquina
*The Economist* publicó la semana pasada un análisis sobre los llamados *neoclouds* — proveedores como CoreWeave que alquilan capacidad de GPU — señalando que se están haciendo mucho más grandes y también más arriesgados. En paralelo, el CEO de Iren, socio de Nvidia, sostiene que la demanda de cómputo puede no saciarse nunca.
Las dos afirmaciones son compatibles y esa es justamente la parte incómoda: una demanda insaciable financiada con deuda es exactamente la forma que tiene un ciclo antes de corregirse. No sabemos si corregirá ni cuándo. Lo que sí sabemos es qué preguntas nos hacemos nosotros, que estamos varios pisos por debajo de esa conversación.
Dónde estamos nosotros
Vamos a ser concretos, porque el consejo genérico sobre nubes no sirve de nada. Nuestra web corporativa y varios de nuestros servicios corren en una sola máquina de un proveedor europeo: un servidor con 8 GB de RAM, con nginx delante y los procesos gestionados por PM2.
No es una postura ideológica ni una recomendación universal. Es una decisión de tamaño: para la carga que tenemos, una máquina bien mantenida cuesta un orden de magnitud menos que la arquitectura gestionada equivalente, y el modo de fallo es uno que entendemos entero.
La contrapartida es real y conviene decirla en voz alta: si esa máquina cae, cae todo lo que hay encima. Lo asumimos porque el coste de esa caída, para nuestro perfil de servicio, es menor que el coste permanente de la alternativa. Ese cálculo cambia el día que un cliente firma un acuerdo de nivel de servicio, y ese día habrá que cambiar la arquitectura, no la excusa.
La pregunta útil no es «qué proveedor»
Cuando alguien pregunta qué nube elegir, casi siempre está haciendo la pregunta pequeña. La grande es: ¿cuánto me cuesta cambiar de opinión dentro de dos años?
Esa cifra no aparece en ninguna factura, pero se puede estimar mirando tres cosas:
- Cuántos servicios propietarios has cableado. Una base de datos gestionada estándar se migra. Un producto de colas específico de un proveedor, con su semántica particular, es código que hay que reescribir.
- Dónde vive el estado. Los datos son lo pesado. Mover 200 GB entre nubes es caro en tránsito y lento en ventana de mantenimiento; mover el cómputo es casi gratis en comparación.
- Cuánto de tu despliegue es específico del proveedor. Si tu infraestructura como código solo describe un proveedor, no tienes infraestructura como código: tienes ese proveedor escrito de otra forma.
Ninguna de las tres exige irse a la nube más barata ni evitar los servicios gestionados. Exigen saber el número. Un compromiso que conoces es una decisión; uno que no conoces es una apuesta.
El riesgo que nadie modela: la contraparte
Lo que el artículo de *The Economist* añade es un riesgo que la mayoría de equipos técnicos no tiene en su hoja de cálculo: el financiero de tu proveedor. Estamos acostumbrados a modelar caídas, latencia y regiones. No estamos acostumbrados a preguntarnos si quien nos alquila las GPU podrá refinanciar su deuda.
Con los grandes esa pregunta es casi retórica. Con proveedores especializados que crecen rápido apalancados en hardware, no lo es. Y la consecuencia práctica es la misma que con cualquier proveedor crítico: no es que haya que evitarlos, es que hay que saber qué pasa contigo si desaparecen.
Un proveedor del que no puedes salir no es un proveedor: es un socio que no elegiste.
Lo que falla de verdad no es la máquina
Después de un tiempo operando así, la lista de incidentes reales no se parece a la que uno imagina antes de empezar. La máquina casi nunca es el problema. El hardware de un proveedor serio aguanta; lo que falla es lo que hay alrededor.
- Certificados que caducan. Es la causa número uno de caída percibida en instalaciones pequeñas, y es cien por cien evitable con renovación automática y una alerta que avise antes, no después.
- Despliegues que se pisan. Compilar encima del directorio que el servidor está sirviendo produce errores intermitentes durante el despliegue, en una ruta distinta cada vez. Es el fallo más difícil de ver porque desaparece solo.
- Secretos que se borran en silencio. Una sincronización de ficheros mal acotada puede llevarse las variables de entorno de producción sin que nada falle en el momento. Lo descubres cuando un formulario deja de entregar.
- Disco lleno. Poco glamuroso y sorprendentemente frecuente: registros que nadie rota, copias que nadie caduca.
Los cuatro son problemas de proceso, no de arquitectura. Migrar a una nube gestionada no resuelve ninguno automáticamente: los cambia de forma. Y ese es el argumento honesto a favor de empezar simple — una arquitectura que entiendes entera te enseña qué falla de verdad en tu caso antes de que pagues por evitar lo que creías que iba a fallar.
Lo que hacemos, en concreto
Nuestro criterio se resume en tres reglas nada heroicas. La primera: el estado se guarda en formatos estándar. Bases de datos y ficheros que se pueden volcar y restaurar en otro sitio sin traductor de por medio.
La segunda: el despliegue está escrito. Nuestro despliegue es un script en el repositorio, no una secuencia que alguien recuerda. Eso empezó como higiene y acabó siendo lo que nos dejó cambiar cosas sin miedo — incluida la corrección de un fallo que llevaba semanas sirviendo errores durante cada despliegue sin que nadie lo notara.
Y la tercera: se prueba la restauración, no la copia. Una copia de seguridad que nadie ha restaurado nunca es una carpeta con esperanza dentro.
Si estás decidiendo si esto lo montas tú o lo externalizas, el marco que usamos está en empresa de software vs freelance vs equipo interno. La respuesta depende de qué parte del riesgo puedes absorber, no de qué opción es «mejor».
