El problema con “migrar todo a la nube”
En los últimos años, la nube pública —AWS en particular— pasó de ser una propuesta técnica a ser un argumento de transformación digital. El resultado es que muchas empresas medianas evaluaron o ejecutaron migraciones no porque el análisis técnico y financiero lo justificara, sino porque era lo que se suponía que había que hacer.
En Aleph Server hemos frenado propuestas de migración total a AWS. Y también hemos recomendado AWS cuando era la respuesta correcta. La diferencia siempre estuvo en el análisis, no en la preferencia por una arquitectura.
Este artículo describe los escenarios donde AWS entrega valor real para empresas medianas, los casos donde el modelo de costos deja de tener sentido, y el criterio que falta en la mayoría de las evaluaciones que se hacen hoy.
Cuándo AWS entrega valor real
Hay escenarios específicos donde la propuesta de valor de AWS para una empresa mediana es clara y verificable.
El primero es la elasticidad ante demanda variable. Si una aplicación tiene picos de uso predecibles o impredecibles que multiplican los requisitos de cómputo por dos, cinco o diez veces durante períodos acotados, AWS permite escalar en minutos sin inversión en hardware que pasará el 80% del tiempo subutilizado. El e-commerce con temporada de navidad, la plataforma de reservas con eventos puntuales, o el sistema de procesamiento de datos con cargas batch mensuales son ejemplos donde la elasticidad tiene valor económico directo.
El segundo es la velocidad de arranque sin inversión en hardware. Para proyectos nuevos donde la incertidumbre sobre el volumen real es alta, AWS permite empezar a operar sin un ciclo de adquisición de hardware. El costo de ese inicio rápido puede ser mayor a mediano plazo, pero el valor de no invertir en infraestructura que podría quedar obsoleta o sobredimensionada puede justificarlo.
El tercero es la disponibilidad geográfica distribuida. Para aplicaciones que necesitan baja latencia en múltiples regiones simultáneamente, AWS entrega esa capacidad sin la complejidad de operar centros de datos propios en distintos países.
El cuarto es el entorno de desarrollo y testing. Provisionar y desprovisionar ambientes de prueba bajo demanda, sin ocupar capacidad de infraestructura propia, tiene valor real para equipos de desarrollo que trabajan con múltiples versiones en paralelo.
Cuándo el modelo de costos de AWS no tiene sentido
Los casos donde el costo de AWS supera el valor que entrega para una empresa mediana son igualmente específicos.
El más frecuente es la carga de trabajo estable y predecible. Si una aplicación usa una cantidad constante de cómputo, almacenamiento y transferencia de datos durante todo el año, el modelo de pago por uso de AWS cobra esa consistencia con un precio por hora que, acumulado a doce meses, puede superar con creces el costo de hardware propio con soporte incluido. El breakeven entre AWS y on-premise o colocation para cargas estables suele estar entre doce y veinticuatro meses de operación.
El segundo es el costo de transferencia de datos. AWS cobra la salida de datos desde sus servicios hacia internet o hacia otros proveedores. Para aplicaciones con alto volumen de transferencia —bases de datos que sincronizan con sistemas on-premise, aplicaciones que sirven contenido pesado— ese costo puede ser significativo y no siempre aparece en las estimaciones iniciales.
El tercero es la complejidad operacional sin equipo técnico para gestionarla. AWS es una plataforma con cientos de servicios, modelos de pricing diferentes para cada uno, y una curva de aprendizaje real para operarla de forma eficiente. Una empresa mediana sin equipo técnico con experiencia en AWS, o sin presupuesto para soporte externo especializado, puede terminar pagando más por ineficiencias de configuración que por el cómputo que realmente usa.
El criterio que falta en la mayoría de las evaluaciones
La mayoría de las evaluaciones de migración a AWS que llegan a Aleph Server tienen en común que calculan el costo de las instancias EC2 y el almacenamiento S3, y lo comparan con el costo del hardware actual. Ese es un punto de partida, no un análisis completo.
El costo total a tres años incluye transferencia de datos, el soporte AWS (el plan Business Support+ tiene un costo mensual mínimo de 29 dólares por cuenta, con tarifas escalonadas sobre el gasto mensual que van del 9% al 3% según el volumen — para empresas medianas con gasto de entre 5.000 y 20.000 dólares mensuales en AWS, el costo de soporte suele estar entre 450 y 1.600 dólares mensuales adicionales), el tiempo del equipo técnico dedicado a gestionar la plataforma, y el costo de eventuales servicios adicionales que se van sumando a medida que la arquitectura crece.
Cuando ese número se calcula completo y se compara con el costo total de una infraestructura on-premise bien gestionada con soporte incluido, el resultado no siempre favorece a AWS. A veces sí. A veces no. La diferencia está en el análisis, no en el supuesto de que la nube es siempre más económica.
El enfoque que aplica Aleph Server
La arquitectura que recomendamos no es on-premise por principio ni cloud por tendencia. Es la que resulta del análisis del patrón de uso real, el costo total a tres años, la capacidad técnica del equipo, y los requisitos de disponibilidad y latencia de cada aplicación específica.
En muchos casos la respuesta es híbrida: cargas estables en infraestructura propia, capacidad elástica o servicios específicos en AWS. En otros casos es completamente on-premise. En otros, completamente cloud. El análisis determina la arquitectura, no al revés.
