Комментарии 17
Как бороться с атаками на функции можно было бы осветить более подробно
Спасибо, что обратили внимание на защиту функций. В дополнение к сказанному, из интересных практик, которые попадались, для минимизации привилегий использовали IAM Access Analyzer в связке с CloudTrail: то естть, на основе реальных вызовов формируются максимально узкие политики, и это снижает поверхность атаки. Да, подход не новый, но рабочий.
Для валидации данных часто отталкиваются от OWASP Serverless Top 10 — проверка полей по whitelist, плюс экранирование всего, что может привести к инъекциям, до передачи в базу или внешние API.
От DDoS и перебора помогает rate-limiting в API Gateway, иногда подключают AWS WAF с rate-based правилами — тоже довольно эффективная связка.
Ну и про наблюдаемость, как бы ни хотелось «делегировать всё провайдеру», без нормального мониторинга врядли что то получится. Lambda Insights и Anomaly Detection в CloudWatch здесь выручают — не пропустят аномалии и дадут реакцию.
Думаю, что заоблачные счета после Denial of Wallet (DoW) останавливают посильнее, чем затруднения с отладкой и внедрением функций
Denial of Wallet – это не баг, это фича для тех, кто лепит serverless как попало. Тут не AWS виноват, что у тебя Lambda по таймеру крутится каждые 5 секунд и лупит по DynamoDB без всякого смысла.
Большинство таких "заоблачных счетов" – результат архитектурной импотенции и «нагуглил, как сделать». А при нормальном подходе serverless летает, как реактивный дрон, и стоит копейки.
Мы гоняем аналитику футбольных матчей – десятки тысяч событий, миллионы трекинг данных, real-time алерты, snapshot'ы – и это обходится дешевле кофе из автомата. Не шучу. Мы не "крутим" сервисы 24х7, а "поднимаем" их только на время матча – причем, теми же Lambda-ми ;)
Просто надо не “функции писать”, а архитектуру думать.
Даже не знаю, кому адресовалось про DynamoDB. Вообще, кратковременные задачи это такая редкость. Но спасибо, что поделилсь своим опытом.
У меня функции крутятся внутри периметра и наружу ничего не торчит - я доволен.
DynamoDB просто как пример упомянул – не агитирую :) У нас чаще в бою крутится связка Lambda + MSK + EventBridge Pipes + ещё кучка специй по вкусу включая DDB – всё это обрабьатывает матчевые события в реальном времени, считает алерты, метрики и прочую аналитику на лету.
По поводу "кратковременные задачи – редкость"... Ну, возможно, у вас архитектурный дзен и всё стабильно как в банке. У нас же 90 минут футбола, 50Hz трекинг, тысячи событий, всё летит и обрабатывается в real-time. Lambda тут вообще как швейцарский нож.
Но если задачи реально тяжёлые и по времени/ресурсам не влазят в рамки Lambda – никто не запрещает смотреть в сторону ECS Fargate. Тоже serverless, только для тех, кому надо "пожирнее", но без заботы о серверах.
Если у вас всё внутри периметра и всё работает – замечательно. Главное, чтобы потом не оказалось, что «периметр» – это коробка, в которой тушат пожары (из практики) :)
Посмотрел на кейс Кока-Колы и прослезился. В масштабах столь крупной компании снижение стоимость произошло с "ноль" до "ноль невзъеженный" - вряд ли там кто-то всерьёз воспринимает такие числа. Подозреваю, что стоимость миграции превысила экономию на порядки - попробуйте в крупной компании открыть проект, выбить бюджет, найти подрядчика, подписать договоры разработки и сопровождения...
Вспомнилась молодость, как мы продавали крупному забугорному клиенту "модное облачное решение", которое в итоге обошлось ему на порядки дороже одного выделенного сервера с простеньким Java-приложением. Но все довольны, бюджет освоен, пресс-релиз сделан, все молодцы. А то, что система постоянно падает из-за специфики сетевых настроек, принципиально ограничиваемых облачной интеграционной платформой - ну так про то большим боссам можно просто не говорить.
Да, в случае с гигантом, как кола, абсолютные цифры в долларах выглядят конечно ничтожно маленькими, особенно в публичных отчётах. Но тут я хотел показать не столько размер экономии, сколько сам вектор — миграция с legacy-архитектуры на serverless в принципе. Это даёт гибкость, быстрее выпускать новые фичи, меньше времени тратить на поддержку. Особенно в системах с высокой и непредсказуемой нагрузкой, как у Coca-Cola с их полумиллионом заказов в день, может они что то потом и придумали, как оптимизировать :)
Что касается вашего примера — классический кейс "облака ради галочки", к сожалению (ну или для кого то к счастью), такое действительно часто случается. Но всё же хочется верить, что культура использования облака эволюционирует. Хотя, конечно, без «освоения бюджета» и маркетинговых побед в духе «мы теперь в serverless» пока никуда..
много лет гляжу на serverless но не вижу иного способа автоматически тестировать (в CI/CD), а так же локально тестировать разработчику кроме как создавать в облаке полную копию прода и запускать на нём удалённые тесты.
и в этом месте, КАЖЕТСЯ, вот эта картинка играет настолько яркими красками, что я так и не решился ни разу попробовать:
На самом деле для локальной разработки и CI/CD давно есть хороший вариант — LocalStack. Это эмулятор AWS-сервисов, который позволяет поднять у себя на машине (или в CI) окружение с S3, Lambda, DynamoDB, API Gateway и многими другими сервисами. Конечно, он не покрывает всё, и бывают несовпадения с реалом, но для большинства задач — особенно на ранних этапах — этого вполне хватает.
Мы, например, тестируем event-driven архитектуру с Lambda + SNS + SQS и даже Amazon MSK полностью локально — и это реально экономит и деньги, и время. Потом уже прогоняем интеграционные тесты на staging в облаке.
Так что полную копию прода в облаке можно оставить только для финальной валидации, а не для всего процесса разработки.
вот, для этой полной копии нужно написать docker-compose
далее отлаживаем например функцию x, надо сделать так, чтобы она вызывалась не из lambda в compose, а из пользовательского окружения
то есть lambda в compose вызывает 53 функции, надо сделать 52, а 53ю чтоб звало на компе у пользователя
при этом надо как-то их состыковать эти lambda в compose с компом у пользователя
и это мы пока говорили о ручном тестировании, а если автоматические тесты с тем, что 1/53 на компе у пользователя?
В общем в этом месте тестирование настолько мутное, что говорить что лямбды тут выигрывают - надо это показывать и доказывать...
Я допускаю, что выигрывают, но вот статей о том КАК это делать - я не видел.
Tooling за последние годы подтянулся. Помимо LocalStack, можно посмотреть в сторону serverless-offline (если ты сидишь на serverless framework) — он как раз хорошо себя показывает при локальной отладке API Gateway + Lambda.
А для комплексных сценариев — когда надо гибко комбинировать локальные и контейнерные вызовы — есть подход с test doubles и симуляцией вызовов. Например, замещать часть AWS SDK или использовать AWS Step Functions Local, если дело в оркестрации.
Ну и, если хочется прям мяса, у Yan Cui есть пара отличных материалов про тестирование serverless-приложений — и как устроить интеграционные тесты, и как изолировать зависимости. Он прям по шагам показывает, как выстраивать пайплайн без полной копии прода на каждом этапе.
Соглашусь: это не “в два клика” и не “из коробки как у Django”. Но если подойти с умом и правильными тулзами — можно жить вполне комфортно.
Спасибо за статью, хороший обзор базовых преимуществ serverless-подхода. Но всё же есть несколько критически важных аспектов, которые, на мой взгляд, стоило бы раскрыть — особенно для тех, кто собирается всерьёз внедрять такую архитектуру.
Во-первых, в статье вскользь упоминаются сложности, но не затрагивается главная боль — отладка и мониторинг. При использовании AWS Lambda или аналогов в production-е быстро выясняется, что привычные инструменты вроде логов или APM тут не работают как обычно. Трейсинг распределённых вызовов, корреляция логов между сервисами, реакция на инциденты — всё это требует внедрения дополнительных инструментов вроде AWS X-Ray, Datadog, или OpenTelemetry. Без них можно просто «ослепнуть» в момент, когда что-то пошло не так.
Во-вторых, cold start — это не просто “иногда чуть подтормаживает”, это иногда секунды лишнего ожидания пользователем. Особенно если функция «просыпается» по первому клику пользователя. Да, можно использовать provisioned concurrency, но тогда теряется часть смысла serverless — оплата за реально использованные ресурсы.
Ещё одна тема, которая требует осторожности — IAM и безопасность. В serverless-модели каждая функция может (и должна) иметь отдельные права доступа, но на практике этим часто пренебрегают, выдавая функции доступ “на всякий случай”. А это уже потенциальная дыра, особенно если функция как-то экспонирована наружу (например, через API Gateway).
И наконец, тайм-ауты. Многие забывают, что у большинства serverless-функций есть ограничение на максимальное время работы (в той же Lambda это 15 минут). Если задача сложная и требует больше — придётся переосмысливать архитектуру, дробить задачи, передавать контекст между функциями или переходить на Step Functions. Это не всегда очевидно в начале.
В целом, serverless — отличный подход, особенно когда нужно быстро что-то запустить и масштабировать, не держа парк серверов. Но продакшн — это не Hello World. Он требует гораздо больше дисциплины, инструментов и архитектурных компромиссов. Об этих вещах стоит помнить и писать, особенно когда статья адресована инженерам и компаниям, стоящим на пороге перехода.
Наврное, если напилить свою серверлесс инфру на своем железе, то это может быть достаточно удобно. Работаешь не с деплоями, а в рамках функций. Базы/редисы/вотэва доступны через апи без деталей реализации, думаю можно здорово бустить разработку.
Но нужна пачка инженеров это поддерживать, но думаю все-равно будет дешевле, чем платить по прайсу облачных провайдеров для крупняка
serverless клаудом не ограничивается.
переход на функции - это сразу вендор лок.
клауд будет в 10 раз дороже: https://tech.ahrefs.com/how-ahrefs-saved-us-400m-in-3-years-by-not-going-to-the-cloud-8939dd930af8
Если посчитать - то 1 функция на 1 гигабайт памяти работающая 24x7 (1 RPS круглосуточно, время выполнения - 1 секунда) будет стоит $40. После этого рассказы об экономической эффективности функций внезапно начинают играть новыми красками - если облачный провадйер рассказывает вам про экономическую эффективность функций, он имеет ввиду эффективность для него, а не для вас.
Не совсем понимаю как получилось у Кока-колы столько платить за 6 инстансов. У меня получается цифра в 2500, ну плюс диски конечно будут. Но не думаю, что это будет 10К. Смена Т2.медиум на Т3а.медиум принесла бы 25% экономии. Плюс если брать контракт на 3 года, тоже сильная экономия была бы.
Тут ещё важен момент - а сколько они потратили на то, чтоб переписать и перенести код на серверлесс? Бесплатно? Возможно с их затратами на разработку они могли лет 10 оставаться на ЕС2.
Как serverless-архитектура влияет на модернизацию инфраструктуры