Escalar a Cero y Desde Cero en tu Clúster de Kubernetes

brown and beige weighing scale

Llevando la Experiencia Serverless a tu Clúster de Kubernetes

Escalar a Cero y Desde Cero en tu Clúster de Kubernetes

Foto de Piret Ilver en Unsplash

Serverless siempre ha sido considerado el siguiente paso en el viaje a la nube. Sabes a lo que me refiero: comienzas desde tu VM en las instalaciones, luego te mueves a tener contenedores en una plataforma PaaS, y luego intentas encontrar tu próxima parada en este viaje que es serverless.

Escalar a Cero y Desde Cero en tu Clúster de Kubernetes
Evolución tecnológica definida basada en la perspectiva de abstracción de infraestructura

Serverless es la idea de olvidarse de la infraestructura y centrarse solo en tus aplicaciones. No hay necesidad de preocuparse por dónde se ejecutará o la gestión de la infraestructura subyacente. Serverless comenzó como un sinónimo del paradigma de Función como Servicio (FaaS). Fue popularizado primero por las funciones de Amazon Lambda y luego por todos los principales proveedores de nube.

Comenzó como una alternativa al enfoque de contenedores que probablemente requiere muchas habilidades técnicas para gestionar y ejecutar a escala de producción, pero este ya no es el caso.

Hemos visto cómo el enfoque serverless ha llegado a cualquier plataforma a pesar de este punto de partida. Siguiendo los mismos principios, tenemos diferentes plataformas cuyo enfoque es abstraer todos los aspectos técnicos para la parte operativa y proporcionar una plataforma donde puedas poner tu lógica en ejecución. Prácticamente cada plataforma SaaS cubre este enfoque, pero me gustaría destacar algunos ejemplos para aclarar:

  • netlify es una plataforma que te permite desplegar tu aplicación web sin necesidad de gestionar nada más que el código necesario para ejecutarla.
  • TIBCO Cloud Integration es una solución iPaaS que proporciona todos los recursos técnicos que podrías necesitar para que puedas centrarte en desplegar tus servicios de integración.

Pero yendo más allá, prácticamente cada servicio proporcionado por las principales plataformas en la nube como Azure, AWS o GCP sigue el mismo principio. La mayoría de ellos (mensajería, aprendizaje automático, almacenamiento, etc.) abstraen toda la infraestructura subyacente para que puedas centrarte en el servicio real.

Volviendo al ecosistema de Kubernetes, tenemos dos capas diferentes de ese enfoque. La principal es el servicio de Kubernetes gestionado que todas las grandes plataformas proporcionan donde toda la gestión de Kubernetes (nodos maestros, componentes internos de Kubernetes) son transparentes para ti y te centras todo en los trabajadores. Y el segundo nivel es lo que puedes obtener en el mundo de AWS con la arquitectura tipo EKS + Fargate donde ni siquiera existen los nodos de trabajo, tienes tus pods que se desplegarán en una máquina que pertenece a tu clúster pero no necesitas preocuparte por ello, ni gestionar nada relacionado con eso.

Así que, como hemos visto, el enfoque serverless está llegando a todas las áreas, pero este no es el alcance de este artículo. La idea aquí es tratar de centrarse en serverless como sinónimo de Función como Servicio (FaaS) y cómo podemos llevar la experiencia FaaS a nuestro ecosistema productivo de K8S. Pero comencemos con las preguntas iniciales:

¿Por qué querríamos hacer eso?

Esta es la cosa más emocionante de preguntar: ¿cuáles son los beneficios que proporciona este enfoque? Función como Servicio sigue el enfoque de escala cero. Eso significa que la función no se carga si no se está ejecutando, y esto es importante, especialmente cuando eres responsable de tu infraestructura o al menos estás pagando por ella.

Imagina un microservicio normal escrito en cualquier tecnología, la cantidad de recursos que puede usar depende de su carga, pero incluso sin ninguna carga, necesitas algunos recursos para mantenerlo en funcionamiento; principalmente, estamos hablando de memoria que necesitas mantener en uso. La cantidad real dependerá de la tecnología y del desarrollo en sí, pero puede moverse de algunos MB a algunos cientos. Si consideramos todos los microservicios que una empresa significativa puede tener, obtendrás una diferencia de varios GB que estás pagando y que no están proporcionando ningún valor.

