Una de las preguntas que aparece con frecuencia cuando una empresa analiza su infraestructura es aparentemente sencilla:
¿Conviene seguir comprando servidores o migrar a cloud?
El problema es que muchas veces la comparación empieza mal.
Se toma el precio mensual de una máquina virtual en AWS, Azure o Google Cloud, se multiplica por algunos años y se lo compara contra el precio de compra de un servidor físico.
El resultado puede parecer contundente.
Pero estamos comparando dos modelos económicos y operativos diferentes.
Para evaluar correctamente una decisión de infraestructura no alcanza con mirar cuánto cuesta el hardware ni cuánto aparece en la calculadora del proveedor. Hay que entender qué estamos ejecutando, cómo se utiliza, qué nivel de servicio necesita y cuánto cuesta realmente operarlo durante todo su ciclo de vida.
Ese concepto es el Total Cost of Ownership o TCO.
Cloud no siempre es más barato. On-premise tampoco.
Una de las simplificaciones más habituales es asumir que migrar a cloud automáticamente reduce costos.
No necesariamente.
Pero tampoco es correcto asumir que mantener infraestructura propia siempre resulta más económico porque “el servidor ya está comprado”.
Ambos modelos tienen costos visibles y costos menos evidentes. Además, responden de manera diferente frente al crecimiento, la variabilidad de la demanda, la disponibilidad requerida y la capacidad del equipo técnico.
Por eso la comparación debería comenzar con una pregunta más útil:
¿Cuál es el costo total de operar este workload durante los próximos años?
Cuando planteamos el problema de esa manera, la conversación deja de ser simplemente “cloud vs servidor” y empieza a incorporar arquitectura, operación, utilización, licencias y riesgo.
El servidor no cuesta solamente lo que dice la factura
Una infraestructura propia tiene costos evidentes: servidores, storage, switches, licencias y contratos de soporte.
Pero también existen otros costos que muchas veces quedan distribuidos entre distintas áreas o presupuestos.
- Energía.
- Refrigeración.
- Espacio físico.
- UPS y protección eléctrica.
- Networking.
- Repuestos y garantías.
- Mantenimiento.
- Renovación de hardware.
- Monitoreo.
- Backup.
- Seguridad.
- Horas de administración.
- Capacidad ociosa.
Cuando esos componentes no se incluyen, terminamos comparando el costo completo del servicio cloud contra solamente una parte del costo de la infraestructura propia.
Eso puede llevar a conclusiones equivocadas en cualquier dirección.
Los principales proveedores de cloud utilizan justamente el concepto de TCO para modelar estas diferencias. AWS, por ejemplo, contempla hardware, software, soporte, facilities, energía y personal dentro de una evaluación de infraestructura. Google Cloud utiliza criterios similares en sus herramientas de estimación.
Cloud cambia CAPEX por consumo
En infraestructura tradicional normalmente compramos capacidad antes de necesitarla.
Si una aplicación necesita diez servidores hoy pero esperamos que crezca durante los próximos tres años, probablemente dimensionemos infraestructura pensando en capacidad futura, redundancia y picos.
Parte de esa capacidad puede permanecer subutilizada durante bastante tiempo.
Cloud propone otra lógica.
Muchos servicios se contratan bajo esquemas de consumo y se pagan según distintos indicadores:
- Horas o segundos de cómputo.
- Capacidad asignada.
- Almacenamiento utilizado.
- Cantidad de requests.
- Transferencia de datos.
- Operaciones realizadas.
- Servicios administrados consumidos.
AWS incluso compara su modelo pay-as-you-go con servicios públicos como electricidad o agua: se paga por aquello que se consume.
Esa flexibilidad permite reducir el problema de comprar capacidad anticipadamente, pero introduce otro:
si nadie controla el consumo, la factura también puede crecer rápidamente.
Cloud elimina parte del problema de sobredimensionar infraestructura, pero transforma el costo tecnológico en algo mucho más dinámico.
Ahí empieza a aparecer FinOps.
La utilización cambia completamente la ecuación
No todos los workloads tienen el mismo comportamiento.
Imaginemos dos escenarios.
Una aplicación estable
Funciona 24×7, mantiene una utilización relativamente constante y probablemente continúe operando durante años.
En ese escenario pueden tener mucho peso:
- Infraestructura dedicada.
- Compromisos de largo plazo.
- Capacidad reservada.
- Licencias existentes.
- Hardware ya amortizado.
Una aplicación con demanda variable
Puede tener temporadas de alta actividad, horarios con poco tráfico o crecimiento difícil de predecir.
En ese caso pueden resultar especialmente valiosos:
- Autoscaling.
- Infraestructura bajo demanda.
- Serverless.
- Servicios administrados.
- Capacidad temporal.
Aunque ambas aplicaciones necesiten técnicamente servidores similares, económicamente pueden ser problemas completamente diferentes.
Por eso preguntar solamente “¿cloud o infraestructura propia?” es demasiado amplio.
La pregunta correcta es: ¿qué modelo económico y técnico tiene sentido para este workload?
También hay que valorar la operación
Otro error frecuente es comparar solamente infraestructura.
Supongamos que un servicio administrado de base de datos cuesta más que una máquina virtual ejecutando el mismo motor.
Eso no demuestra automáticamente que la VM sea más económica.
Si administramos la plataforma nosotros mismos, alguien tiene que ocuparse de tareas como:
- Backups.
- Parches.
- Actualizaciones.
- Alta disponibilidad.
- Replicación.
- Monitoreo.
- Recovery.
- Hardening.
- Troubleshooting.
En algunos casos la organización quiere conservar ese control.
En otros, pagar por un servicio administrado puede liberar tiempo del equipo técnico para trabajar en problemas de mayor valor.
El costo financiero importa.
El costo operativo también.
Las licencias pueden cambiar todo
En muchos proyectos de infraestructura, el costo del hardware o del cómputo no es necesariamente el componente más importante.
Tecnologías como Windows Server, SQL Server, Oracle, VMware, software de backup y distintas herramientas de seguridad pueden modificar considerablemente una comparación.
También pueden existir condiciones particulares:
- Licencias perpetuas.
- Contratos vigentes.
- Derechos BYOL.
- Acuerdos corporativos.
- Descuentos por volumen.
- Restricciones de licenciamiento.
Migrar una máquina virtual sin revisar su modelo de licenciamiento puede transformar una migración aparentemente económica en una decisión mucho más costosa de lo esperado.
Por eso FinOps ya considera el licenciamiento y SaaS como parte explícita del análisis económico de la tecnología.
Y después están los datos
Mover cómputo suele ser relativamente sencillo.
Mover datos puede no serlo.
Antes de decidir una arquitectura hay que considerar:
- Volumen de información.
- Transferencia de datos.
- Latencia.
- Replicación.
- Backup.
- Residencia de datos.
- Requisitos regulatorios.
- Integraciones existentes.
- Dependencias con otros sistemas.
- Costos de egress.
Una aplicación puede funcionar técnicamente muy bien en cloud y, aun así, generar una arquitectura costosa si necesita mover grandes volúmenes de información permanentemente hacia otros entornos.
Lo mismo puede suceder al revés: mantener infraestructura únicamente para evitar mover datos también puede tener costos operativos importantes.
Por eso el análisis tiene que mirar el sistema completo.
La respuesta también puede ser híbrida
La decisión no siempre es:
cloud o datacenter.
Muchas organizaciones terminan utilizando una combinación de modelos.
Por ejemplo:
- Sistemas core en infraestructura propia.
- Aplicaciones web en cloud.
- Backups externos.
- SaaS para determinadas funciones.
- Analítica en cloud.
- Disaster Recovery en otra plataforma.
- Servicios administrados para componentes puntuales.
La infraestructura híbrida no necesariamente es un estado transitorio.
Puede ser una decisión consciente de arquitectura.
Entonces, ¿qué conviene comparar?
Antes de decidir, deberíamos poder modelar al menos dos o tres escenarios reales.
No solamente “cloud vs servidor”, sino cómo funcionaría cada arquitectura, cuánto costaría operarla, cómo crecería y qué riesgos introduciría.
Algunas preguntas que vale la pena responder son:
- ¿Cuál es la utilización real actual?
- ¿Existe capacidad ociosa?
- ¿Cuánto crecimiento esperamos?
- ¿Hay hardware próximo a renovarse?
- ¿Qué licencias están involucradas?
- ¿Cuánto cuesta operar actualmente el entorno?
- ¿Qué disponibilidad necesita realmente la aplicación?
- ¿Qué tareas podría asumir un servicio administrado?
- ¿Qué ocurre si la demanda se duplica?
- ¿Qué ocurre si la demanda cae?
- ¿Qué dependencias existen con otros sistemas?
- ¿Qué capacidad tiene actualmente el equipo técnico?
Con esa información es posible construir escenarios comparables.
Escenario A: mantener la infraestructura actual
Permite entender cuánto cuesta continuar operando el entorno existente y qué riesgos aparecen por antigüedad, capacidad o soporte.
Escenario B: renovar infraestructura propia
Permite calcular nueva inversión, amortización, soporte, licencias y capacidad disponible durante los próximos años.
Escenario C: migrar a cloud
Permite proyectar consumo, servicios administrados, transferencia de datos, descuentos, reservas y operación.
Escenario D: arquitectura híbrida
Permite evaluar si mantener determinados componentes en infraestructura propia y mover otros a cloud genera una mejor combinación de costo, riesgo y flexibilidad.
Ese ejercicio se parece mucho más a una decisión FinOps que simplemente comparar dos listas de precios.
No existe un ganador universal
Cloud no debería adoptarse simplemente porque “todo está yendo a cloud”.
Tampoco debería descartarse porque una calculadora mostró que cinco años de una máquina virtual cuestan más que comprar un servidor.
La infraestructura propia puede tener mucho sentido.
Cloud también.
Y en muchas organizaciones, la respuesta correcta será una combinación de ambas.
La decisión mejora cuando dejamos de comparar productos y empezamos a comparar arquitecturas, costos, operación, utilización, riesgo y valor para el negocio.
Ese es el punto donde una discusión de infraestructura empieza a convertirse en una decisión FinOps.
Preguntas frecuentes
¿Cloud siempre es más barato que una infraestructura on-premise?
No. Depende del tipo de workload, la utilización, las licencias, el costo operativo, la arquitectura y la capacidad necesaria. Una carga muy estable puede comportarse económicamente de manera muy diferente a una aplicación con demanda variable.
¿Qué significa TCO?
TCO significa Total Cost of Ownership o costo total de propiedad. Busca incluir no solamente el precio de compra o consumo de una tecnología, sino también los costos necesarios para operarla durante su ciclo de vida.
¿Qué es una infraestructura híbrida?
Es una arquitectura que combina distintos modelos, por ejemplo infraestructura propia, servicios cloud y plataformas SaaS. No necesariamente es una etapa de migración: puede ser una decisión permanente basada en requisitos técnicos y económicos.
¿Estás evaluando una migración o renovación de infraestructura?
Antes de decidir, conviene comparar escenarios completos: costos, utilización, licencias, operación, arquitectura y crecimiento esperado.
En FinOps Argentina trabajamos sobre ese análisis para transformar una discusión técnica en una decisión económica y operativa más clara.