Step Functions (workflow déclaratif managé)
Décrire un workflow en JSON déclaratif (Amazon States Language) et laisser un service managé (AWS Step Functions, Google Cloud Workflows) exécuter, retenter, paralléliser. Le pattern de workflow sans infrastructure à maintenir.
Problème
Maintenir un cluster Temporal, un cluster Camunda ou un Airflow self-hosted impose une équipe ops dédiée : monitoring, upgrades, backup, scaling, sécurité. Pour des workflows EDI modérément complexes (10-30 étapes), l'overhead opérationnel excède la valeur. On voudrait définir le workflow simplement et laisser le runtime au cloud provider.
Forces
- Maintenir un workflow engine a un coût : installation, monitoring, upgrades, scaling.
- Les workflows EDI peuvent être nombreux mais simples : 10-30 étapes, sans logique sophistiquée.
- L'intégration native cloud est appréciable : Lambda, S3, SQS, SNS s'enchaînent naturellement.
- Le format déclaratif facilite l'audit : le JSON ASL se relit, se versionne, se diff.
- La facturation à l'usage : pas de coût en l'absence de flux, scale horizontal géré.
Solution
AWS Step Functions définit un workflow en Amazon States Language (ASL), un sous-ensemble JSON typé. Chaque state est un Task (appel Lambda, ECS, etc.), Wait (timer), Choice (branchement), Parallel (exécution parallèle), Map (fan-out), Pass, Succeed, Fail. Le runtime AWS exécute, gère retries (avec policy déclarative), timeouts, persistance. Google Cloud Workflows offre l'équivalent avec un YAML similaire. Azure Logic Apps est un cousin avec UI visuelle.
Définition ASL JSON d'un workflow EDI :
{
"StartAt": "ParseInvoice",
"States": {
"ParseInvoice": {
"Type": "Task",
"Resource": "arn:aws:lambda:...:parse-invoice",
"Next": "ValidateInvoice"
},
"ValidateInvoice": {
"Type": "Task",
"Resource": "arn:aws:lambda:...:validate-invoice",
"Retry": [{ "ErrorEquals": ["States.ALL"],
"IntervalSeconds": 2,
"MaxAttempts": 3,
"BackoffRate": 2.0 }],
"Catch": [{ "ErrorEquals": ["ValidationError"],
"Next": "SendApErak" }],
"Next": "RouteToErp"
},
"SendApErak": { "Type": "Task", ..., "End": true },
"RouteToErp": { ..., "Next": "AwaitErpAck" },
"AwaitErpAck": { "Type": "Wait", "Seconds": 3600,
"Next": "CheckAck" },
"CheckAck": { "Type": "Choice", ... },
...
}
}
Le runtime AWS Step Functions exécute ce JSON,
gère retries, timeout, parallélisme, parallel branches.
Implémentation EDI
Cas concret : workflow de traitement d'INVOIC entrant.
Chaque étape est une Lambda : parse-invoice, validate-invoice,
route-to-erp, await-erp-ack, archive-to-s3. Le JSON ASL définit
l'enchaînement, les retries (3 tentatives backoff exponentiel),
les catch d'erreurs (validation error → SendAperak →
Notification). Le tout est versionné en GitOps. Le déploiement
se fait via Terraform avec ressource aws_sfn_state_machine.
Le coût : ~25¢ pour 1000 state transitions (Standard
workflow) ou 1¢ pour 1000 transitions (Express workflow). Pour
100k factures/mois avec 10 transitions chacune, coût ~250$/mois
en Standard. La console AWS Step Functions visualise chaque
exécution avec timeline détaillée. Pour les workflows plus
complexes (logique conditionnelle riche, code custom), Temporal
reste préférable. Pour les workflows simples cloud-native, Step
Functions est imbattable en TCO.
Anti-patterns
- Workflow trop volumineux : ASL JSON de 5000 lignes pour un workflow avec 200 états → ingérable, illisible. Découper en sous-workflows.
- Logique métier dans le workflow : ASL n'est pas un langage de programmation. Mettre la logique dans les Lambdas, garder le workflow purement orchestration.
- Pas de versionning : modifier en console sans Git → audit impossible, rollback douloureux.
- Coût Standard pour workflows courts : Standard facture chaque transition cher pour workflows < 5min. Pour ces cas, Express Workflows.
- Lock-in cloud : ASL est propriétaire AWS, les Google Cloud Workflows et Azure Logic Apps ont des syntaxes différentes. Architecture cloud-agnostique difficile.
- Pas de tests locaux : difficile de tester un workflow sans déployer. Utiliser Step Functions Local pour tester.
Patterns liés
- Process Manager — pattern EIP parent.
- Temporal Workflow — variante code-first plus puissante.
- Process Engine — pattern parent, ici en mode SaaS managé.
- Saga Orchestration — pattern naturellement implémenté en Step Functions.
- Compensating Action — pattern à coder explicitement via Catch dans ASL.
Sources
- AWS Step Functions Developer Guide. La référence officielle. docs.aws.amazon.com — Step Functions
- Amazon States Language Specification. La grammaire formelle de ASL. states-language.net — spec
- Google Cloud Workflows Documentation. L'équivalent Google Cloud. cloud.google.com — workflows
- Azure Logic Apps Documentation. L'équivalent Microsoft Azure. learn.microsoft.com — logic-apps
- AWS Architecture Center — Serverless workflow patterns. Patterns d'usage Step Functions pour orchestration cloud. docs.aws.amazon.com — serverless-workflow-patterns
- Richardson C. — Microservices Patterns, Manning 2018. Chapitre 4 sur les Sagas et leur implémentation en orchestration ; Step Functions y est traité comme implémentation.