Costo total de propiedad

La factura que solo te dice el precio del medidor

En 2022, 37signals, la empresa detrás de Basecamp y el servicio de correo Hey, decidió que sus facturas de AWS y Google Cloud se habían vuelto una de las partes más caras de operar el negocio, y empezó a mover esa infraestructura de vuelta a sus propios centros de datos. Para 2024, su factura anual de nube había bajado de $3.2 millones a $1.3 millones, un ahorro reportado de $2 millones al año, después de una compra inicial de hardware de cerca de $700,000, con la empresa proyectando más de $10 millones ahorrados en 5 años. Ese es un caso real y bien documentado de que ser dueño del hardware costó menos que rentar la capacidad equivalente, para esa carga de trabajo específica, estable y predecible de esa empresa.

También es, por sí sola, una comparación incompleta, y entender por qué es exactamente para lo que sirve el costo total de propiedad.

Qué significa TCO en realidad

El costo total de propiedad es el costo completo de adquirir, correr y mantener un sistema durante un periodo definido, normalmente de 3 a 5 años, no solo el precio de una sola línea. Una factura de nube muestra el medidor: cómputo, almacenamiento y transferencia de datos, facturados por el mes que se acaba de usar. Una cotización de hardware muestra el precio de lista de la máquina. Ninguno de los 2 es TCO. TCO es lo que obtienes una vez que sumas todo lo que rodea a ese número visible en ambos lados de la comparación.

Costos directos frente a los costos que nadie pone en la factura

Los costos directos y medidos son los que ya muestra una factura de nube: cómputo, almacenamiento y transferencia de datos. La transferencia de datos merece una nota aparte, porque no es simétrica. AWS, como la mayoría de los proveedores, no cobra por mover datos hacia su nube, pero sí cobra, en niveles escalonados, por sacar datos, lo que se llama egress. Una carga de trabajo que lee poca información pero exporta grandes cantidades con regularidad puede terminar con una factura de transferencia de datos mucho más grande de lo que sugeriría su costo de cómputo por sí solo.

Todo lo demás es un costo indirecto, y se ubica en ambos lados de la comparación, no solo en uno. Del lado de la nube: el trabajo único de migrar o rediseñar una carga de trabajo para que corra ahí, el tiempo del personal dedicado a configurar, monitorear y optimizar los recursos en la nube, las herramientas de gestión de costos y monitoreo compradas específicamente para vigilar ese gasto, y las herramientas de seguridad o cumplimiento que se agregan encima. Del lado de sitio propio: energía y enfriamiento para el cuarto donde vive el hardware, el bien inmueble mismo, una renovación de hardware cada pocos años conforme el equipo envejece, y tiempo del personal dedicado a instalar, parchar y eventualmente desechar equipo retirado, la misma carga de mantenimiento que la primera lección de este dominio describió como una de las razones originales por las que existe la nube.

La trampa: comparar solo lo que es fácil de comparar

Es tentador correr esta comparación revisando 2 números, la factura de nube de este trimestre y el precio de lista de hardware equivalente, y declarar ganador al que sea menor. Ninguno de los 2 números es TCO. La factura de nube deja fuera al personal y las herramientas que se acumulan alrededor de ella. El precio de lista del hardware deja fuera la energía, el enfriamiento y el ciclo de renovación que vuelve a aparecer en 3 a 5 años.

El caso de 37signals es un ejemplo útil y real de qué tan fácil es caer en esta trampa incluso cuando una empresa intenta genuinamente ser rigurosa. La cobertura independiente sobre el movimiento señaló específicamente que sus cifras de ahorro publicadas todavía no contaban los futuros costos de renovación de hardware, el personal de operaciones adicional que exigió el cambio, ni el costo continuo de operar espacio, energía y enfriamiento de centro de datos. Eso no es una crítica a la decisión de 37signals, que bien podría sostenerse una vez que se cuenten esas categorías. Es una muestra de que incluso una empresa que defiende públicamente ser dueña de su hardware no había terminado de contar, en el momento en que se reportaron esas cifras, cada categoría que exige una comparación de TCO completa.

Ejemplo trabajado: una comparación de 3 años, hecha con honestidad

Toma una carga de trabajo con tráfico estable y predecible y compara 3 años de propiedad en sitio propio contra 3 años en la nube, contando los costos indirectos de ambos lados.

Para esta carga de trabajo específica y estable, la comparación honesta de 3 años favorece al hardware en sitio propio, por unos $56,000, y no simplemente porque la factura medida de la nube sea más grande que el precio de lista del hardware. Solo se ve claro una vez que se cuenta el personal y las herramientas de ambos lados. Es la misma forma de decisión que tomó 37signals, a una escala mucho más grande.

Cambia una sola suposición y la respuesta puede voltearse. Dale a esta carga de trabajo un patrón de tráfico que se dispara a 3 veces su base durante 2 semanas al año, y el lado de sitio propio ahora necesita hardware dimensionado para un pico que usa 2 semanas y deja ocioso el resto del año, el mismo problema de sobreaprovisionamiento que la nube nació para eliminar. El lado de nube, en cambio, simplemente escala hacia arriba esas 2 semanas y vuelve a bajar después, pagando solo por la capacidad extra que en verdad usó. Ese único cambio en la forma de la carga de trabajo suele bastar para voltear la comparación al lado contrario. Ni "la nube siempre es más barata" ni "la nube siempre es un robo" es una regla que puedas memorizar; TCO es un cálculo que corres para una carga de trabajo específica, no un veredicto que se traslada del caso de una empresa al de otra.

FinOps: la disciplina que evita que el TCO se quede obsoleto

Un cálculo de TCO es una fotografía, calculada una vez para una decisión tomada en un momento dado. El gasto en la nube no se queda quieto después de esa decisión: cambia cada vez que un ingeniero levanta un recurso nuevo, que es justo lo que lo hace distinto de un presupuesto fijo de centro de datos, definido una vez al año y dejado en paz. FinOps es la disciplina construida para manejar esa diferencia. La FinOps Foundation la define como un marco operativo y una práctica cultural que maximiza el valor de negocio de la tecnología, permite decisiones oportunas y basadas en datos, y crea responsabilidad financiera a través de la colaboración entre ingeniería, finanzas y el negocio, en vez de tratar el costo como algo que solo revisa un área de finanzas después de los hechos.

Es la misma idea a la que apunta el propio AWS Well-Architected Framework con sus principios de optimización de costos: implementar la gestión financiera en la nube como una capacidad organizacional real, y analizar y atribuir el gasto de forma continua para que el dueño de una carga de trabajo pueda ver, y actuar sobre, lo que en verdad le cuesta. FinOps es lo que se ve cuando corres ese análisis de forma continua en vez de una vez al año.

Hacia dónde te lleva esto

Una factura de nube y una cotización de hardware son las 2 respuestas parciales. Antes de comparar 2 formas de correr una carga de trabajo, enumera todos los costos directos e indirectos de ambos lados, ponles precio en la misma ventana de varios años, y solo después compara los totales. Consigue ese hábito una vez, en una hoja de cálculo, y FinOps es simplemente lo que se ve al seguir haciéndolo de forma continua en vez de una sola vez.

Con esto se cierra la economía de la nube: qué problema resuelve, cómo pagas por ella y qué cuesta correrla en realidad. El siguiente dominio deja atrás el costo y pasa a los servicios mismos, empezando por las 3 formas en que los proveedores de nube empaquetan lo que venden: IaaS, PaaS y SaaS.