Funciones de nube vs motor de Kubernetes

Actualizado en agosto de 2019.

La línea de cómputo de Google ofrece muchas opciones excelentes. Dos de las mejores tecnologías en GCP son Kubernetes Engine y Cloud Functions. Ambos son potentes y, como desarrollador, es fácil establecer de forma predeterminada las funciones de la nube porque me quita mucho trabajo administrativo. Este trabajo administrativo, aunque declarativo yaml archivos es un aspecto importante para configurar Kubernetes Engine.

La premisa original de este artículo era que un desarrollador simplemente me preguntaba "¿cuándo elegirías Kubernetes sobre las funciones de la nube?". Es una pregunta que he considerado mucho desde que trabajé con estos dos, por lo que creo que la mejor manera de manejar esto es predeterminar las funciones de la nube y explicar las instancias en las que Kubernetes Engine sería una mejor opción. Si bien no catalogo todas las razones, aquí están las principales que juegan para elegir Kubernetes.

3 idiomas no van a cortarlo

Al usar Cloud Functions en este momento, solo tiene tres entornos de desarrollo para elegir y ese es Node.js, Python y Go. Esta es una tecnología increíble y es poderosa.

Kubernetes Engine le ofrece libertad porque los módulos que está creando son entornos aislados que pueden ejecutar cualquier idioma y tiempo de ejecución. Es posible que sea una tienda .NET y necesite aprovechar C #. He tenido la idea de utilizar las bibliotecas Core Foundation de Apple en un servicio. Ese servicio deberá escribirse en Swift. Estos son solo algunos de los casos que podrían implicar el uso de un lenguaje y un conjunto de marcos diferentes. En el futuro, Cloud Functions admitirá más de estas tecnologías, pero eso llevará bastantes años antes de que esté en producción.

Velocidad

Velocidad, y quiero decir en este momento, no en 200 ms. Esta es una diferencia fundamental. Hay casos en los que solo desea obtener datos y llevarlos a algún lado. Si no se usa una función de nube durante algún tiempo, todas las instancias de esa función se cerrarán. Esto es bueno, no está pagando nada si no lo está utilizando. Sin embargo, puede haber casos en los que simplemente no desee esperar esa hora de inicio en frío. Si esa no es una opción, Kubernetes te respaldará, ya eres un clúster y puedes tener un par de pods corriendo para ese servicio en particular listos para entrar en acción cuando sea necesario.

Procesamiento pesado y grandes cargas de trabajo.

Las funciones son excelentes para conectar varios servicios juntos. Sin embargo, no están destinados a tareas pesadas o de larga duración. Tienen poca CPU y memoria en comparación con Compute, Kubernetes y App Engine. Tienen un tiempo de espera mucho más rápido a los 5 minutos, lo que significa que el trabajo debe realizarse rápidamente y que debe regresar de la función rápidamente.

Además, no maneja bien las cargas pesadas. Si va a hacer mucho procesamiento de imágenes o análisis de big data en una función en la nube, se encontrará con problemas. Con Kubernetes Engine, tiene la capacidad de escalar pods en función de varios parámetros, como CPU alta, memoria, etc. Con las funciones en la nube, no tiene la capacidad de seleccionar CPU y la asignación de memoria es bastante baja en comparación con los otros servicios informáticos.

Invocación de locura

¿Cuántas veces invocas la función? ¿Cien o cien mil veces en un día? Es diferente si su función de nube se basa en un disparador de base de datos de Firebase, en ese momento vale la pena conformarse con la función de nube. Sin embargo, si está intentando crear un servicio que va a validar correos electrónicos o simplemente a ingerir una gran cantidad de datos, entonces vale la pena considerar Kubernetes. Primero, siempre puede tener algunos pods ejecutándose para reducir la latencia en el servicio. En segundo lugar, con Cloud Functions, parte del precio es cuántas veces se invoca una función. Con Kubernetes, puede escalar a más instancias durante las horas pico que reducir la escala. No importa si su servicio se invoca diez mil veces, en este punto está pagando por la cantidad de nodos y pods que está ejecutando, lo que reducirá sus costos generales.

Comunicación de microservicios

Finalmente, tenemos comunicación de servicio a servicio. Las funciones en la nube tienen algunos desencadenantes realmente potentes para Firebase y GCP. Por ejemplo, puede configurar un disparador Cloud Pub / Sub o activar otra función cargando archivos en Cloud Storage. Además, tenemos activadores HTTP que son útiles para crear enlaces web.

Sin embargo, ¿qué sucede si tiene varios servicios que no necesitan ser activados, pero solo quiere que se comuniquen entre ellos? Por el momento, hablar y comunicarse entre servicios no es realmente un enfoque efectivo cuando se usan Cloud Functions. Piense solo en el proceso de implementación. Con Cloud Functions, esto es engorroso cuando comienzas a actualizar un montón de servicios en Google Cloud. Mientras tanto, con Kubernetes simplemente está cargando sus configuraciones y Kubernetes se asegura de que el entorno se ejecute correctamente para usted. Sí, hay mucho más trabajo por adelantado para crear los archivos yaml, pero es muy simple mantener esa infraestructura en funcionamiento.

En última instancia, depende de lo que esté construyendo y cuáles sean sus necesidades, pero si está haciendo malabarismos con la idea de llamar a varios disparadores de funciones HTTP basados ​​en una llamada en sus Funciones de nube, debe retroceder y preguntarse si Kubernetes es una mejor opción para el 90% de intercomunicación que está ocurriendo.

Esta lista no es exhaustiva y definitivamente está abierta a interpretación. Nuevamente, se basa en sus necesidades como empresa y organización. Kubernetes todavía está creciendo a un ritmo rápido y no todos tienen un desarrollador / equipo disponible que pueda administrar un proyecto de Kubernetes Engine para ellos. Por otro lado, tal vez tenga muchos servicios .NET Core que desea implementar y Cloud Functions simplemente no lo cortará porque necesita usar Node.js, Python o Go. Siempre vale la pena dar un paso atrás y pensar en las diferentes tecnologías en juego y en cómo podemos aprovecharlas para ser lo más productivas posible.

James Wilson es un desarrollador que construye sistemas distribuidos utilizando Go y Google Cloud. También es autor de Pluralsight y puedes ver sus cursos aquí.