Alexandre Vazquez

Serverless ya está aquí. Lo sabemos. Incluso para las empresas que están comenzando su viaje en la nube moviéndose a plataformas basadas en contenedores, ya saben que serverless está en su visión futura al menos para algunos casos de uso específicos.

Su simplicidad sin necesidad de preocuparse por nada relacionado con la plataforma solo se enfoca en el código y también la economía que viene con ellos hace que este modelo de computación sea un cambio de juego.

La plataforma principal para este enfoque en este momento es AWS Lambda de Amazon, hemos leído y escuchado mucho sobre AWS Lambda, pero todas las plataformas van por ese camino. Google con sus Google Functions, Microsoft con su Azure. Esto no es solo una cosa para los proveedores de nube pública, también si estás operando en un enfoque de nube privada puedes usar este modo de implementación usando frameworks como KNative o OpenFaaS. Si necesitas más detalles al respecto, también tuvimos algunos artículos sobre este tema:

Deploying Flogo App on OpenFaaS

OpenFaaS is an alternative to enable the serverless approach in your infrastructure when you’re not running in the public cloud and you don’t have available those other options like AWS Lambda Functions or Azure Functions or even in public cloud, you’d like the features and customizations option it provides. OpenFaaS® (Functions as a Service) is […]

Todas estas plataformas están actualizando y mejorando su opción para ejecutar cualquier tipo de código que desees en ellas, y esto es lo que Azure Function acaba de anunciar hace unas semanas, el lanzamiento de un enfoque de Custom Handler para soportar cualquier tipo de lenguaje que puedas imaginar:

Azure Functions custom handlers

Learn to use Azure Functions with any language or runtime version.

Y vamos a probar eso haciendo lo que más nos gusta ………..

…. ¡Ejecutar una aplicación Flogo sobre eso!

Así que, ¡empecemos a trabajar!

Lo primero que necesitamos hacer es crear nuestra aplicación Flogo. Voy a usar Flogo Enterprise para hacer eso, pero puedes hacer lo mismo usando la versión de código abierto también:

Vamos a crear una aplicación simple, solo un servicio REST de Hello World. Como puedes ver aquí:

El archivo JSON de la aplicación Flogo puedes encontrarlo en el repositorio de GitHub que se muestra a continuación:

GitHub - alexandrev/flogo-azure-function: Sample of Flogo Application running as a Azure Function

Sample of Flogo Application running as a Azure Function - GitHub - alexandrev/flogo-azure-function: Sample of Flogo Application running as a Azure Function

Pero las configuraciones principales son las siguientes:

• El servidor escuchará en el puerto especificado por la variable de entorno FUNCTIONS_HTTPWORKER_PORT
• El servidor escuchará una solicitud GET en la URI /hello-world
• La respuesta será bastante simple “Invocando una aplicación Flogo dentro de Azure Functions”

Ahora, que tenemos el archivo JSON, solo necesitamos comenzar a crear los artefactos necesarios para ejecutar una función de Azure.

Necesitaremos instalar el paquete npm para las Azure Functions. Para hacer eso necesitamos ejecutar el siguiente comando:

npm i -g azure-functions-core-tools@3 --unsafe-perm true

Es importante tener el “@3” porque de esa manera hacemos referencia a la versión que tiene esta nueva lógica de Custom Handler para poder ejecutarla.

Crearemos una nueva carpeta llamada flogo-func y ejecutaremos el siguiente comando dentro de esa carpeta:

func init --docker

Ahora deberíamos seleccionar node como el entorno de ejecución a usar y javascript como el lenguaje. Eso podría ser algo extraño porque no vamos a usar ni node, ni dotnet ni python ni powershell. Pero seleccionaremos eso para mantenerlo simple ya que solo intentamos enfocarnos en el enfoque de Docker para hacerlo.

Después de eso solo necesitamos crear una nueva función, y para hacer eso necesitamos escribir el siguiente comando:

