Cuando el crecimiento rompe la infraestructura: una empresa regional al límite
- 26 mar
- 3 min de lectura
Durante muchos años, una empresa regional del sector logístico operó con una infraestructura tecnológica relativamente sencilla. Su entorno estaba basado en un clúster de virtualización VMware con tres nodos físicos, almacenamiento SAN iSCSI y un conjunto de aplicaciones empresariales que gestionaban inventario, facturación y operaciones logísticas.
El entorno había sido diseñado para soportar alrededor de 120 usuarios concurrentes y cargas de trabajo previsibles. La arquitectura funcionaba correctamente porque el negocio tenía un crecimiento moderado y la mayoría de los procesos eran internos.
Pero el negocio cambió.
En menos de cuatro años la empresa duplicó su volumen de operaciones. Incorporó nuevas sedes en otros países, integró aplicaciones web para clientes y proveedores, y añadió servicios de seguimiento logístico en tiempo real que generaban miles de eventos por minuto.
La infraestructura comenzó a mostrar sus límites.
Las primeras señales aparecieron en la capa de base de datos. Los servidores SQL comenzaron a registrar picos de I/O en el almacenamiento, especialmente durante procesos de conciliación y generación de reportes. El almacenamiento SAN, diseñado originalmente con discos SAS tradicionales, empezaba a experimentar latencias superiores a 20-25 ms durante cargas intensivas.
Al mismo tiempo, las ventanas de respaldo nocturno comenzaron a extenderse. Los backups completos de las máquinas virtuales competían por recursos de red y almacenamiento con procesos batch que ejecutaban integraciones con sistemas externos.
El equipo de tecnología respondió ampliando capacidad.
Se añadieron dos nuevos hosts al clúster de virtualización, se expandió el volumen de almacenamiento y se aumentó el ancho de banda entre sedes. Estas acciones resolvieron temporalmente algunos cuellos de botella, pero introdujeron nuevos problemas.
El entorno virtualizado empezó a concentrar demasiadas cargas de trabajo en el mismo pool de recursos. Algunas máquinas virtuales críticas compartían almacenamiento con sistemas menos prioritarios, generando contención de I/O. Además, ciertas aplicaciones que procesaban eventos en tiempo real competían con procesos analíticos por CPU y memoria.
El problema no era únicamente de capacidad.
Era de arquitectura.
La infraestructura había sido diseñada para una operación mucho más pequeña y con patrones de uso muy distintos. A medida que el negocio creció, se fueron agregando componentes sin rediseñar la base tecnológica.
El resultado era un entorno difícil de escalar y cada vez más complejo de administrar.
La empresa decidió entonces replantear su arquitectura tecnológica.
El primer cambio fue migrar hacia una plataforma hiperconvergente basada en almacenamiento definido por software, lo que permitió distribuir las cargas de I/O entre nodos y reducir la latencia de acceso a datos mediante el uso de discos NVMe y SSD.
El segundo paso fue separar cargas de trabajo críticas. Las bases de datos transaccionales y los sistemas logísticos se aislaron en clusters dedicados para evitar contención de recursos con otras aplicaciones.
También se adoptó un modelo híbrido que integraba infraestructura local con servicios cloud en AWS y Azure. Algunas cargas analíticas y procesos batch se trasladaron a la nube para evitar que compitieran por recursos con los sistemas transaccionales.
Finalmente, se rediseñó la estrategia de backup y recuperación utilizando replicación incremental y snapshots coordinados con las bases de datos, lo que permitió reducir significativamente las ventanas de respaldo.
Los resultados comenzaron a verse rápidamente.
La latencia del almacenamiento se redujo a menos de 5 ms, las aplicaciones críticas recuperaron estabilidad y el equipo de tecnología volvió a tener margen para escalar servicios sin comprometer la operación.
Este tipo de situaciones deja una lección importante.
Muchas empresas amplían su infraestructura tecnológica añadiendo capacidad, cuando el problema real está en la arquitectura que sostiene esa infraestructura.
La tecnología puede escalar, pero solo cuando la arquitectura está preparada para hacerlo.
En AIT LATAM trabajamos precisamente en ese punto: diseñar infraestructuras tecnológicas que permitan a las organizaciones crecer sin que la complejidad operativa se convierta en un riesgo.
Porque cuando el crecimiento rompe la infraestructura, el problema rara vez es un servidor.
Es la arquitectura que lo sostiene.




Comentarios