Serverless clean architecture помогает изолировать бизнес-логику и снизить зависимость от облака. Разберём, как это работает на практике и где возникают комприссы.
Основная проблема serverless-подхода проявляется не на старте, а при масштабировании архитектуры. Functions as a Service упрощает эксплуатацию: не нужно управлять инфраструктурой, патчами и масштабированием. Но вместе с этим появляется скрытая связность с конкретным провайдером. Точки входа, триггеры, SDK и даже модель деплоя отличаются между AWS и Azure. В результате бизнес-логика начинает “протекать” в инфраструктурный слой. Это особенно заметно при попытке переноса: код, который считался переносимым, требует доработок. Деградация начинается в момент, когда одна и та же функция реализуется по-разному из-за различий в триггерах и адаптерах.
Решение строится вокруг serverless clean architecture и идеи строгой изоляции бизнес-логики. Используется Spring Cloud Function как абстракция поверх FaaS. Он позволяет описывать функции как чистые вход-выход (input/output), а адаптацию к облаку выносить в отдельный слой. В комбинации с Gradle-модулями это даёт разделение: доменная логика, адаптеры под облака и инфраструктурный код (IaC). Это компромисс. Мы платим дополнительной сложностью сборки и структуры проекта, но выигрываем в переносимости. Важно, что Spring Cloud Function не устраняет полностью vendor lock-in. Он снижает его влияние, но cloud-specific код всё равно остаётся в адаптерах.
Реализация показывает, где проходят реальные границы абстракции. Для Azure функция объявляется с HTTP-триггером прямо в коде, включая базовую безопасность (API key). Для AWS триггер отсутствует в коде и определяется через API Gateway в Infrastructure as Code. Это принципиальное различие. В AWS также требуется явно указать handler и имя функции через переменные окружения. Эти детали нельзя унифицировать без потерь. Поэтому архитектура разделяет:
- бизнес-логику (чистые функции),
- cloud adapters (Spring Cloud Function для AWS и Azure),
- инфраструктуру (Terraform CDK).
Terraform CDK используется как единый слой управления инфраструктурой. Он генерирует Terraform-конфигурации через язык программирования. Это даёт единый способ описания ресурсов в разных облаках. Однако и здесь нет полной унификации: параметры функций, триггеры и конфигурации остаются специфичными. Архитектура не скрывает различия, а локализует их.
Отдельный инженерный аспект — модель масштабирования. В serverless масштабируется не сервис целиком, а отдельные функции. Это повышает эффективность (throughput) и снижает избыточное потребление ресурсов. Но требует более строгого разделения ответственности. Если функция делает слишком много, преимущества теряются. Это напрямую связано с clean architecture: чем чище границы, тем предсказуемее масштабирование.
Результаты такого подхода носят качественный характер. В исходных данных нет конкретных метрик latency или cost. Однако наблюдается снижение зависимости от одного облака и упрощение повторного использования бизнес-логики. Команда может деплоить одну и ту же логику в AWS и Azure с минимальными изменениями. При этом полностью избежать различий в реализации невозможно. Это ожидаемое ограничение.
В индустрии подобный подход рассматривается как прагматичный. Полная cloud-agnostic архитектура редко достижима без потерь в возможностях платформы. Поэтому акцент смещается на контроль точек зависимости. Serverless clean architecture не убирает lock-in, но делает его управляемым. Это особенно важно в условиях, когда требования к размещению и выбору облака могут меняться.