Уявіть: мікросервісна архітектура, де 15 Lambda-функцій послідовно обробляють замовлення — валідація, перевірка складу, розрахунок доставки, списання оплати, сповіщення. Якщо зв'язати їх прямими викликами, історія втрачається, помилки важко локалізувати, а при збої одного кроку весь процес зависає. Для фінтех-платформи з навантаженням 1000 замовлень/сек ми вирішили цю проблему, впровадивши оркестрацію через AWS Step Functions. Результат — скорочення часу обробки на 30% та повна прозорість кожного виконання. Такі ж результати показують 30+ проєктів, де ми застосовували оркестрацію: від e-commerce до FinTech. Середня економія на інфраструктурі досягає 40%, а окупність впровадження — 3-6 місяців.
Прямі виклики однієї Lambda з іншої — антипатерн: втрачається історія виконання, складно обробляти помилки, немає видимості прогресу. Оркестрація за допомогою Step Functions або Durable Functions вирішує проблеми N+1 запитів до баз даних, втрату стану та відсутність моніторингу. Наші інженери реалізували понад 30 проєктів з оркестрацією — від e-commerce до FinTech. Оцініть ваш проєкт за один день — пишіть, і ми підготуємо комерційну пропозицію.
Коли потрібна оркестрація замість прямих викликів?
Бізнес-процес складається з кількох кроків зі станом, потрібні умови розгалуження (if step_A succeeded, then step_B, else step_C), паралельне виконання кількох функцій з очікуванням результату, довготривалі процеси (>15 хвилин для Lambda) або людське підтвердження на якомусь кроці (wait for callback). У всіх цих випадках прямі виклики призводять до спагеті-коду та проблем з налагодженням.
Function Composition як рішення проблем serverless-оркестрації
Оркестратор бере на себе маршрутизацію, повторні спроби та збір метрик. Замість десятків викликів з коду ви описуєте workflow декларативно. Це спрощує налагодження — кожне виконання можна простежити крок за кроком у консолі. При збої система автоматично повторює крок або переходить до компенсуючої дії. За нашими оцінками, впровадження оркестрації знижує витрати на інфраструктуру до 40% за рахунок оптимізації викликів. Порівняйте: пряме зв'язування Lambda вимагає 15 викликів на замовлення з ризиком таймаутів, оркестратор же виконує ті ж кроки з гарантованою обробкою помилок у 5 разів швидше.
AWS Step Functions: практичний приклад
Приклад State Machine (ASL)
{
"Comment": "Обробка замовлення",
"StartAt": "ValidateOrder",
"States": {
"ValidateOrder": {
"Type": "Task",
"Resource": "arn:aws:lambda:us-east-1:123:function:validate-order",
"Next": "CheckInventory",
"Retry": [{"ErrorEquals": ["Lambda.ServiceException"], "MaxAttempts": 3}],
"Catch": [{
"ErrorEquals": ["ValidationError"],
"Next": "NotifyInvalidOrder"
}]
},
"CheckInventory": {
"Type": "Parallel",
"Branches": [
{"StartAt": "ReserveItems", "States": {"ReserveItems": {"Type": "Task", "Resource": "arn:...:reserve-items", "End": true}}},
{"StartAt": "CalculateShipping", "States": {"CalculateShipping": {"Type": "Task", "Resource": "arn:...:calc-shipping", "End": true}}}
],
"Next": "ProcessPayment"
},
"ProcessPayment": {
"Type": "Task",
"Resource": "arn:aws:states:::lambda:invoke.waitForTaskToken",
"Parameters": {
"FunctionName": "arn:...:process-payment",
"Payload": {
"taskToken.$": "$$.Task.Token",
"orderId.$": "$.orderId"
}
},
"Next": "FulfillOrder",
"TimeoutSeconds": 300
},
"FulfillOrder": {"Type": "Task", "Resource": "arn:...:fulfill-order", "End": true},
"NotifyInvalidOrder": {"Type": "Task", "Resource": "arn:...:notify-invalid", "End": true}
}
}
.waitForTaskToken дозволяє Step Functions чекати callback від зовнішньої системи (наприклад, платіжного шлюзу) без постійного опитування. Платіжний шлюз викликає SendTaskSuccess з токеном, коли транзакція завершена.
Terraform для Step Functions
resource "aws_sfn_state_machine" "order_processing" {
name = "order-processing"
role_arn = aws_iam_role.sfn_role.arn
definition = templatefile("${path.module}/state_machine.json", {
validate_lambda_arn = aws_lambda_function.validate_order.arn
reserve_lambda_arn = aws_lambda_function.reserve_items.arn
payment_lambda_arn = aws_lambda_function.process_payment.arn
fulfill_lambda_arn = aws_lambda_function.fulfill_order.arn
})
logging_configuration {
log_destination = "${aws_cloudwatch_log_group.sfn.arn}:*"
include_execution_data = true
level = "ERROR"
}
tracing_configuration {
enabled = true # X-Ray tracing
}
}
Порівняння: AWS Step Functions vs Azure Durable Functions
| Характеристика | AWS Step Functions | Azure Durable Functions |
|---|---|---|
| Максимальна тривалість | 1 рік | Необмежено (перевірки кожні 10 сек) |
| Візуалізація виконання | Вбудована консоль | Application Insights |
| Ціноутворення | $0.025/1k переходів (Standard) | Плата за execution time + storage |
| Інтеграція з мовами | JSON/ASL | C#, Python, JavaScript, F# |
| Умовна компіляція | Ні | Так (if/else в коді) |
Ваш вибір залежить від екосистеми: якщо ви на AWS — Step Functions, якщо на Azure — Durable Functions. У випадку мультихмари можна використовувати єдиний оркестратор на базі Temporal або Camunda, але це виходить за рамки serverless.
Azure Durable Functions: альтернатива
.NET / Node.js / Python оркестратор на базі Azure Functions:
import azure.durable_functions as df
def orchestrator_function(context: df.DurableOrchestrationContext):
parallel_tasks = [
context.call_activity("ReserveItems", context.get_input()),
context.call_activity("CalculateShipping", context.get_input())
]
results = yield context.task_all(parallel_tasks)
approval = yield context.wait_for_external_event("ApprovalReceived")
if approval:
return (yield context.call_activity("FulfillOrder", context.get_input()))
else:
return (yield context.call_activity("CancelOrder", context.get_input()))
main = df.Orchestrator.create(orchestrator_function)
Durable Functions використовують Azure Storage для зберігання стану. Оркестратор може чекати зовнішньої події необмежено довго.
Як обробляти помилки в оркестрації?
У розподілених процесах немає вбудованих транзакцій. Патерн Saga — компенсуючі дії при відмові:
"ProcessPayment": {
"Type": "Task",
"Resource": "...",
"Catch": [{
"ErrorEquals": ["PaymentFailed"],
"Next": "CompensateReservation"
}]
},
"CompensateReservation": {
"Type": "Task",
"Resource": "arn:...:release-reservation",
"Next": "NotifyPaymentFailed"
}
Кожен крок, який потрібно відкотити при помилці, має компенсуючу функцію. Видимість забезпечується через CloudWatch Metrics та X-Ray для Step Functions, а для Durable Functions — Application Insights.
Express vs Standard Workflows
| Standard | Express | |
|---|---|---|
| Тривалість | До 1 року | До 5 хвилин |
| Execution history | Повна | CloudWatch Logs |
| Ціна | $0.025/1k transitions | $0.00001/state transition |
| Підходить для | Бізнес-процеси | High-volume, short workflows |
Standard Workflows у 2500 разів дорожчі за Express Workflows за перехід, але підтримують довгі процеси з повним аудитом. Для проєктів з навантаженням понад 10 000 викликів на день вигідніше Express.
Що входить в роботу
- Архітектурна документація з описом workflow та всіх функцій.
- Код оркестратора та лямбда-функцій (або Azure Functions) у вашому репозиторії.
- Інфраструктурний код (Terraform / Bicep) для розгортання.
- Налаштований моніторинг та алерти (CloudWatch / Application Insights).
- Доступ до репозиторію та інструкції з розгортання.
- Навчання вашої команди роботі з оркестратором.
Процес роботи та терміни
- Проектування state machine + ASL опис — 2–3 дні.
- Lambda функції для кожного кроку — 3–7 днів.
- Step Functions state machine + IAM — 2–3 дні.
- Обробка помилок + компенсації — 2–3 дні.
- Моніторинг + алерти + тестування — 2–3 дні.
Зв'яжіться з нами для консультації — замовте реалізацію Function Composition під ключ. Пишіть, і отримайте комерційну пропозицію з детальним планом протягом одного дня. Наш досвід підтверджують 30+ успішних впроваджень у фінтесі, e-commerce та логістиці. Отримайте консультацію безкоштовно — просто напишіть нам.