func new

En la interfaz basada en CLI que nos muestra las Azure Function Core Tools, solo necesitamos seleccionar HTTP trigger y proporcionar un nombre.

En nuestro caso, usaremos hello-world como el nombre para mantenerlo similar a lo que definimos como parte de nuestra aplicación Flogo. Terminaremos con la siguiente estructura de carpetas:

Ahora necesitamos abrir la carpeta que se ha creado y necesitamos hacer varias cosas:

• Primero que todo, necesitamos eliminar el archivo index.js porque no necesitamos ese archivo ya que esta no será una función de node JS.
• Necesitamos copiar el HelloWorld.json (nuestra aplicación Flogo) a la carpeta raíz de la función.
• Necesitamos cambiar el archivo host.json al siguiente contenido:

{

  "version": "2.0",

  "httpWorker": {

     "description": {

            "arguments": ["-app"],

            "defaultExecutablePath": "engine-windows-amd64.exe",

            "defaultWorkerPath": "HelloWorld.json"

      }

   }

}

Ahora, necesitamos generar el engine-windows-amd64.exe y para poder hacer eso necesitamos ir al FLOGO_HOME en nuestra máquina e ir a la carpeta FLOGO_HOME/flogo/<VERSION>/bin y lanzar el siguiente comando:

./builder-windows-amd64.exe build

Y deberías obtener el engine-windows-amd64.exe como salida como puedes ver en la imagen a continuación:

Ahora, solo necesitas copiar ese archivo dentro de la carpeta de tu función, y deberías tener la siguiente estructura de carpetas como puedes ver aquí:

Y una vez que tengas eso, solo necesitas ejecutar tu función para poder probarla localmente:

func start

Después de ejecutar ese comando deberías ver una salida similar a la que se muestra a continuación:

¡Solo me gustaría resaltar el tiempo de inicio para nuestra aplicación Flogo alrededor de 15 milisegundos! Ahora, solo necesitas probarlo usando cualquier navegador y solo ir a la siguiente URL:

http://localhost:7071/api/hello-world

Este ha sido solo el primer paso en nuestro viaje, pero fueron los pasos necesarios para poder ejecutar nuestra aplicación Flogo como parte de tu entorno serverless alojado por la plataforma Microsoft Azure!

Todos sabemos que con el auge del desarrollo y las arquitecturas nativas de la nube, hemos visto plataformas basadas en Kubernetes como el nuevo estándar, todas enfocándose en nuevos desarrollos siguiendo los nuevos paradigmas y mejores prácticas: Microservicios, Arquitecturas impulsadas por eventos, nuevos protocolos brillantes como GraphQL o gRPC, y así sucesivamente.

Pero debemos ser conscientes de que la mayoría de las empresas que hoy están adoptando estas tecnologías no son oportunidades de campo verde. Tienen muchos sistemas ya en funcionamiento con los que todos los nuevos desarrollos en las nuevas arquitecturas nativas de la nube necesitan interactuar, por lo que las reglas se vuelven más complejas y hay muchas tonalidades de gris cuando estamos creando nuestra aplicación en Kubernetes.

Y basado en mi experiencia, cuando estamos hablando con el cliente sobre la nueva arquitectura en la nube, la mayoría de ellos traen aquí el patrón por lotes. Saben que esto ya no es una mejor práctica, que no pueden seguir construyendo sus sistemas de manera por lotes tratando de hacer por la noche lo que deberíamos estar haciendo en tiempo real. Pero, la mayoría de las veces necesitan coexistir con los sistemas que ya tienen y podría ser necesario este tipo de procedimiento. Así que necesitamos encontrar una manera de proporcionar Procesamiento por Lotes en Kubernetes.

También para los clientes que ya tienen sus aplicaciones existentes usando ese patrón y quieren moverse al nuevo mundo, es mejor para ellos que puedan hacerlo sin necesidad de re-arquitectar su aplicación existente. Algo que probablemente terminarán haciendo pero a su propio ritmo.

