Cloud Run VS Cloud Functions: ¿Cuál es el más barato?

Autor: https://twitter.com/gblaquiere
Enlace original 

Elegir una solución desde un punto de vista técnico es importante, pero el coste de un servicio no debe olvidarse porque, en un entorno de escala automática, puede explotar sin previo aviso.
La comparación se realizó sólo en función de los precios y las cuotas y límites de cada producto. El rendimiento del procesamiento se supone igual en ambos

Cloud functions

El precio de las funciones en la nube se basa en la vCPU en GHz / sy la memoria en Gb / s, redondeada a los 100 ms más cercanos. La especificidad de las funciones es que puede ajustar la memoria y la velocidad de la CPU, pero no por separado. Ambos están vinculados, aumente la memoria si desea más MHz y viceversa.

El precio de salida de la red es una tarifa plana de $ 0,12 / Gb
Finalmente, las solicitudes se facturan a $ 0,40 el millón de solicitudes después de los primeros 2 millones de cuota gratuita.

Cloud Run (administrado)

El precio de Cloud Run se basa en vCPU / sy la memoria en Gb / s, redondeada a los 100 ms más cercanos. No es posible usar vCPU parcial por instancia. Su instancia siempre tiene 1 vCPU asignada. La memoria se puede ajustar de 128Mb a 2Gb

Una instancia puede manejar hasta 80 solicitudes concurrentes. Por lo tanto, para una instancia determinada, solo se le cobra cuando la instancia procesa al menos una solicitud.

La salida de la red se basa en el precio del Nivel Premium de la red después de 1 Gb de nivel gratuito.
Finalmente, las solicitudes se facturan a $ 0.40 cada millón de solicitudes después de los primeros 2 millones de solicitudes de cuota gratuita

En resumen

El costo de la red es ligeramente diferente con 5 Gb de nivel libre de salida para Cloud Functions y solo 1 para Cloud Run -> alrededor de $ 0.50 de diferencia. Pero el precio de salida de GB no es el mismo, y es más complejo en Cloud Run, basado en el Nivel Premium de red. En Europa y América del Norte, es notablemente más barato con Cloud Run comparado con Asia.

Las Cloud Functions permiten ajustar la velocidad de vCPU de acuerdo con la memoria utilizada. Pero solo puede manejar 1 solicitud por instancia.

Cloud Run siempre usa 1 vCPU; solo puedes ajustar la memoria. Pero Cloud Run puede procesar solicitudes concurrentes en la misma instancia.

Finalmente, el coste de la cantidad de solicitudes es estrictamente el mismo.

Por cierto, podemos considerar 2 casos principales de comparación: con solo 1 solicitud concurrente y con varias solicitudes simultáneas.

Para este caso se crea una GSheet para jugar con memoria, concurrencia y valores de requisitos de proceso.

Un caso de solicitud concurrente

En este caso, solo se compara el procesamiento de 1 solicitud. En este caso, Cloud Run y ​​Cloud Functions tienen exactamente 1 instancia para procesar esta solicitud única y, por lo tanto, solo se cobra esta instancia.

Este caso puede ocurrir si configura para una sola concurrencia en Cloud Run, o si tiene solicitudes dispersas y secuenciales a su servicio

Por lo tanto, en la misma condición, con 1 vCPU (2.4Ghz) y 2Gb de memoria, el precio y el rendimiento son estrictamente los mismos entre Cloud Run y ​​Cloud Functions.

Caso de varias solicitudes concurrentes

La mayoría de las veces, un servicio maneja varias solicitudes al mismo tiempo. Cloud Run tiene la capacidad de manejar hasta 80 solicitudes concurrentes con la misma instancia.

Por el contrario, Cloud Functions crea tantas instancias como las solicitudes concurrentes.
De este modo, más puede procesar la solicitud simultáneamente con Cloud Run, más barato es el servicio.

Que podemos valorar

La mejor opción depende de lo que desee optimizar, sus casos de uso y sus necesidades específicas.

Latencia más baja

Si su objetivo es la latencia más baja, elija Cloud Run.
De hecho, Cloud Run usa siempre 1 vCPU (al menos 2.4Ghz) y puede elegir el tamaño de memoria de 128Mb a 2Gb.

Con Cloud Functions, si se necesita el mejor rendimiento de procesamiento (2,4 Ghz de CPU), debe pagar 2 Gb de memoria. Si su necesidad de memoria es baja, las cloud function con 2 Gb de memoria son excesivas y cuestan nada.

