Ответ
Да, у меня был опыт миграции набора серверных функций (serverless) с Azure Functions на AWS Lambda. Основной причиной была консолидация всей инфраструктуры проекта в рамках одного облачного провайдера (AWS) для упрощения управления и снижения затрат.
Ключевые шаги и сложности миграции:
-
Анализ и планирование:
- Сопоставление триггеров Azure (HTTP, Blob Storage, Service Bus) с их аналогами в AWS (API Gateway, S3, SQS/SNS).
- Аудит зависимостей и конфигураций (переменные окружения, управляемые идентичности в Azure → IAM роли в AWS).
-
Переписывание кода:
- Функции были на C# (.NET Core). Код бизнес-логики в основном остался прежним, но пришлось переписать точки входа (handlers) и интеграции со специфичными сервисами AWS.
-
Пример (Azure → AWS):
// Было в Azure Functions [FunctionName("ProcessBlob")] public static void Run([BlobTrigger("container/{name}")] Stream blob, string name, ILogger log) // Стало для AWS Lambda, реагирующей на S3 public async Task FunctionHandler(S3Event s3Event, ILambdaContext context)
-
Инфраструктура как код: Вся новая инфраструктура на AWS была описана с помощью Terraform (ранее использовался ARM в Azure), что сделало процесс повторяемым.
-
Сложности:
- Холодный старт (cold start): В AWS Lambda при определённых настройках он был более ощутим, потребовалась оптимизация пакета развёртывания.
- Мониторинг и логирование: Переход с Azure Application Insights на AWS CloudWatch и X-Ray. Потребовалось время, чтобы настроить аналогичный уровень observability.
- Поэтапный перенос: Миграция проводилась постепенно, используя стратегию «синего-зелёного» развёртывания, чтобы не прерывать работу сервиса.
Ответ 18+ 🔞
А, ну это я проходил, блядь. Перетаскивал кучу этих самых serverless-функций с Azure на AWS. Честно говоря, основной движухой было то, что все наши сервисы уже сидели на AWS, а эти функции — как хуй с горы, торчали отдельно в Azure. Управлять этим — терпения ноль ебать, да и в деньгах выходило накладно. Решили всё в одну кучу собрать.
Что делал и где мозг выносило:
-
Сначала сидел, думал, как подступиться.
Нужно было каждую штуку из Azure найти замену в AWS. HTTP-триггер — это API Gateway, работа с файлами из Blob Storage — на S3 переезжает, очереди Service Bus — ну, SQS/SNS, ёпта. А ещё эти все доступы: в Azure Managed Identity, а в AWS — IAM-роли настраивай. Голова квадратная становилась. -
Код сам по себе — да похуй.
Логика бизнесовая осталась, её почти не трогал. А вот точки входа — это пиздец, всё переписывать. Представь, просто берёшь и меняешь способ, как функция просыпается.
Вот смотри, как было и как стало:// Раньше в Azure Functions — красиво, объявил атрибут и всё [FunctionName("ProcessBlob")] public static void Run([BlobTrigger("container/{name}")] Stream blob, string name, ILogger log) // А теперь для AWS Lambda, которая от S3 события торкается public async Task FunctionHandler(S3Event s3Event, ILambdaContext context)Чувствуешь разницу? Пришлось вникать в ихние структуры событий. Не смертельно, но времени жрёт овердохуища.
-
Инфраструктуру я на Terraform перевёл.
Раньше в Azure были эти ARM-шаблоны, а тут — Terraform. С одной стороны, гибче, с другой — опять учись, блядь, их синтаксис. Зато теперь всё как код, развернул — и работает. Красота. -
А вот сложности — это отдельная песня, я тебе скажу.
- Холодный старт (cold start) на AWS Lambda иногда так долго думал, что я уже начинал волнение ебать чувствовать. Пришлось пакеты развертывания оптимизировать, лишние зависимости выкидывать — в общем, танцы с бубном.
- Мониторинг. В Azure Application Insights всё было привычно, а тут — CloudWatch. Искал логи — как иголку в стоге сена. Пока не настроил X-Ray, вообще нихуя не понятно было, где что тормозит.
- Самое главное — мигрировали не всё разом. Поднимали новые функции на AWS, а старые на Azure пока работали. Потом потихоньку трафик переключали, смотрели, не сломалось ли что. Стратегия «синий-зелёный», называется. Так хоть пользователи нихуя не заметили, что мы там в backend-е творим. А творили мы, я тебе скажу, много чего.