Pero más allá de la gestión de infraestructura, este enfoque también juega muy bien con otro de los últimos enfoques arquitectónicos, la Aplicación Basada en Eventos (EDA), porque podemos tener servicios que están dormidos solo esperando el evento correcto para despertarlos y comenzar a procesar.

Entonces, en resumen, el enfoque serverless te ayuda a obtener tu sueño de infraestructura optimizada y habilitar diferentes patrones también de manera eficiente. Pero, ¿qué pasa si ya poseo la infraestructura? Será lo mismo porque ejecutarás más servicios en la misma infraestructura, por lo que aún obtendrás el uso optimizado de tu infraestructura actual.

¿Qué necesitamos para habilitar eso?

Lo primero que necesitamos saber es que no todas las tecnologías o marcos son adecuados para ejecutarse en este enfoque. Eso se debe a que necesitas cumplir con algunos requisitos para poder hacerlo como un enfoque exitoso, como se muestra a continuación:

  • Inicio Rápido: Si tu lógica no está cargada antes de que una solicitud llegue al servicio, necesitarás asegurarte de que la lógica pueda cargarse rápidamente para evitar impactar al consumidor del servicio. Eso significa que necesitarás una tecnología que pueda cargarse en una pequeña cantidad de tiempo, generalmente hablando en el rango de microsegundos.
  • Sin Estado: Como tu lógica no se va a cargar en un modo continuo, no es adecuada para servicios con estado.
  • Descarte: Similar al punto anterior, debe estar listo para un apagado elegante de manera robusta.

¿Cómo hacemos eso?

Varios marcos nos permiten obtener todos esos beneficios que podemos incorporar en nuestro ecosistema de Kubernetes, como los siguientes:

  • KNative: Este es el marco que la Fundación CNCF apoya y se está incluyendo por defecto en muchas distribuciones de Kubernetes como Red Hat Openshift Platform.
  • OpenFaaS: Este es un marco muy utilizado creado por Alex Ellis que apoya la misma idea.

Es cierto que hay otras alternativas como Apache OpenWhisk, Kubeless o Fission, pero son menos utilizadas en el mundo actual y principalmente la mayoría de las alternativas han sido elegidas entre OpenFaaS y KNative, pero si quieres leer más sobre otras alternativas te dejaré un artículo sobre la CNCF cubriéndolas para que puedas echar un vistazo por ti mismo:

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

Beneficios de Serverless: Principales Ventajas Desde la Perspectiva Empresarial

Beneficios de Serverless: Principales Ventajas Desde la Perspectiva Empresarial

Aprende sobre las ventajas y desventajas de un enfoque sin servidor para tomar la decisión correcta para tu pila tecnológica 

Serverless es un tema apasionante para muchas personas, y es algo que ha evolucionado mucho desde su concepción. Comenzó siendo un enfoque para deshacerse de los servidores, no en el lado técnico (obviamente) sino en el lado de la gestión.

La idea detrás de esto es hacer que los desarrolladores, y las personas de TI en general, se concentren en crear código y desplegarlo en algún tipo de infraestructura gestionada. La contraposición habitual era contra plataformas basadas en contenedores. Con servicios de Kubernetes gestionados, como EKS o AKS, todavía eres responsable de los trabajadores que están ejecutando tu carga. No necesitas preocuparte por el componente de administración. Pero, de nuevo, necesitas manejar y gestionar algunas partes de la infraestructura.

Este enfoque también se incorporó en otros sistemas, como iPaaS y ofertas puras de SaaS en cuanto a low code o no code. E incluimos el concepto de función como servicio para marcar la diferencia en este enfoque. Entonces, la primera pregunta es: ¿Cuál es la principal diferencia entre una función que despliegas en tu proveedor sin servidor y una aplicación que puedes usar en tu iPaaS?

Depende de la perspectiva que quieras analizar.

Voy a omitir los detalles técnicos sobre capacidades de escalar a cero, técnicas de calentamiento, etc., y me centraré en la perspectiva del usuario. La principal diferencia es cómo estos servicios te van a cobrar en función de tu uso.

iPaaS u ofertas similares de SaaS te van a cobrar en función de la instancia de la aplicación o algo similar. Pero la plataforma sin servidor/función como servicio te va a costar en función del uso que hagas de esa función. Eso significa que te van a cobrar en función del número de solicitudes que reciba tu función.