Menor costo

Reducir los costos no siempre es la mejor estrategia para la satisfacción del cliente, pero la realidad empresarial puede requerirlo. De todos modos, depende mucho de su caso de uso.

Tanto Cloud Run como Cloud Function se redondean a los 100 ms más cercanos. Como podría jugar con la GSheet, las funciones en la nube son más baratas cuando el tiempo de procesamiento de 1 solicitud es inferior a los primeros 100 ms.

De hecho, puede ralentizar la vCPU de Cloud Functions, lo que tiene como consecuencia aumentar la duración del procesamiento, pero mientras se mantiene por debajo de 100 ms si lo ajusta bien. Por lo tanto, se utilizan menos Ghz / s y, por lo tanto, paga menos.

Por ejemplo, con un bajo requerimiento de procesamiento (se requieren 20Mhz) que requirió solo 128Mb de memoria, tiene:

• Cloud Functions: 100 ms de procesamiento por un costo de $ 0.23e-6
• Cloud Run: 8 ms de procesamiento por un costo de $ 2.4e-6

Claro, Cloud Functions es 10 veces más barato, pero sus clientes esperan 10 veces más. Y esta comparación de precios es cierta SOLO si tiene solicitudes secuenciales.

En este ejemplo, con más de 10 solicitudes simultáneas, ¡Cloud Run es más barato! De hecho, Cloud Run maneja hasta 80 solicitudes concurrentes en la misma instancia antes de crear (y facturar) una nueva.


Por el contrario, Cloud Functions maneja las solicitudes concurrentes en diferentes instancias y, por lo tanto, debe pagar cada instancia en ejecución además del sobrecoste de arranque en frío para cada
instancia creada.

Hay otro caso en el que las Cloud Functions son más baratas y es una buena idea ralentizar la vCPU: cuando una aplicación llama a las API y espera las respuestas. Tener una función con 200Mhz es suficiente y una vCPU completa de Cloud Run es exagerada (para ninguno o pocos procesos) y, por lo tanto, es costosa.

Limitación de instancia

En la página de Limitación y Cuota de cada producto, el número de instancias paralelas está limitado a 1000.

Sin embargo, con las Cloud Functions, es posible establecer un límite superior personalizado para limitar el número de instancias paralelas. Inicialmente lanzado para limitar el uso de recursos (por ejemplo, conexión de base de datos), también es una gran funcionalidad para limitar los gastos y establecer el límite superior del costo de su servicio. Pero siempre con un impacto negativo en la satisfacción del usuario en caso de saturación.

Cloud run aún no ofrece este tipo de limitación personalizable

Manejo de eventos

Las funciones en la nube se pueden activar mediante solicitudes HTTP (llamadas funciones HTTP) pero también por eventos activados en el entorno Google Cloud (llamadas funciones en segundo plano)

Por el contrario, los contenedores de Cloud Run solo pueden ser llamados por solicitudes HTTP. Sin embargo, es posible usar la suscripción de inserción de PubSub para impulsar los eventos de PubSub para que Cloud Run los procese. Además, también es posible publicar eventos de almacenamiento en el tema de PubSub y, por lo tanto, procesar eventos de almacenamiento con Cloud Run nuevamente a través de una suscripción push de PubSub. Pero no más.

Por lo tanto, a excepción de los eventos PubSub y Storage, las Cloud Functions son inevitables para todos los demás tipos de eventos. No hay elección posible.

Requisito de conexión VPC

Su aplicación sin servidor puede requerir algunos recursos privados solo disponibles en su VPC. Por ejemplo, un almacén de memoria para almacenamiento de clave-valor de baja latencia, o un acceso VPN / conexión directa para alcanzar recursos externos (OnPremise o en otra nube).

Las cloud Function permiten configurar un conector VPC para conectar sus funciones sin servidor a su VPC, y así enrutar el tráfico según sea necesario.
Hasta ahora, no era posible con Cloud Run administrado, pero podría cambiar a fines de 2019.

Que elegir

Antes de mi conclusión, me gustaría agregar algunas consideraciones adicionales, no directamente vinculadas al precio de la plataforma, sino también en todo el proceso de desarrollo, servicio y monitoreo.

A tener en cuenta sobre el costo

