Уявіть: мікросервісна архітектура, де 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 та логістиці. Отримайте консультацію безкоштовно — просто напишіть нам.