Los patrones de procesamiento por lotes en el desarrollo de TIBCO son un patrón bastante utilizado y tenemos clientes en todo el mundo con este tipo de desarrollo usado en producción durante muchos años. Ya sabes, este tipo de proceso que se ejecuta en un momento específico (semanalmente los lunes, cada día a las 3 PM… o simplemente cada hora para hacer algún trabajo regular).

Es un patrón sencillo aquí. Simplemente agrega un temporizador que puedes configurar cuándo se lanzará y agrega tu lógica. Eso es todo. Tan simple como eso:

Pero, ¿cómo se puede traducir esto a un enfoque de Kubernetes? ¿Cómo podemos crear aplicaciones que funcionen con este patrón y aún así ser gestionadas por nuestra plataforma? Afortunadamente, esto es algo que se puede hacer, y también tienes diferentes maneras de hacerlo dependiendo de lo que quieras lograr.

Principalmente hoy vamos a describir dos maneras de poder hacer eso y tratar de explicar las principales diferencias entre una y otra para que puedas saber cuál deberías usar dependiendo de tu caso de uso. A esos dos métodos los voy a llamar de esta manera: Lote gestionado por TIBCO Kubernetes y enfoque de API de Cron Job

Lote Gestionado por TIBCO

Este es el más simple. Es exactamente el mismo enfoque que tienes en tu aplicación BusinessWorks existente en las instalaciones, solo que desplegado en el clúster de Kubernetes.

Así que, no necesitas cambiar nada en tu lógica, solo tendrás una aplicación que es iniciada por un Temporizador con su configuración respecto a la programación dentro del alcance de la aplicación BusinessWorks y eso es todo.

Solo necesitas proporcionar los artefactos necesarios para desplegar tu aplicación en Kubernetes como cualquier otra aplicación de TIBCO BusinessWorks y eso es todo. Eso significa que estás creando un Despliegue para lanzar este componente y siempre tendrás un pod en ejecución evaluando cuándo la condición es verdadera para lanzar el proceso como lo tienes en tu enfoque en las instalaciones.

API de Cron-Job de Kubernetes

El patrón de procesamiento por lotes es algo que ya está cubierto de manera predeterminada por la API de Kubernetes y por eso tenemos el concepto de Cron-Job. Probablemente recuerdes los Cron Jobs que tenemos en nuestras máquinas Linux. Si eres un desarrollador o un administrador de sistemas, estoy seguro de que has jugado con estos cronjobs para programar tareas o comandos para que se ejecuten en un momento determinado. Si eres una persona basada en Windows, este es el equivalente en Linux de tus Trabajos del Programador de Tareas de Windows. Mismo enfoque.

Y esto es muy simple, solo necesitas crear un nuevo artefacto usando esta API de Cron Job que principalmente dice el trabajo a ejecutar y la programación de ese trabajo similar a lo que hemos hecho en el pasado con el cronjob en nuestra máquina Linux:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hola desde el clúster de Kubernetes
          restartPolicy: OnFailure

Los trabajos que podemos usar aquí deben cumplir con una regla única que también se aplica en los trabajos cron de Unix: El comando debe terminar cuando el trabajo esté hecho.

Y esto es algo que es crítico, lo que significa que nuestro contenedor debe salir cuando el trabajo esté hecho para poder ser usado dentro de este enfoque. Eso significa que no podemos usar un “enfoque de servidor” como estamos haciendo en el enfoque anterior porque en ese caso, el pod nunca termina. ¿Significa eso que no puedo usar una aplicación de TIBCO BusinessWorks como parte de un Cron Job de Kubernetes? ¡Absolutamente no! Veamos cómo puedes hacerlo.

Así que, deberíamos centrarnos en dos cosas, la lógica de negocio debería poder ejecutarse tan pronto como el proceso comience y el contenedor debería terminar tan pronto como el trabajo esté hecho. Comencemos con la primera.