Las nubes públicas vienen con una nueva capacidad: el verdadero conocimiento del coste. En mi empresa, el coste de la nube generó miedos: ¡Woah, es caro! No, no lo es, pero es conocido, visible.

En un entorno local, es muy difícil saber el costo real por servicio, especialmente el costo humano o los recursos mutualizados (red, almacenamiento, alojamiento, ...).

Cuando elige una solución técnica, es importante tener en cuenta todas las piezas del proyecto y, en primer lugar, sus recursos humanos. Las funciones en el cloud parecen más baratas porque su caso de uso les queda bien. Pero, ¿su equipo puede desarrollar funciones en los idiomas disponibles?

En mi empresa, nuestra pila heredada (y experiencia) era PHP y C ++ y esto no se ajustaba a la capacidad de Cloud Functions. Por eso, los Docker fueron nuestra elección, incluso antes de que existiera el producto Cloud Run.

¿Realmente sabes el coste de tu equipo?

• Riesgo de renuncia porque las personas no están bien con una nueva pila
• Coste de la sesión de aprendizaje además de la ausencia de productividad durante el tiempo de aprendizaje.
• La falta de calidad de código, fiabilidad, rendimiento y productividad debido a la nueva implementación de código.

Todas estas razones son, la mayoría de las veces, mucho más caras que el costo del proveedor de la nube.

Además de este aspecto humano, ¿cuál será el costo de la refactorización en caso de portabilidad? ¿Cuál será el costo de X% más de errores debido a las dificultades de las pruebas o la falta de experiencia en un nuevo idioma?

Aplicación crítica

Hoy, Cloud Run está en beta. En Google Cloud Platform, las versiones beta son realmente estables y se pueden usar en producción. Sin embargo, no existe un compromiso de Google con el servicio y el soporte puede ser menos eficiente.

Las funciones en la nube están en GA para Python 3, Node 8 y Go 1.11

En la aplicación de misión crítica con SLA restrictivo, esta puede ser la primera opción de criterio, por encima del costo mismo.

Límites y cuotas

Existen pocas diferencias entre los 2 servicios, pero pueden implicar un cambio organizacional o un rediseño de diseño de solución técnica. Este es un costo indirecto, pero a tener en cuenta si planea implementar cientos de funciones en el cloud con una alta velocidad de implementación.

De hecho, las cloud Function están limitadas a 1000 funciones por proyecto y a 120 minutos de compilación por día y por proyecto.

En Cloud Run, no hay límite en la compilación porque se realiza fuera de la plataforma, y ​​existe el mismo límite de 1000 servicios por proyecto. PERO un servicio puede servir a varios endpointss.

Otro aspecto es el tamaño de cada solicitud / respuesta 3 veces mayor con Cloud Run que con Cloud Functions. ¿Su caso de uso se ve afectado por esto?
Otros límites son difíciles de comparar o no son relevantes para una gran mayoría de proyectos.

Conclusión

Como se puede ver, la comparación de costos entre Cloud Functions y Cloud Run va más allá de simplemente comparar una lista de precios. Además, en sus proyectos, a menudo tendrá que usar las 2 soluciones para aprovechar sus fortalezas y capacidades.

La primera opción para el desarrollo es Cloud Run. Su portabilidad, su capacidad de prueba, su apertura en las bibliotecas, los idiomas y los archivos binarios le confieren demasiadas ventajas para, al menos, un precio similar, y a menudo con una ventaja real en el costo pero también en el rendimiento, en particular para solicitudes concurrentes. Incluso si necesita el mismo nivel de aislamiento de las funciones de la nube (1 instancia por solicitud), ¡simplemente configure el parámetro de concurrencia en 1!

Sin embargo, algunas razones, como el soporte de GA, la capacidad de VPC o los eventos, pueden obligarlo a elegir Cloud Functions, pero, la mayoría de las veces, no será por una razón de precios.

Finalmente, la variedad de casos de uso, las diferencias en la organización y la complejidad de los recursos humanos (habilidades, deseos, motivaciones) generan demasiadas combinaciones y solo puedo proporcionar consejos y cosas que no olvidar en su proceso de decisión. No es posible proporcionar una respuesta única.

En cualquier caso, asegúrese de elegir el socio adecuado, con un punto de vista externo, que lo ayude en este viaje, hable con sus equipos y trate de encontrar la mejor respuesta a sus casos de uso.