Temporal o Step Functions: las transiciones no cuentan el mismo trabajo

Para elegir entre Temporal y AWS Step Functions, hay que comparar el mismo comportamiento ante éxito, fallo y espera, y calcular cada opción con sus propias unidades. Step Functions Standard conviene cuando el proceso encaja en estados e integraciones de AWS; Temporal permite escribir el Workflow como código, con Workers que ejecuta el equipo. La documentación de AWS explica que Standard se define mediante Amazon States Language y se factura por transiciones de estado.

Una transición no equivale automáticamente a una acción de Temporal Cloud. El catálogo de acciones de Temporal Cloud incluye inicios de Workflows, Activities, temporizadores y señales, mientras que la reproducción del historial en un Worker no genera por sí sola nuevas acciones facturables. Esa diferencia cambia el cálculo de un flujo que reintenta tareas o espera una respuesta externa.

Qué cuenta cada motor

En Step Functions Standard, la unidad es cada transición de estado ejecutada. El recorrido real importa: una rama omitida no consume las transiciones de esa rama, mientras que un reintento configurado añade una transición. La definición concreta puede contener estados de tarea, decisión o espera, además de las llamadas de negocio que el usuario percibe.

Temporal Cloud cobra acciones asociadas a operaciones del servicio. Programar una Activity, volver a intentarla, iniciar un temporizador o enviar una señal son conceptos distintos en su catálogo. Un heartbeat de una Activity cuenta cuando llega al servidor; no basta con que el código del Worker intente enviarlo. Además, el historial de eventos ocupa almacenamiento aunque su reproducción para reconstruir un Workflow no se facture como otra acción.

La unidad de cobro tampoco describe por completo el trabajo externo. Si un estado de Step Functions invoca Lambda o una Activity de Temporal llama a un procesador de pagos, esa ejecución y cualquier repetición de la llamada tienen su propio coste y sus propios efectos. Para comparar motores, el resultado de negocio y la política de reintentos deben ser los mismos; las unidades internas pueden seguir siendo diferentes.

Tres flujos con las unidades oficiales

Estos modelos son hipotéticos y sirven para descomponer una factura, no para atribuir un rendimiento medido a ninguno de los servicios. En cada recorrido conviene separar las operaciones de orquestación de las llamadas externas y contar también las variantes que terminan en error.

• Flujo simple. Supongamos que una reserva se crea y luego se confirma. Una máquina Standard puede representar esas tareas como estados sucesivos y cobrar las transiciones del recorrido definido, incluidos los estados de control que ejecute. En Temporal Cloud, un Workflow que programa dos Activities registra, como base, una acción de inicio y una por cada Activity programada. Las dos operaciones de negocio no bastan para deducir cuántas transiciones tendrá la máquina Standard.
• Flujo con reintento. Si la creación de la reserva falla una vez y la política ordena repetirla, Standard añade la transición del reintento. Temporal Cloud añade la acción correspondiente al reintento de la Activity; los heartbeats que lleguen al servicio pueden incrementar el total. La reserva externa también puede haberse intentado más de una vez, con independencia de las unidades que cobre el orquestador.
• Saga larga. Supongamos una autorización, una espera con plazo para recibir una señal externa y una compensación si llega una cancelación. Standard cuenta los estados efectivamente recorridos: autorización, decisión, espera y, en la rama cancelada, compensación, según la máquina diseñada. Un diseño de Temporal Cloud suma el inicio del Workflow, la Activity de autorización, el temporizador, la señal recibida y la Activity de compensación en esa rama. Otras consultas, Activities o reintentos añadirían acciones; el historial permanecería activo mientras el Workflow siguiera abierto.

Una estimación mensual necesita la frecuencia de cada camino, no solo un promedio de pasos por ejecución. Si las cancelaciones y los fallos recorren estados o Activities distintos, se multiplican sus unidades por el volumen previsto de cada variante y después se suman. Esa separación deja visible cuándo un cambio de política de reintentos altera tanto la orquestación como el consumo del servicio invocado.

Cómo pasan esas unidades a la factura

La tarifa de Step Functions Standard fija para Virginia del Norte 0,000025 dólares por transición después de 4.000 transiciones gratuitas al mes e incluye los reintentos en el recuento. Para ese escenario, la parte de orquestación es el total mensual de transiciones que supera el tramo gratuito multiplicado por la tarifa. AWS cobra aparte los servicios utilizados por el flujo, como las invocaciones de Lambda; otras regiones pueden tener precios distintos.

La tarifa publicada de Temporal Cloud parte de 50 dólares por millón de acciones y añade 0,042 dólares por GB-hora de historial activo de Workflows abiertos y 0,00105 dólares por GB-hora de historial retenido de Workflows cerrados. El importe combina acciones y volumen de historial durante el tiempo que permanece en cada categoría. La página también contempla descuentos por volumen y complementos, de modo que la tarifa inicial no sustituye las condiciones de una contratación concreta.

La espera larga ilustra la diferencia: en Standard el tiempo transcurrido no se convierte por sí mismo en una tarifa de duración de la orquestación, aunque los estados recorridos y servicios adicionales sí cuentan. En Temporal Cloud, una espera puede sumar la acción del temporizador y mantener historial en almacenamiento activo; su peso depende de los bytes conservados y de cuánto permanezca abierto el Workflow. Comparar únicamente 0,000025 dólares por transición con el precio por acción ocultaría esa dimensión.

Recuperación y dependencia del proveedor

Standard conserva la ruta de una ejecución en su historial y ofrece reintentos definidos en la máquina de estados. Temporal reconstruye el estado del Workflow reproduciendo su historial en un Worker tras una interrupción. En ambos casos, una llamada externa que pueda repetirse exige decidir cómo evitar efectos duplicados, por ejemplo mediante una clave de idempotencia aceptada por el servicio llamado.

El modelo de programación también afecta a los cambios durante procesos largos. En Step Functions se modifica una definición de estados y sus integraciones; en Temporal se despliega código de Workflow y Activities. Las ejecuciones abiertas de Temporal obligan a cuidar la compatibilidad del código con historiales anteriores. Step Functions mantiene la orquestación dentro de AWS, mientras que Temporal permite elegir entre su servicio gestionado y uno autogestionado; trasladar un flujo ya construido entre motores requiere adaptar su definición y sus integraciones.

La operación completa la elección

La guía de despliegue de Temporal indica que el código de la aplicación y sus Workers se ejecutan en infraestructura del usuario tanto con Temporal Cloud como con un servicio Temporal autogestionado. Elegir esta última modalidad añade la responsabilidad de mantener el propio servicio. Su coste incluye infraestructura, persistencia, supervisión, actualizaciones y tiempo del equipo, aunque no exista una factura de acciones de Temporal Cloud.

Standard ofrece una cuenta más directa cuando el equipo ya usa servicios de AWS y puede expresar el proceso como estados. Temporal cobra sentido cuando la lógica del Workflow en código, la recuperación mediante historial y la posibilidad de alojar el servicio pesan más para el proyecto. La comparación económica válida suma, para cada diseño, orquestación, llamadas externas, almacenamiento aplicable y trabajo de operación bajo las mismas reglas de fallo y espera.

Lee también:

• VS Code 1.134 ordena los chats de agentes y deja comparar su trabajo
• Google Workspace o Microsoft 365: el almacenamiento no cuenta toda la factura
• GitHub Copilot o JetBrains AI: el mismo precio compra cuotas e IDE distintos