Эффективная миграция более 30 AWS Lambda с Serverless Framework с помощью LLM: опыт и рекомендации

Биткойн Альткойны

В современном мире разработки облачных приложений Serverless Framework долгое время был одним из самых популярных инструментов для создания и управления функциями AWS Lambda. Несмотря на его удобство и гибкость, с течением времени появились причины задуматься о миграции на более поддерживаемые и нативные решения, такие как AWS SAM. Этот материал рассказывает об опыте переноса более 30 Lambda функций, связанных с комплексным backend-приложением, а также о том, какую роль в этом процессе сыграли современные технологии больших языковых моделей (LLM). История началась около восьми лет назад, когда под backend для кроссплатформенного десктопного приложения на Qt/C++ было реализовано всего несколько Lambda функций, отвечающих за выдачу лицензий и подтверждение платежей. За годы объем сервера вырос до более чем 30 функций, среди которых webhook’и, cron-задачи для напоминаний, различные прокси-серверы, службы поддержки, AI inference и многое другое.

Изначально решение о выборе Serverless Framework принималось с расчетом на простоту и минимизацию затрат на инфраструктуру, поскольку основная логика находилась на стороне клиента — десктопного приложения. Однако за несколько лет управления таким количеством функций и ресурсов накопились сложности. Serverless Framework требовал многочисленных обходных маневров, множество кастомных CloudFormation шаблонов дополняли ограниченный функционал платформы. Появлялись недокументированные «хаки», а некоторые важные возможности были реализованы лишь через сторонние плагины, многие из которых давно не поддерживались. К тому же, компания-разработчик постепенно изменила модель лицензирования и убрала поддержку сторонних облаков, усиленно фокусируясь на AWS, что привело к усилению vendor lock-in.

Появление предупреждений о прекращении поддержки используемой версии Serverless Framework и появление вопросов с безопасностью заставили задуматься о миграции. В связи с этим был поставлен вопрос: на что переходить? Среди вариантов были Pulumi, Terraform, AWS CDK и серверлес-приложение AWS SAM. Первые две платформы подразумевают использование внешних провайдеров или довольно большие изменения в архитектуре. CDK требует написания кода инфраструктуры на одном из поддерживаемых языков программирования, включая не обошедшую стороной сложности с зависимостями JavaScript-пакетов даже при выборе Go. В итоге выбор пал на более зрелый и декларативный AWS SAM.

AWS SAM оказался достаточно близким по концепции к Serverless Framework – yaml-конфигурация с декларативным описанием инфраструктуры на основе CloudFormation. Такой подход облегчал понимание и перенос существующих сервисов. Однако стоит отметить, что переход потребовал тщательного изучения новой специфики SAM, его ограничений и особенностей использования, включая работу с template.yaml и samconfig.toml.

Главным подспорьем в процессе миграции стали большие языковые модели (LLM), такие как Claude Sonnet 3.5 и Gemini 2.5 Pro. Они применялись для конвертации конфигурационных файлов Serverless в SAM, генерирования шаблонов и написания вспомогательных скриптов. Задача оказалась непростой, поскольку LLM порой испытывали трудности с обработкой больших контекстов, допускали ошибки в отступах yaml, а также «галлюцинировали» несуществующие свойства, пытаясь восполнить недостающие знания о SAM.

Тем не менее, инструмент позволил сэкономить время и нервные клетки, выступая в роли ассистента, которому оставалось помогать на этапе ревью и исправления. Важным этапом стала работа с тестовыми проектами, где миграция касалась лишь нескольких функций и упрощенной инфраструктуры. Это позволило не только проверить возможности LLM в реальных задачах, но и освоиться с управлением AWS SAM без риска повлиять на пользователей. Параллельно была создана система проверки развертывания, включающая автоматические end-to-end тесты, которые обеспечили последующую стабильность и контроль качества после переноса. Одним из непростых моментов была необходимость перепроектирования сервисов, которые чрезмерно зависели от уникальных механизмов Serverless.

Например, для обхода циклических зависимостей между State Machine и Lambda функциями пришлось менять логику и разбивать функции на части. Замена Serverless Framework потребовала также реализации режима обслуживания (maintenance mode), чтобы обеспечить плавность миграции в продуктивной среде и предупредить потерю данных. В целом, переход на AWS SAM был разбит на несколько этапов: сначала было настроено dev-окружение, затем параллельно созданы параллельные продакшн-среды с новым стеком, последовательно перенесены данные, обновлены интеграции и конфигурации DNS, а после проверки работоспособности старый стек был выключен. Такой подход минимизировал риски и позволил не прерывать работу приложения. Опыт миграции показал, что отказ от Serverless Framework и переход на нативные инструменты AWS дает серьезные преимущества в долгосрочной перспективе.

Прежде всего, это уменьшение зависимости от сторонних компаний и закрытых решений, лучшая поддержка и обновляемость, а также более прозрачное и надежное управление инфраструктурой. Кроме того, в ходе миграции стала понятнее внутренняя архитектура, исчезли многочисленные «ад-хок» решения, появилось детальное документирование и система автоматических тестов. Несмотря на некоторые сложности, в частности с медленной скоростью некоторых развертываний и необходимостью переделывать отдельные архитектурные решения, общая оценка опыта положительная. Использование LLM существенно облегчило работу с шаблонами, позволило избежать написания с нуля большого объема кода, а внедренные testing-процессы обеспечили надежность. Было выявлено, что в последней версии Serverless Framework отсутствует поддержка многооблачных проектов, что могло бы быть риском в будущем.

Этот опыт служит хорошим примером того, как современные технологии искусственного интеллекта уже сегодня активно меняют подходы к инфраструктурному развитию и автоматизации. При грамотном использовании LLM-помощников разработчики могут значительно ускорять рутинные операции, снижать количество ошибок и более уверенно работать с новыми инструментами. Одновременно важно понимать их ограничения, оставлять контроль за важными изменениями человеку и не бояться вносить корректировки вручную. В заключение, миграция более 30 серверлес-функций с Serverless Framework к AWS SAM с поддержкой LLM стала важным шагом в эволюции backend-приложения. Она позволила отказаться от устаревающих технологий, оптимизировать процесс управления инфраструктурой, повысить безопасность и качество обслуживания пользователей.

Такой опыт должен быть интересен разработчикам, работающим с большим количеством функций AWS Lambda и планирующим переход на нативные решения с современными подходами к автоматизации.