Advertencia: esto es un poco largo, porque requiere algo de contexto primero.
Los CFO generalmente han estado en el negocio de las finanzas durante toda su vida y han invertido mucho tiempo en hacer las cosas de manera proscrita. Y como muchos en esa posición, su pensamiento a menudo se calcifica y las cosas nuevas son simplemente herejías.
Estoy excesivamente generalizando, por supuesto, pero es similar en concepto a la tercera regla en las Reglas de Tecnología de Douglas Adams, “cualquier cosa inventada después de los treinta y cinco años va en contra del orden natural de las cosas”.
- Como inicio de Internet, ¿debo pagar por un servidor dedicado o ir a la nube? Para aquellos que usan nubes para sus nuevas empresas, ¿a quién usaron y cuánto les costó? ¿Recibiste algún descuento?
- ¿Qué tan segura es la computación en la nube?
- ¿Cuál es la solución de almacenamiento en la nube más segura sobre la que solo usted tiene control completo?
- ¿Qué almacenamiento en la nube tiene el mayor espacio proporcionado a sus usuarios?
- ¿Alguna compañía ha intentado crear una solución integral de back office en la nube?
Los directores financieros de las empresas tradicionales tienden a pensar en incrementos de 1, 3 y más de 5 años. “¿Cuál es el costo total de este contrato de 1 año?” “¿Cuál es mi costo mensual por depreciar este equipo durante 3 años?” “¿Cuál es el ROI de 5 años para este proyecto?” Y eso es bueno, porque están analizando el panorama.
El personal técnico analiza los puntos débiles inmediatos que intentan resolver ahora. “¿Cuántos minutos tardarán en volver a conectar este servidor?” “¿Cuántas personas me están gritando en este momento ?” “Necesito comprar un nuevo servidor ahora, pero sé que tendrá que cambiar en seis meses con esos los tontos de arriba cambian de opinión otra vez “.
La computación en la nube se entiende mejor cuando aprende a hacer dos preguntas simples:
- ¿Cuál es nuestra unidad de medida más pequeña para la cual podemos calcular los costos?
- ¿Y si no necesitáramos todas esas unidades?
En mis días de operaciones, compramos un servidor web para una aplicación que estábamos desarrollando. Lo especificaríamos lo suficientemente robusto como para dar cuenta del crecimiento (el aumento del uso que causa más recursos de CPU / memoria / disco / red) durante tres años, ya que ese era el tiempo que sería nuestro dueño. Hay trucos para evitar esto, por supuesto … compre un servidor más nuevo / más grande los próximos años, migre la aplicación y reasigne el servidor anterior a una aplicación de menor uso, pero aún así tuvimos que pensar en 1 a 3 años. Toda esa CPU y memoria adicionales quedarían inactivas y se desperdiciarían.
Pero … ¿cuál es nuestra unidad de costo más pequeña para operar ese servidor? ¿Y si no necesitáramos todas esas unidades?
Solo se accedió a una de nuestras aplicaciones web durante el horario comercial del cliente, por lo que aproximadamente 12 horas al día (horario comercial estándar, en cuatro zonas horarias en los EE. UU., O aproximadamente 8 a.m. a 8 p.m. ET). Eso son 12 horas de uso y 12 horas de inactividad. ¿Qué pasaría si pudiéramos calcular nuestro costo por hora? ¿De qué maneras podríamos ahorrar dinero?
Si nuestro costo mensual por comprar / operar un servidor en nuestro centro de datos (depreciación de hardware, más energía, red y espacio en rack / piso) fue de $ 1000 / mes, eso es alrededor de $ 1.38 / hora.
¿Cuál podría ser mi costo en la computación en la nube? Ese mismo servidor solo puede costar $ 0.72 / hr ($ 0.66 / hr de ahorro), porque el proveedor compra servidores, energía, red y racks a granel. Sus costos por servidor pueden ser más bajos, y la virtualización les permite distribuir los costos de ese hardware de manera diferente. ¡De modo que $ .0.66 / hr se convierta en un ahorro de $ 481 / mes, o $ 17,345 durante tres años, para un servidor!
Dado que ahora estamos pagando por hora, ¿qué pasaría si pudiéramos apagarlo durante 12 horas al día? Eso $ 0.72 / hr nos cuesta $ 525 / mes. Recorte 12 horas al día y estamos viendo la mitad del costo.
De hecho, ¿qué pasaría si tuviéramos un servidor más pequeño durante esas 12 horas que estuvo en línea, porque siempre podemos cambiar a un servidor más grande cuando sea necesario? ¿Cuánto más dinero ahorraríamos? Según la utilización de la CPU / memoria, solo necesitamos un servidor de $ 0.24 / h. Así que ahora estamos viendo $ 87 / mes, para ejecutar ese servidor o $ 3153 durante tres años.
Excepto, tenemos un pico de tráfico todos los días durante tres horas, así que vamos a activar un segundo servidor para manejar la carga. Un adicional de $ .24 / h por tres horas al día, durante tres años es un exiguo $ 770. ¡Barato! (bueno, sin incluir los costos de desarrollo para volver a diseñar la aplicación para que se ejecute con éxito bajo ese nivel de elasticidad, pero este es un ejemplo simple).
¿Por qué un CFO no quisiera esto?
Dos razones:
No suelen funcionar a ese nivel de granularidad. Cuando estaba en Gestión de productos para un servicio en la nube pública, tuve que construir modelos de costos en precios unitarios por hora. Algunos de mis colegas se rieron de mí porque trabajaba en centavos por hora como mi unidad de medida, mientras que trabajaban en miles de dólares mensuales. Pero el CFO nunca vio esos modelos. Solo veía reservas por contrato (1 a 3 años) o ingresos mensuales. No le importaba mi información por unidad, como “costo por hora de un núcleo / hilo de CPU”. Quería saber cuál era el costo mensual / anual y los ingresos mensuales / anuales.
El CFO no analizará esta granularidad a menos que alguien les entregue una hoja de cálculo y un caso de negocios que describa el ejemplo anterior, traduciendo los costos por hora en ciclos mensuales / anuales / de 3 años. Y los técnicos, que trabajan directamente con los servidores, no son los que se sientan y preparan esa hoja de cálculo.
Recuerde, estos son profesionales que han estado en el negocio por un tiempo … probablemente tengan alrededor de 35 años o estén cerca de él. Y como dijo Douglas Adams, “cualquier cosa inventada después de los treinta y cinco años va en contra del orden natural de las cosas”.
Mi ejemplo anterior se basa en una aplicación que admití en mis viejos días de operaciones, unos años antes de que Amazon anunciara sus servicios iniciales S3 y EC2. Ciertamente nunca se me ocurrió determinar nuestros costos por hora, y ciertamente no habría tenido el conocimiento en ese entonces para calcularlo de todos modos. Para mí sugerir que apaguemos un servidor por la noche para ahorrar dinero hubiera sido ridículo. De hecho, muchas organizaciones ni siquiera saben cómo medir la utilización real de su servidor o determinar cuántos recursos realmente necesitan para soportar una aplicación. Están tan abrumados con el trabajo reaccionario (interrupciones, problemas de los usuarios, etc.) que superan las especificaciones para evitar problemas o intentan acercarse lo suficiente y simplemente lidian con las consecuencias día a día.
Si utilizan la nube pública “para ahorrar dinero”, el personal técnico querrá que sea una implementación exitosa. Por lo tanto, sobreespecifican los servidores, como siempre lo han hecho, para garantizar una transición sin problemas. Y luego usan los servidores 24 × 7.
El director financiero está inicialmente contento, porque su presupuesto CAPEX acaba de reducirse a tiempo para la reunión de la junta. Luego, después de unos meses o un año, calcula que el costo de tres años para OPEX es significativamente mayor que una depreciación de CAPEX de tres años, y no entiende por qué. Luego dice: “La nube es una pérdida de dinero. No me gusta
Todo porque nadie preguntó
“¿Cuál es nuestra unidad de costo más pequeña que podemos medir y calcular?”
“¿Y si no necesitáramos todas esas unidades?”.
