A workflow engine runs a multi-step process for you and remembers where it got to. If a step fails, it retries. If the machine running it dies, another picks up from the last completed step. If the process has to wait three days for a human or a webhook, the engine waits, without a thread sitting idle. That's exactly what the course's sagas, orchestration and scheduled jobs lessons ask for, and the clouds offer two very different ways to get it.
One family describes the workflow as data: a state machine in JSON or YAML that the cloud interprets (Step Functions, Google Workflows, Logic Apps). The other writes the workflow as code in a normal language and makes it durable by recording every step and replaying it after a crash (Azure Durable Functions, Temporal). The choice between them matters more than the choice of cloud.
Side by side
| AWS Step Functions | Google Workflows | Azure Durable Functions / Logic Apps | Temporal (self-hosted or Temporal Cloud) | |
|---|---|---|---|---|
| How you write it | A JSON state machine (Amazon States Language) | A YAML or JSON definition | Durable Functions: code orchestrators; Logic Apps: designer-based definitions | Code, in Go, Java, TypeScript, Python and more |
| Longest run | 1 year (Standard), 5 minutes (Express) | 1 year | Long-running, with durable timers | Long-running; very long ones restart with continue-as-new |
| Size limits | 256 KiB per state's input or output; 25,000 history events per Standard execution | 512 KB of variables; 100,000 steps per execution | Bounded by the storage provider and history size | History hard limit of 51,200 events or 50 MB |
| How it survives crashes | The service records each state transition | The service keeps execution state | Event sourcing and replay | Event history and replay |
| What you pay per | Standard: state transitions; Express: requests and duration | Usage; an idle workflow costs nothing | Functions execution, plus storage | Your cluster, or Temporal Cloud usage |