Una plataforma para la aplicación que había y para las que venían

01El punto de partida

Todo vivía en una única máquina virtual: el servidor de aplicaciones, la base de datos y los archivos que suben los usuarios, los tres sobre el mismo disco. Cualquier fallo de hardware se llevaba las tres cosas a la vez. La configuración estaba escrita dentro de la aplicación y los cambios se habían hecho a mano, sin registro: si esa máquina se perdía, nadie podía rearmarla igual, había que reconstruirla probando. Y con una sola instancia, publicar una versión era apagar el servicio, así que se publicaba de noche, los domingos, o no se publicaba. Pero lo que decidió el presupuesto no fue nada de eso: era que no venía sola. Detrás había más aplicaciones, empezando por una web con su propia base, y cada una iba a repetir el patrón — otra máquina virtual, configurada a mano, con su propio disco único.

02Con qué no se podía negociar

• Un solo servidor físico: 30 GB de memoria y 16 núcleos para todo.
• El código de negocio no se reescribe. Solo cambia cómo se configura.
• Son datos reales: cero filas perdidas, sin excepciones.
• Lo que no esté declarado en el repositorio, no existe.

03La decisión

Una plataforma de contenedores sobre tres nodos, con la aplicación movida tal cual estaba: lo único que cambió es de dónde saca su configuración, de valores escritos en el código a variables de entorno. Se evaluó y se descartó la alternativa barata — dos máquinas con la base replicada y un balanceador adelante — y hay que decir que para una sola aplicación esa era la respuesta correcta: menos piezas, menos que aprender, menos formas de romperse. Un clúster para una aplicación es sobreingeniería. Se eligió la plataforma porque no era una aplicación, eran las que venían: el costo de montarla y aprenderla se paga una vez, y sumar la segunda es agregar un archivo al repositorio en lugar de repetir todo el trabajo, replicación de la base incluida. Además resolvía dos cosas que el esquema de dos máquinas deja a cargo de uno: los archivos, que necesitan lectura y escritura simultánea desde cualquier nodo y si no obligan a montar y mantener un servidor de archivos aparte; y la conmutación automática de la base con recuperación a un punto en el tiempo y respaldos declarados junto a la base, que de la otra forma son guiones propios que hay que escribir, probar y mantener. Son servidores propios y no había opción de alquilar un servicio gestionado, así que la alternativa real siempre fue armarlo uno mismo: la pregunta era cuánto de lo que se arma sirve para lo que sigue.

05Lo que salió mal

Durante el corte se apagó la aplicación vieja y se apagó su máquina virtual. Un reinicio del servidor físico, días después, la devolvió entera: la máquina tenía el arranque automático puesto en el hipervisor, un nivel más abajo de donde nadie había mirado. Volvió con la aplicación corriendo contra la base vieja, lista para aceptar escrituras que nadie iba a ver nunca. Se detectó comparando los conteos de filas de los dos entornos, todavía idénticos, así que no hubo divergencia. Se quitó el arranque automático de la máquina y se desactivó también la tarea programada nocturna de la aplicación. Apagar algo no es sacarlo de circulación, y en una migración el origen tiene tantas formas de volver como capas tenga debajo: el servicio, la máquina y el hipervisor son tres interruptores distintos.

06El resultado

El corte duró 20 minutos, con los conteos de filas verificados antes de congelar el origen y después de importar en el destino: idénticos. La aplicación quedó con dos réplicas, la base con tres copias y conmutación automática, y los archivos de los usuarios sobre almacenamiento accesible desde cualquier nodo. Toda la plataforma, incluido el motor que la despliega, está declarada en un repositorio, y las credenciales viajan cifradas dentro de ese mismo repositorio. Sumar la aplicación siguiente ya no es levantar otro servidor: es agregar un archivo. La máquina vieja no se dio de baja: quedó apagada y a mano, como salida por si el clúster falla. Queda un límite declarado desde el primer día: las tres máquinas corren sobre un único servidor físico, así que la alta disponibilidad es lógica y no física — cubre la caída de un nodo o de un disco, no la del servidor. El camino para cerrarlo es conocido: un segundo equipo y respaldos fuera del sitio. La regla general: un repositorio declarativo te devuelve la configuración, nunca los datos. Son dos problemas distintos, cada uno necesita su propia solución, y darlos por resueltos juntos es el error caro.