Eso es un cambio de juego. Proporciona la implementación más precisa de las operaciones optimizadas y el enfoque de elasticidad. En este caso, es directo y claro que solo vas a pagar por el uso de tu plataforma. La economía es excelente. Echa un vistazo a la oferta de AWS Lambda hoy:

El nivel de uso gratuito de AWS Lambda incluye 1 millón de solicitudes gratuitas por mes y 400,000 GB-segundos de tiempo de cómputo por mes.

Y después de ese primer millón de solicitudes, te van a cobrar 0.20 $ por cada millón de solicitudes adicionales.

Al leer las oraciones anteriores, probablemente estés pensando: «Eso es perfecto. ¡Voy a migrar todo a ese enfoque!»

No tan rápido. Este estilo de arquitectura no es válido para todos los servicios que puedas tener. Aunque la economía es excelente, estos servicios vienen con limitaciones y anti-patrones que significan que deberías evitar esta opción.

Primero, comencemos con las restricciones que la mayoría de los proveedores de la nube definen para este tipo de servicios:

  • Tiempo de ejecución: Esto suele estar limitado por tu proveedor de la nube a un número máximo de segundos de ejecución. Eso es justo. Si te van a cobrar por solicitud, y puedes hacer todo el trabajo en una sola solicitud que tarda 10 horas en completarse utilizando los recursos del proveedor, ¡probablemente eso no sea justo para el proveedor!
  • Recursos de memoria: También limitados, por las mismas razones.
  • Carga útil de la interfaz: Algunos proveedores también limitan la carga útil que puedes recibir o enviar como parte de una función, algo a tener en cuenta cuando estás definiendo el estilo de arquitectura para tu carga de trabajo.

En un momento, veremos los anti-patrones o cuándo deberías evitar usar esta arquitectura y enfoque

Pero primero, una breve introducción a cómo funciona esto a nivel técnico. Esta solución puede ser muy económica porque el tiempo que tu función no está procesando ninguna solicitud no está cargado en sus sistemas. Por lo tanto, no está utilizando ningún recurso en absoluto (solo una pequeña parte de almacenamiento, pero esto es algo ridículo) y generando cualquier costo para el proveedor de la nube. Pero eso también significa que cuando alguien necesita ejecutar tu función, el sistema necesita recuperarla, lanzarla y procesar la solicitud. Eso generalmente se llama el «tiempo de calentamiento», y su duración depende de la tecnología que uses.

  • Servicios de baja latencia y Servicios con tiempo de respuesta crítico: Si tu servicio necesita baja latencia o el tiempo de respuesta debe ser agresivo, este enfoque probablemente no va a funcionar para ti debido al tiempo de calentamiento. Sí, hay soluciones alternativas para resolver esto, pero requieren solicitudes ficticias al servicio para mantenerlo cargado y generan costos adicionales.
  • Proceso por lotes o programado: Esto es para API sin estado para el mundo nativo de la nube. Si tienes un proceso por lotes que podría llevar tiempo, tal vez porque está programado por las noches o los fines de semana, podría no ser la mejor idea ejecutar este tipo de carga de trabajo.
  • Servicios masivos: Si pagas por solicitud, es importante evaluar el número de solicitudes que tu servicio va a recibir para asegurarte de que los números todavía estén a tu favor. Si tienes un servicio con millones de solicitudes por segundo, probablemente este no sea el mejor enfoque para tu presupuesto de TI.

Al final, serverless/función como servicio es tan genial por su simplicidad y lo económico que es. Al mismo tiempo, no es una bala de plata para cubrir todas tus cargas de trabajo.

Necesitas equilibrarlo con otros enfoques arquitectónicos y plataformas basadas en contenedores, o ofertas de iPaaS y SaaS, para mantener tu caja de herramientas llena de opciones para encontrar la mejor solución para cada patrón de carga de trabajo que tenga tu empresa.

Desplegando la aplicación Flogo en OpenFaaS

Desplegando la aplicación Flogo en OpenFaaS

OpenFaaS es una alternativa para habilitar el enfoque sin servidor en tu infraestructura cuando no estás operando en la nube pública y no tienes disponibles esas otras opciones como AWS Lambda Functions o Azure Functions, o incluso en la nube pública, te gustaría las características y opciones de personalización que proporciona.

