Step Functions para no morir. Parte 1: Inicio

Giuliana Olmos - Feb 1 '22 - - Dev Community

Buenas! Este post va a ser el primer capítulo de una serie, en la que voy a explicar las Step Functions de AWS. Algunos capítulos van a contener exclusivamente contenido teórico, y otros contenido practico, en esos, voy a incluir videos para que se entienda mejor.

En este post vamos a ver:

  • ¿Que son las step Functions?
  • Cuales son sus ventajas.
  • Casos de usos.
  • Ejemplo.

¿Qué son las Step Functions?

Good Luck Charly Meme

Si tomamos la definición de la documentación de AWS, una Step Function es un servicio de orquestación sin servidor que le permite combinar funciones Lambdas y otros Servicios para crear aplicaciones críticas para el negocio. A través de la consola gráfica de Step Functions, puede ver el flujo de trabajo de su aplicación como una serie de pasos basados en eventos.

Las Step Functions se basan en máquinas y tareas de estado. Una máquina de estado es un flujo de trabajo. Una tarea es un estado de un flujo de trabajo que representa una única unidad de trabajo que está realizando otro servicio de AWS. Cada paso de un flujo de trabajo es un estado.

Es decir, las step Functions sirven para orquestar diseñar flujos de trabajo utilizando los distintos servicios que ofrece AWS.

Ventajas

Trabajar con Step Functions trae diversas ventajas, entre ellas:

  • Se ejecutan en la nube, es decir, no hay una infraestructura que necesite ser mantenida.
  • Son autoescalables, cada consulta crea una nueva instancia para que procese el flujo de trabajo.
  • Su definición gráfica es parecida a un diagrama de flujo, lo que permite una administración más simple.
  • Al pertenecer al proveedor AWS, puede ser integrada con otros servicios para tener una aplicación más compleja.
  • Son aptas para la arquitectura de microservicios.

Casos de uso de las steps.

La idea de orquestar step functions es la de escribir menos código, para así poder centrarse en crear y actualizar la aplicación.
Una aplicación puede contener distintos flujos combinados.
Por ejemplo:

Orquestación secuencial

Este tipo de diseño lo utilizamos cuando queremos que nuestra aplicación ejecute los pasos en un orden especifico.
Lambda Secuencial

Ramificación

Puede utilizarse de dos maneras.

  • Bifurcación: Dependiendo de una o más variables podemos elegir por cual flujo se va continuar la secuencia. (El if de toda la vida)
  • Paralelismo: Podemos hacer que la secuencia se divida en dos flujos que se ejecuten al mismo tiempo.

Flujo Ramificado

Control de errores

Utilizando en la configuración las palabras retry y catch podemos reintentar una tarea en caso de error, o bifurcar el camino para que se pueda manejar ese error.

Manejo de errores

Tareas Manuales

Estos son pasos en el flujo de la state machine que una vez ejecutados se quedan a la espera de una confirmación externa para poder continuar con la secuencia.
Aclaración: Pienso dedicar un capitulo entero a explicar este tipo de flujo.

Tareas Manuales

Ejemplo de State Function

La siguiente imagen es un ejemplo de una Step Function que combina distintos casos de uso.

Ejemplo Step Function

Esta flujo de trabajo corresponde a un proceso de pago.
El primer step es de tipo Choice, y va a encargarse de encaminar el flujo a la opción correspondiente, dependiendo de si el pago es por debito o crédito.
Los siguientes step son lambdas que se van a encargar de procesar el pago.
En el caso en el que alguna transacción no pueda ser realizada, tenemos un manejo de errores mediante un catch que redirecciona el flujo a la lambda que va a formatear ese error.
El ultimo step se va a encargar de enviar el mensaje (transacción exitosa o fallida) al cliente mediante una cola de SQS.

En fin

Smiling dog GIF
Este ha sido un pantallazo general de lo que vamos a estar viendo en los siguientes capítulos.
Si tienen alguna duda, pueden dejarla en los comentarios.
Voy a estar publicando esta serie una vez por semana.

Si el post les fue útil, pueden invitarme un cafecito.
Invitame un café en cafecito.app

. . . . . . . . . . . . .