Gestionando workflows en modo serverless

Workflows es uno de los servicios de Google Cloud que menos tiempo lleva en el mercado. Se trata de un servicio serverless de gestión de flujos de trabajo de Google Cloud. Como habréis podido apreciar no se han roto la cabeza con el nombre, personalmente me parece estupendo, ya que cada día son más los productos y recordar todos ellos empieza a ser un poco complicado.

En este post vemos cómo este servicio empieza siendo sencillo en su nombre, a continuación vamos a descubrir si el resto del producto es igual o si la cosa se complica...

¿Qué son los workflows?

Wikipedia define un workflow o flujo de trabajo como “un patrón de actividades orquestado y repetible”. Dicho de otra manera, un conjunto de acciones que se desarrollan de una manera determinada.

Gracias a Workflows vamos a poder orquestar llamadas a servicios y ejecutarlos sin necesidad de tener servidores dedicados, de forma robusta, con escalado automático y pagando solo por el uso que hagamos.

Como la mayoría de servicios cloud, una de las premisas de este producto es descargar de trabajo a los desarrolladores para que puedan dedicar el máximo tiempo en procesos que realmente aporten valor.

Para este primer vistazo al producto vamos a ver sus principales características y algunos ejemplos, de forma que nos hagamos una idea del potencial de este servicio y nos sea más fácil empezar a crear nuestros propios workflows.

Principales características

• Ejecución fiable incluso para llamadas síncronas. Workflows es serverless, pero no tiene tiempos de calentamiento de forma que la ejecución de un workflow tardará siempre lo mismo (no así las llamadas que haga). Al ser un producto gestionado, nos aseguramos que una vez lanzado el workflow se ejecutará de manera robusta.
• Servicio Serverless: escala automáticamente sin necesidad de ninguna gestión de las máquinas, además solo pagas cuando lo usas.
• Gestión integrada de errores y reintentos. Pudiendo definir la política de reintentos (por ejemplo un backoff exponencial).
• Autentificación automática para servicios Google Cloud: APIs, Functions, Cloud Run…
• Logs integrados. Como el resto de servicios de Google Cloud, podemos gestionar los logs de manera unificada dentro de la plataforma.

¡Pasemos a la práctica!

Ejemplo 1: llamadas a Google Cloud y servicios externos

Aunque Workflows encaja a la perfección con los servicios de Google, es perfectamente capaz de hacer peticiones Http a otros servicios. En este primer ejemplo vamos a preguntar a Gravatar (servicio unificado de avatares) cómo obtener la información de perfil de un determinado email.

Para poder hacer la llamada antes vamos a tener que obtener el email codificado en md5, lo que solucionaremos haciendo una llamada a una cloud function.

Usar el API de Gravatar es muy sencillo, solo es necesario hacer una petición GET indicando el hash (md5) del email del usuario. Aquí puedes ver un ejemplo de llamada GET para obtener los datos de un usuario en formato json.

La función para codificar en MD5 es muy sencilla, os dejo el código aquí. De momento dejemos la función pública para poder acceder sin seguridad, más adelante veremos cómo hacer las llamadas seguras de manera fácil.

Una vez creada la función iremos al apartado de Workflows y crearemos uno, cuando nos pidan el código:

- getHashFromEmail:
   call: http.get
   args:
       url: ${"https://europe-west1-sandbox-262410.cloudfunctions.net/md5en?message=" + args.email}
   result: md5hash
- getGravatarInfo:
   call: http.get
   args:
       url: ${"https://en.gravatar.com/" + md5hash.body.hash + ".json"}
   result: resultGravatar
- returnOutput:
   return: ${resultGravatar.body.entry[0].thumbnailUrl}

Ahora vamos a explicar qué hemos puesto en nuestro código. Como vemos, nuestro workflow solo tiene 3 pasos (getHashFromEmail, getGravatarInfo y returnOutput).

En los dos primeros hacemos llamadas muy simples a una cloud function (llamada interna) y a un API externa. Las llamadas tienen la misma sintaxis de forma que no hay mucha diferencia entre llamar a servicios de Google o de fuera, el precio de las llamadas sí puede variar.

Una vez creado lo ejecutamos pasando como parámetros de ejecución {“email”: “[email protected]”}. Es una cuenta de ejemplo pero podéis poner otra que tenga cuenta en Gravatar.

Cuando ya se ha ejecutado solo hay que refrescar la web (el workflow es casi instantáneo) y veremos por pantalla el resultado de la llamada. ¡Nuestro primer workflow se ha ejecutado con éxito!