OpenFaaS® (Funciones como Servicio) es un marco para construir funciones sin servidor con Docker y Kubernetes que tiene soporte de primera clase para métricas. Cualquier proceso puede ser empaquetado como una función, permitiéndote consumir una variedad de eventos web sin codificación repetitiva de plantilla.

Hay buen contenido en Medium sobre OpenFaaS, así que no me gusta pasar mucho tiempo en esto, pero me gustaría dejarte aquí algunos enlaces como referencia:

Ya tenemos mucha información sobre cómo ejecutar una aplicación Flogo como una función Lambda, como puedes ver aquí:

https://www.youtube.com/watch?v=TysuwbXODQI

Pero… ¿qué pasa con OpenFaaS? ¿Podemos ejecutar nuestra aplicación Flogo dentro de OpenFaaS? ¡Claro! Déjame explicarte cómo.

OpenFaaS es un marco muy personalizable para construir funciones de escala cero y podría necesitar algo de tiempo para familiarizarse con los conceptos. Todo se basa en watchdogs que son los componentes que escuchan las solicitudes y son responsables de lanzar los forks para manejar las solicitudes:

Vamos a usar el nuevo watchdog llamado of-watchdog que se espera sea el predeterminado en el futuro y toda la información está aquí:

Este watchdog proporciona varios modos, uno de ellos se llama HTTP y es el predeterminado, y se basa en un reenvío HTTP al servidor interno que se ejecuta en el contenedor. Eso encaja perfectamente con nuestra aplicación Flogo y significa que lo único que necesitamos es desplegar un disparador de solicitud HTTP Receive en nuestra aplicación Flogo y eso es todo.

Desplegando la aplicación Flogo en OpenFaaS

Las únicas cosas que necesitas configurar son el método (POST) y la Ruta (/) para poder manejar las solicitudes. En nuestro caso vamos a hacer una aplicación simple de Hola Mundo como puedes ver aquí:

Desplegando la aplicación Flogo en OpenFaaS

Para poder ejecutar esta aplicación necesitamos usar varias cosas, y vamos a explicarlo aquí:

Primero que nada, necesitamos hacer la instalación del entorno OpenFaaS, voy a omitir todos los detalles sobre este proceso y solo señalarte al tutorial detallado sobre ello:

Ahora necesitamos crear nuestra plantilla y para hacerlo, vamos a usar una plantilla de Dockerfile. Para crearla vamos a ejecutar:

faas-cli new --lang dockerfile

Vamos a nombrar la función flogo-test. Y ahora vamos a actualizar el Dockerfile para que sea así:

Desplegando la aplicación Flogo en OpenFaaS

La mayor parte de este contenido es común para cualquier otra plantilla que use el nuevo of-watchdog y el modo HTTP.

Me gustaría resaltar las siguientes cosas:

Usamos varias variables de entorno para definir el comportamiento:

  • mode = HTTP para definir que vamos a usar este método
  • upstream_url = URL a la que vamos a reenviar la solicitud
  • fprocess = Comando del sistema operativo que necesitamos ejecutar, en nuestro caso significa ejecutar la aplicación Flogo.

Otras cosas son las mismas que deberías hacer en caso de que quieras ejecutar aplicaciones Flogo en Docker:

  • Agregar el ejecutable del motor para tu plataforma (UNIX en la mayoría de los casos ya que la base de la imagen es casi siempre basada en Linux)
  • Agregar el archivo JSON de la aplicación que deseas usar.

También necesitamos cambiar el archivo yml para que se vea así:

version: 1.0
provider:
  name: openfaas
  gateway: http://abc59586cc33f11e9941b069251daa7b-1114483165.eu-west-2.elb.amazonaws.com:8080
functions:
  flogo-test:
    lang: dockerfile
    handler: ./flogo-test
    image: alexandrev/flogo-test:1.7

¡Y eso es todo! Ahora, solo necesitamos ejecutar el siguiente comando:

faas-cli up -f .flogo-test.yml

Y la función se va a desplegar en tu entorno y podemos ejecutarla usando el portal de OpenFaaS directamente:

Desplegando la aplicación Flogo en OpenFaaS

Todo el código está disponible aquí (lo único que falta es el Flogo Enterprise Engine que necesitas usar para poder construirlo y subirlo)