Uno de los errores más habituales cuando se habla de modernización es pensar únicamente en tecnología. Se habla de Kubernetes, cloud, Terraform o automatización como si el simple hecho de incorporarlos solucionase los problemas existentes.
La realidad suele ser bastante distinta. La mayoría de problemas aparecen mucho antes: despliegues manuales, dependencia del estado del servidor, cambios sin trazabilidad, configuraciones inconsistentes, ausencia de rollback, entornos distintos entre sí y una operación completamente dependiente de conocimiento implícito.
Este proyecto nació precisamente en ese escenario. Una plataforma digital con bastante volumen de venta online, cambios constantes y una arquitectura que había ido creciendo de forma reactiva hasta empezar a generar fricción operativa seria.
La aplicación funcionaba sobre un servidor Windows donde los despliegues se realizaban manualmente mediante acceso remoto. Parte de los cambios se hacían directamente sobre producción y no existía una separación clara entre entornos.
El sistema estaba orientado a funcionalidad inmediata, pero no a mantenibilidad ni escalabilidad operativa.
Características iniciales: - Despliegues manuales vía RDP/SSH - Cambios directos sobre producción - Sin control de versiones estructurado - Sin entornos separados - Dependencia total del estado del servidor - Sin rollback claro - Configuración acoplada a infraestructura - Escalabilidad limitada - Cambios difíciles de auditar - Errores difíciles de reproducir
Mientras el ritmo de cambios era bajo, el modelo aguantaba. Pero a medida que aumentaba la frecuencia de modificaciones, campañas y necesidades de negocio, el sistema empezó a mostrar limitaciones claras.
Es importante entender algo: el problema no era el sistema operativo. El problema era el modelo operativo.
Cambiar a Linux, Kubernetes o cloud sin resolver eso solo habría movido los mismos problemas a otro sitio.
La primera fase consistió en rediseñar el ciclo de vida de la aplicación:
Objetivos iniciales: - Introducir trazabilidad - Eliminar despliegues manuales - Separar entornos - Reducir dependencia del servidor - Permitir rollback - Automatizar procesos repetitivos - Estandarizar despliegues - Preparar evolución futura
El primer cambio importante fue introducir Git como centro operativo del proyecto.
Hasta ese momento, parte del conocimiento estaba repartido entre servidores, scripts locales y cambios realizados directamente sobre producción.
Eso hacía imposible saber realmente:
- qué versión estaba desplegada - cuándo se cambió algo - quién lo modificó - cómo volver atrás - qué diferencias existían entre entornos
La incorporación de Git permitió empezar a trabajar sobre una base reproducible y trazable.
Otro problema importante era la inexistencia de entornos diferenciados.
Muchas incidencias nacían directamente de ahí:
"En mi máquina funciona" "En producción falla" "No sé qué versión hay desplegada"
Se introdujo separación explícita:
- Desarrollo - Preproducción - Producción
Cada entorno tenía configuración diferenciada y validaciones antes de promover cambios hacia producción.
Esto redujo muchísimo el riesgo operativo y permitió detectar errores antes de impactar directamente sobre cliente final.
La automatización pasó rápidamente a convertirse en el núcleo operativo del sistema.
Se implementó un pipeline CI/CD basado en Jenkins:
Stages principales: - Checkout - Build - Validación - Deploy preproducción - Validación funcional - Deploy producción
El despliegue dejó de depender de acceder manualmente al servidor.
Se utilizaron:
- Jenkins - rsync - scripting Bash - systemd - control de versiones
Eso permitió:
- trazabilidad - repetibilidad - reducción de errores humanos - rollback más sencillo - menor dependencia del operador
Una vez estabilizado el flujo operativo, el siguiente paso fue abandonar la dependencia del servidor único y migrar la plataforma hacia Linux en cloud.
La idea no era únicamente cambiar de sistema operativo, sino empezar a desacoplar aplicación e infraestructura.
Se reorganizó:
- estructura de despliegue - servicios - configuración - dependencias - procesos de arranque - gestión de logs
Y se empezó a trabajar con un enfoque mucho más declarativo.
La infraestructura dejó de construirse manualmente.
Terraform permitió definir:
- compute - red - almacenamiento - recursos cloud
Características clave:
- Declarativo - Reproducible - Versionable - Idempotente
Esto eliminó gran parte del drift entre entornos y permitió reconstruir infraestructura de forma consistente.
Terraform resolvía provisión, pero no configuración interna del sistema.
Ahí entró Ansible:
- instalación de paquetes - configuración de servicios - hardening básico - usuarios - despliegues - automatización operativa
Ventajas importantes:
- sin agentes - YAML declarativo - idempotencia - reproducibilidad
Esto redujo muchísimo las diferencias entre servidores y simplificó despliegues futuros.
Con la plataforma ya desacoplada y automatizada, la evolución natural fue mover la aplicación hacia un modelo basado en contenedores y Kubernetes.
Aquí el objetivo no era "usar Kubernetes porque sí", sino resolver problemas reales:
- despliegues más consistentes - desacoplamiento de infraestructura - portabilidad - escalabilidad - aislamiento - mejor gestión operativa
Se empezaron a definir:
- Deployments - Services - configuración declarativa - variables externas - persistencia - publicación de servicios
La aplicación dejó de depender de un servidor concreto.
Y aquí está probablemente la parte más importante de todo el proyecto.
Kubernetes no solucionó mágicamente los problemas.
Lo que realmente permitió evolucionar la plataforma fue:
- trazabilidad - automatización - reproducibilidad - separación de responsabilidades - documentación - control del ciclo de despliegue
Kubernetes simplemente terminó de consolidar un modelo que ya había empezado antes.
El sistema pasó de ser:
- manual - reactivo - dependiente de un servidor - difícil de mantener - poco trazable
a convertirse en:
- automatizado - reproducible - auditable - preparado para escalar - desacoplado de infraestructura
Este tipo de proyectos dejan una idea bastante clara:
Cuando el ritmo de cambio crece, apoyarse únicamente en operación manual deja de ser viable.
Automatización, CI/CD, IaC, Linux, cloud y Kubernetes no deberían verse como tecnologías aisladas, sino como piezas de un modelo operativo coherente.
La clave no está en desplegar más rápido.
La clave está en reducir complejidad operativa mientras el sistema sigue evolucionando.
Porque el verdadero problema nunca suele ser desplegar una vez. El problema es mantener el sistema durante años sin que cada cambio se convierta en una amenaza.