Чистая архитектура для Serverless: изоляция бизнес-логики и уход от vendor lock-in

Привязка к конкретному облачному провайдеру — одна из главных проблем serverless-архитектур. Разработчики часто оказываются в ситуации, когда бизнес-логика тесно переплетается с инфраструктурным кодом, что делает миграцию между облаками дорогой и трудоемкой. Однако существует проверенное решение: сочетание Clean Architecture, Spring Cloud Function и Gradle позволяет создавать переносимые serverless-сервисы, которые можно развернуть на AWS Lambda, Azure Functions или Google Cloud Functions без изменения бизнес-логики. Этот подход, продемонстрированный экспертом по облачным технологиям Еленой ван Энгелен на конференции InfoQ, помогает избежать vendor lock-in и сохранить гибкость при выборе облачной платформы.

Чистая архитектура для Serverless: изоляция бизнес-логики

Ключевая идея доклада — разделение приложения на слои, где бизнес-логика находится в самом центре и не зависит от внешних фреймворков, баз данных или облачных API. Елена ван Энгелен предложила структуру на основе Gradle-модулей: core (бизнес-логика), application (use cases), infrastructure (адаптеры для баз данных, сообщений и т.д.) и adapter (облачные функции). Такой подход позволяет переиспользовать бизнес-логику при смене провайдера — достаточно заменить только адаптерный слой. Spring Cloud Function выступает в роли универсального интерфейса, который абстрагирует конкретную облачную функцию (AWS Lambda, Azure Function, Google Cloud Function).

Почему важно изолировать бизнес-логику в serverless?

Изоляция бизнес-логики в serverless-архитектуре критична для долгосрочной гибкости. Когда код функции напрямую использует SDK конкретного облака (например, AWS SDK для работы с DynamoDB или Azure SDK для Cosmos DB), при переходе на другого провайдера придется переписывать не только инфраструктурные части, но и саму логику. Это увеличивает время и стоимость миграции, а также риск внесения ошибок. Чистая архитектура решает эту проблему, помещая бизнес-правила в независимый слой, который не знает о существовании облачных сервисов. В результате разработчики могут тестировать логику без развертывания в облаке, а при необходимости легко заменить один облачный сервис на другой.

Предыстория и контекст

Проблема vendor lock-in в serverless-мире давно беспокоит сообщество. Многие компании выбирают одного провайдера и строят всю архитектуру вокруг его проприетарных сервисов (например, DynamoDB для AWS или Cosmos DB для Azure). Когда возникает необходимость перейти на другую платформу или использовать мультиоблачную стратегию, разработчики сталкиваются с необходимостью переписывать значительную часть кода. Подход Clean Architecture, популяризированный Робертом Мартином, предлагает решение, но его применение в serverless-контексте требует дополнительных усилий. Елена ван Энгелен адаптировала эту архитектуру для FaaS, используя Spring Cloud Function — фреймворк, который позволяет писать функции, не зависящие от конкретной облачной платформы.

Как работает Spring Cloud Function в мультиоблачной среде?

Spring Cloud Function предоставляет единый API для написания функций, которые затем могут быть развернуты на любой поддерживаемой платформе (AWS, Azure, Google Cloud, локальный сервер). Функция реализует интерфейс java.util.function.Function, и фреймворк автоматически адаптирует ее под конкретную облачную среду. Например, для AWS Lambda генерируется обработчик, для Azure Functions — триггер. Это позволяет разработчикам сосредоточиться на бизнес-логике, а не на деталях интеграции с каждым провайдером. Spring Cloud Function также поддерживает реактивные типы и интеграцию с Spring Cloud Stream для работы с сообщениями, что расширяет его применимость.

Технические детали: Gradle, Terraform CDK и live demo

В ходе демонстрации Елена показала структуру многомодульного Gradle-проекта. Модуль core содержит чистую бизнес-логику на Kotlin, без зависимостей от облачных библиотек. Модуль adapter содержит классы, реализующие интерфейсы Spring Cloud Function для AWS Lambda и Azure Functions. Для развертывания использовался Terraform CDK (CDKTF) — инструмент, позволяющий описывать инфраструктуру как код с помощью языков общего назначения (в данном случае TypeScript). CDKTF генерирует конфигурации Terraform для AWS и Azure, что обеспечивает единообразное управление ресурсами. Демонстрация включала развертывание одного и того же приложения в обоих облаках, причем бизнес-логика оставалась неизменной. Елена отметила, что такой подход упрощает тестирование: модуль core можно тестировать изолированно с помощью юнит-тестов, а интеграционные тесты для adapter-модуля легко заменять заглушками.

Какие инструменты нужны для реализации мультиоблачного serverless?

Для реализации мультиоблачного serverless на основе Clean Architecture потребуется набор инструментов: Gradle для сборки многомодульного проекта, Spring Cloud Function для абстракции облачных функций, Terraform CDK для управления инфраструктурой как кодом, а также Kotlin или Java для написания бизнес-логики. Дополнительно могут понадобиться библиотеки для работы с базами данных (например, Spring Data) и сообщениями (Spring Cloud Stream), но их следует подключать только в модуле infrastructure. Важно, чтобы модуль core оставался свободным от любых внешних зависимостей, кроме стандартной библиотеки языка.

Кого затронет и как

Разработчики, использующие Kotlin и Spring, получат практический шаблон для создания переносимых serverless-приложений. Компании, стремящиеся к мультиоблачной стратегии или желающие избежать vendor lock-in, смогут снизить затраты на миграцию и повысить гибкость. Архитекторам стоит обратить внимание на подход с Gradle-модулями, который упрощает тестирование и поддержку кода. Для российского рынка, где активно используются как AWS, так и Azure (и даже Yandex Cloud), такой подход может быть особенно актуален — он позволяет строить независимые от провайдера решения. Кроме того, Clean Architecture способствует лучшей документации и пониманию кода новыми членами команды, так как границы между слоями четко определены.

Что будет дальше

Ожидается, что Spring Cloud Function продолжит развиваться, возможно, с добавлением поддержки новых облачных платформ. Инструменты вроде Terraform CDK будут улучшать интеграцию с serverless-сервисами. Сообщество Clean Architecture для serverless будет расти, появляться больше примеров и библиотек. Елена ван Энгелен планирует опубликовать код демонстрации в открытом доступе, что позволит разработчикам адаптировать его под свои нужды. Также вероятно появление дополнительных адаптеров для других облачных провайдеров, таких как Google Cloud Functions или Yandex Cloud Functions, что расширит возможности мультиоблачного развертывания.

Итог

Доклад Елены ван Энгелен предлагает практическое решение для одной из самых острых проблем serverless-архитектур — привязки к вендору. Использование Clean Architecture, Spring Cloud Function и Gradle-модулей позволяет изолировать бизнес-логику и развертывать ее на разных облачных платформах без изменений. Этот подход заслуживает внимания всех, кто строит современные облачные приложения и хочет сохранить гибкость. Начните с малого: выделите бизнес-логику в отдельный модуль, подключите Spring Cloud Function и используйте Terraform CDK для описания инфраструктуры — и вы получите переносимое serverless-решение, готовое к работе в любом облаке.