Pregunta realmente interesante, y la respuesta del Director de Ingeniería de Dropbox realmente debería considerarse algo definitiva.
Dicho esto, permítanme explorar un poco la pregunta porque va al corazón de las aplicaciones de hiperescala.
Las aplicaciones de hiperescala son aplicaciones que sirven a millones de usuarios.
- ¿En qué medida los empleadores pagan completamente los planes de pensiones para los desarrolladores de software en los Países Bajos?
- ¿Los proyectos ReactJS / redux son imposibles de mantener una vez que el codificador original se va?
- ¿Cuáles son los idiomas y la pila que usarías para crear una aplicación moderna?
- Cómo recuperar y mostrar imágenes de MongoDB usando Node.js
- ¿Qué proyecto puedo hacer como desarrollador web front-end que agregaría peso a mi currículum?
La pregunta que debe hacerse es esta: ¿cuánto cuesta un solo usuario en términos de ciclos de cómputo en los ciclos de cómputo pico?
Y aquí está la respuesta perversa: no mucho. De hecho, si haces los cálculos, probablemente salga en centavos fraccionales. En Zynga hicimos los cálculos en 2011 y descubrimos que el costo por usuario era inferior a 0.1 centavos. Me sorprendería y encantaría que otro proveedor compartiera sus datos, pero dudo que alguien lo haga.
Resultado sorprendente
Qué significa eso?
Significa que los costos de CPU de un solo hilo para un solo usuario son pequeños; los costos solo importan a escala. Y si solo importan a escala, la pregunta se convierte en “¿Cómo pago la escala?”
La respuesta mejor y más optimista es que el usuario final pagará lo suficiente para sufragar los costos. Y supongo que Dropbox ha resuelto ese problema 🙂
Y resulta que una pequeña cantidad de usuarios tiene que pagar una pequeña cantidad para cubrir los costos de la infraestructura.
Si ese es el caso, entonces el costo de rendimiento de Python solo aumenta el número de usuarios que tienen que pagar para cubrir los costos de la infraestructura.
Y si los usuarios que tienen que pagar para alcanzar el punto de equilibrio es realmente pequeño desde una perspectiva de infraestructura pura, y usted ya tiene más que suficiente, entonces esta no es una optimización interesante.
Hagamos algo de aritmética para que el último párrafo sea menos claro:
cost_per_user = $ 0.001
total_users = 1000
infra_cost = $ 1
¿Cuánto tiene que pagar un solo usuario para cumplir con infra_costs?
$ 1
Entonces, siempre y cuando una persona pague $ 1, entonces no le importa que Python sea lento desde una perspectiva de costo puro. Tiene suficiente efectivo para ejecutar su infraestructura.
Ahora, obviamente, este es un ejemplo trivial, y supone un modelo de monetización muy pobre. Una compañía como Dropbox probablemente tiene más del 0.1% de sus usuarios pagando por el almacenamiento y, por lo tanto, los ingresos que generan son mucho más que los costos de la infraestructura.
Y eso me lleva al margen. Resulta que los costos solo importan, ya que afectan su modelo de negocio. Suponiendo que Dropbox es un negocio bien administrado, y eso se siente razonable, espero que el costo de su infraestructura sea pequeño en comparación con las ventas, el marketing y la ingeniería. Y cuanto más barata sea la infraestructura, más dinero tendrá que gastar en esas otras actividades.
Esta es una de esas situaciones de Navaja de afeitar de Occam.
Hagamos algo de aritmética para aclarar mi punto
Suponga que los ingresos totales = $ 100
Costo de ingeniería = $ 30
Infra = $ 1
Ventas + Marketing = $ 30
Si pudiera ahorrar el 50% de sus costos de Infraestructura yendo a C, eso reduciría sus costos totales en $ 0.50
Pero esos ahorros vendrían a expensas de la productividad de la ingeniería, presumiblemente es más fácil desarrollar características con Python. La disminución en la productividad de la ingeniería se traduciría en una disminución en la velocidad de la característica o en un aumento en los costos de ingeniería. En la práctica, realmente se traduce en una disminución en la velocidad de la característica.
Si desde una perspectiva comercial necesita más funciones en lugar de una infraestructura más barata, eso es una mala compensación.
Y esto me lleva al siguiente punto. Dadas las ganancias de productividad de Python y los costos reales de pasar a C, una mejor pregunta es esta: ¿Dropbox utiliza algún tipo de JIT para Python? Esto es lo que hicieron las personas muy inteligentes en Facebook. Frente a los costos de PHP desde el punto de vista de la infraestructura, en lugar de pasar a C, hicieron que PHP fuera mucho, mucho más rápido.
Usar un lenguaje que no sea C siempre es una buena solución para aplicaciones de hiperescala si puede hacer que un pequeño número de personas pague. Y hacer que los lenguajes dinámicos vayan más rápido siempre es una mejor respuesta que pasar a C en estos entornos.