Ejemplo 2: pasos condicionales y llamadas a Gcloud

Ahora que ya hemos creado nuestro primer workflow vamos a centrarnos en añadir lógica entre nuestros pasos y cómo hacer llamadas a Google Cloud autenticadas.

En este segundo ejemplo vamos a simular el onboarding de un nuevo empleado en una compañía imaginaria. En esta compañía cada usuario del departamento de marketing (dep = MKT) tiene asignado nada más entrar un bucket en cloud storage para que almacene lo que necesita.

Para cumplir este requisito nuestro workflow mirará el departamento y, si es uno de los seleccionados, realizará una llamada al API de Cloud Storage para crear un bucket. En caso de ser de otro departamento finalizará sin hacer nada.

Vamos a ver primero la definición del workflow:

- conditionalSwitch:
   switch:
       - condition: ${args.dep == "MKT"}
         next: createBucket
       - condition: ${args.dep != "MKT"}
         next: normalExit
   next: normalExit
- normalExit:
   return: "No necesita bucket"
- createBucket:
   call: http.post
   args:
       url: https://storage.googleapis.com/storage/v1/b?project=sandbox-262410
       auth:
           type: OAuth2
       body:
           name: ${"sandbox-262410-" + args.name}
           location: europe-west1
           storageClass: STANDARD

   result: createResponse
   next: endstep
- endstep:
   return: "Creado el bucket con éxito"

Primer paso: conditionalSwitch

En el paso conditionalSwitch vemos cómo se añade la lógica para ir a un paso u otro dependiendo del departamento. También vemos cómo con la propiedad next podemos seleccionar el próximo paso en caso de que no se cumpla ninguna de las condiciones.

La propiedad next se puede poner en todos los pasos opcionalmente, sino se indica se saltará al próximo paso de la lista.

Segundo paso: normalExit

Este paso solo se ejecutará si el usuario es de un departamento distinto a marketing y, como tiene definido un return, cuando se ejecute se terminará el workflow y no continuará la ejecución.

Tercer paso: createBucket

En el paso createBucket vemos cómo realizar una llamada al API de Cloud Storage para crear un nuevo bucket, indicamos el tipo de auth que queremos y añadimos los parámetros, ¡más fácil imposible!

Al final indicamos con next el próximo paso, como justo indicamos el siguiente paso la linea no hace mucho. Por último, el paso final nos devuelve un texto indicando que se ha creado correctamente el bucket de datos para nuestro nuevo empleado.

Ejemplo 3: reintentos y autentificación para Functions/Run

Como último ejemplo vamos a ver cómo configurar una llamada a un API para implementar un sistema de reintentos, y de paso vamos a ver como hacer para llamar a cloud functions o cloud run de manera segura gracias a la autenticación por OIDC en lugar de OAuth2.

En este ejemplo simularemos una llamada a una cloud function que falla mucho, concretamente las 4 primeras veces que llamemos a la función por instancia. Lo primero que tenemos que hacer es crear la función, esta vez limitando las llamadas para que no se pueda llamar sin estar autenticado. Os dejo el código aquí.

Veamos ahora el workflow:

- main:
   try:
       steps:
           - startBackendCall:
               call: http.get
               args:
                   url: https://europe-west1-sandbox-262410.cloudfunctions.net/simulate-fail
                   auth:
                       type: OIDC
               result: myResponse
   retry:
       max_retries: 8
       backoff:
           initial_delay: 1
           max_delay: 60
           multiplier: 2
- endstep:
   return: ${myResponse}

En código podemos ver cómo hay un nuevo nivel de agrupamiento para el paso startBackendCall, esto es necesario para añadir una política de reintentos. Al mismo nivel que el grupo de pasos con try añadimos un nuevo bloque retry con la definición de la política de reintentos.

En este caso hemos optado por un backoff exponencial que va multiplicando por 2 los tiempos entre llamada y llamada hasta un máximo de 8 llamadas con un tiempo de espera entre llamadas que irá aumentando hasta 60 segundos.

Para finalizar

En este post hemos aprendido un poco sobre este nuevo servicio, por qué nos puede resultar interesante, cuáles son sus principales características y unos ejemplos donde hemos visto de manera práctica cómo dar los primeros pasos. Ahora solo queda empezar a usarlo en casos reales, aprovechando al máximo sus funcionalidades y ventajas.

Así terminamos este primer contacto con el servicio de Workflows, un servicio que puede ayudarnos a hacer nuestro día a día más fácil. Un servicio al que le deseamos una larga vida cargada de novedades.