La primera es fácil. Usemos nuestro ejemplo anterior: Enfoque por lotes simple que escribe una traza de registro cada minuto. Necesitamos hacer que comience tan pronto como el proceso haya comenzado, pero esto es bastante de serie (OOTB) con TIBCO BusinessWorks, solo necesitamos configurar ese temporizador para que se ejecute solo una vez y eso comenzará tan pronto como la aplicación esté en ejecución:

Así que, ya tenemos el primer requisito solucionado, veamos con el otro.

Deberíamos poder terminar el contenedor completamente cuando el proceso termine y eso es un desafío porque la aplicación BusinessWorks no se comporta de esa manera. Se supone que deben estar siempre en ejecución. Pero esto también se puede resolver.

Lo único que necesitamos es hacer uso de un comando al final del flujo. Es como un comando de salida en nuestro script de shell o código Java para terminar el proceso y el contenedor. Para hacer eso, deberíamos agregar una Actividad de “Ejecutar Comando Externo” y simplemente configurarla para enviar una señal al proceso BusinessWorks que se ejecuta dentro del contenedor.

La señal que vamos a enviar es SIGINT, que es similar a la que enviamos cuando presionamos CTRL+C en un Terminal para requerir que el proceso se detenga. Vamos a hacer lo mismo. Para hacer eso, vamos a usar el comando kill que se incluye en todas las máquinas Unix y en la mayoría de las imágenes base de docker también. Y el comando kill requiere dos argumentos:

kill -s <SIGNAL_NAME> <PID>

• SIGNAL_NAME: Ya cubrimos esa parte y vamos a usar la señal llamada SIGINT.
• PID: En cuanto al PID, necesitamos proporcionar el PID del proceso BusinessWorks que se ejecuta dentro del contenedor.

La parte de encontrar el PID para ese proceso que ejecuta BusinessWorks dentro del contenedor puede ser difícil de localizar, pero si ves los procesos en ejecución dentro de un contenedor de BusinessWorks, puedes ver que no es tan complicado de encontrar:

Si entramos dentro de un contenedor en ejecución de una aplicación BusinessWorks, verificaremos que este PID siempre es el número 1. Así que ya tenemos todo listo para configurar la actividad como se muestra a continuación:

Y eso es todo, con estos dos cambios podemos desplegar esto usando la API de CronJob y usarlo como parte de tu conjunto de herramientas de patrones de aplicación.

Pros y Contras de cada enfoque

Como puedes imaginar, no hay una solución única sobre cuándo usar uno u otro porque va a depender de tu caso de uso y tus requisitos. Así que intentaré enumerar aquí las principales diferencias entre ambos enfoques para que puedas elegir mejor cuando esté en tus manos:

• El enfoque gestionado por TIBCO es más rápido porque el pod ya está en ejecución y tan pronto como se cumple la condición, la lógica comienza. Usar la API de Cron Job requiere un período de calentamiento porque el pod comienza cuando se cumple la condición, por lo que se puede aplicar algún retraso aquí.
• El enfoque gestionado por TIBCO requiere que el pod esté en ejecución todo el tiempo, por lo que utiliza más recursos cuando la condición no se alcanza. Así que en caso de que estés ejecutando contenedores sin estado como AWS Fargate o similar, la API de Cron JOB es una mejor opción.
• La API de CronJob es una API estándar de Kubernetes, lo que significa que se integra completamente con el ecosistema, mientras que el enfoque gestionado por TIBCO es gestionado por TIBCO usando configuraciones de aplicación.
• El enfoque gestionado por TIBCO no es consciente de otras instancias de la misma aplicación en ejecución, por lo que gestionas mantener una sola instancia en ejecución para evitar ejecutar la misma lógica muchas veces. En el caso de la API de Cron Job, esto es gestionado por la propia plataforma de Kubernetes.