Вроде бы коротко и по делу, но вот чтение писем с помощью Spring/Spring Boot не освещено. Как раз по этой тематике очень мало информации, а существующая по Spring Integration выглядит немного странно с настройкой бинов через xml в 2020 году.
Было бы здорово и эту информацию осветить, если есть желание разобраться. Такое в принципе очень часто необходимо при автоматизированном тестировании отправки email и его содержимого.
Почти все верно, но по большей степени для асинхронных вызовов. Для них настраивается Retry pollicy (по дефолту 2 раза). Для синхронных запросов, как в моем случае, retry — это обязанность API Gateway либо консьюмера Api Gateway. Можно сделать на стороне JS к примеру.
Насчет шедулеров, это прямо одно из основных направлений я бы сказал. CloudWatch может работать по принципу cron job и триггерить запуск лямбды. Также для лямбды доступно огромное количество триггеров, который могут даже существовать параллельно.
Насчет своей инфраструктуры для лямбд, мне кажется зависит от специализации. Если огромная компания имеет такую потребность то наверно стоит оценить такую возможность. Естественно тут все упирается в рабочие ресурсы и производительность. Возможно вы потратите больше на зп разработчикам, чем провайдеру. Ну и чтобы добиться того же перформанса что имеется у aws/google придется попотеть))
Спасибо за такие заметки. Прочитал, и действительно, когда начинал проект собирать не было ни Provisioned Concurrency ни VPC NAT для лямбды, успел только 8 джаву обновить до 11.
А так надо будет провести пару экспериментов с Provisioned Concurrency.
rsync Если коротко, то все зависит от типа теста. В юнитах мокаем обычными средствами языка Mockito/PowerMockito.
В интеграционных тестах — зависимости, такие как база / S3 / любой другой сервис чаще всего поднимаются независимо в Docker.
В e2e, если есть возможность, поднимается дополнительный стек и дублируются зависимые ресурсы.
А вот тесты на безопасность и производительность в большинстве случаев опускаются, если применение асинхронное и AWS роли и политики четко заданы во всем аккаунте.
Также, с точки зрения производительности хорошо бы не забыть проверить как объем оперативной памяти влияет на скорость обработки, тем самым на затраты.
На вашем месте я точно также бы не стал замарачиваться с переводом готовой инфраструктуры на лямбды, особенно если идет разговор о каком-либо REST API и уже имеющем k8s инфраструктуре.
Но вот создание ETL процессов либо clean-up джоб — как раз под силу AWS Lambda. И при некоторых вложениях в автоматизацию CI/CD для лямбд, можно получить крутое решение как для любого dev/test окружения, так и для процессов архивации данных в проде.
Было бы здорово и эту информацию осветить, если есть желание разобраться. Такое в принципе очень часто необходимо при автоматизированном тестировании отправки email и его содержимого.
Насчет своей инфраструктуры для лямбд, мне кажется зависит от специализации. Если огромная компания имеет такую потребность то наверно стоит оценить такую возможность. Естественно тут все упирается в рабочие ресурсы и производительность. Возможно вы потратите больше на зп разработчикам, чем провайдеру. Ну и чтобы добиться того же перформанса что имеется у aws/google придется попотеть))
А так надо будет провести пару экспериментов с Provisioned Concurrency.
В интеграционных тестах — зависимости, такие как база / S3 / любой другой сервис чаще всего поднимаются независимо в Docker.
В e2e, если есть возможность, поднимается дополнительный стек и дублируются зависимые ресурсы.
А вот тесты на безопасность и производительность в большинстве случаев опускаются, если применение асинхронное и AWS роли и политики четко заданы во всем аккаунте.
Также, с точки зрения производительности хорошо бы не забыть проверить как объем оперативной памяти влияет на скорость обработки, тем самым на затраты.
Но вот создание ETL процессов либо clean-up джоб — как раз под силу AWS Lambda. И при некоторых вложениях в автоматизацию CI/CD для лямбд, можно получить крутое решение как для любого dev/test окружения, так и для процессов архивации данных в проде.