Tooling за последние годы подтянулся. Помимо LocalStack, можно посмотреть в сторону serverless-offline (если ты сидишь на serverless framework) — он как раз хорошо себя показывает при локальной отладке API Gateway + Lambda.
А для комплексных сценариев — когда надо гибко комбинировать локальные и контейнерные вызовы — есть подход с test doubles и симуляцией вызовов. Например, замещать часть AWS SDK или использовать AWS Step Functions Local, если дело в оркестрации.
Ну и, если хочется прям мяса, у Yan Cui есть пара отличных материалов про тестирование serverless-приложений — и как устроить интеграционные тесты, и как изолировать зависимости. Он прям по шагам показывает, как выстраивать пайплайн без полной копии прода на каждом этапе.
Соглашусь: это не “в два клика” и не “из коробки как у Django”. Но если подойти с умом и правильными тулзами — можно жить вполне комфортно.
На самом деле для локальной разработки и CI/CD давно есть хороший вариант — LocalStack. Это эмулятор AWS-сервисов, который позволяет поднять у себя на машине (или в CI) окружение с S3, Lambda, DynamoDB, API Gateway и многими другими сервисами. Конечно, он не покрывает всё, и бывают несовпадения с реалом, но для большинства задач — особенно на ранних этапах — этого вполне хватает.
Мы, например, тестируем event-driven архитектуру с Lambda + SNS + SQS и даже Amazon MSK полностью локально — и это реально экономит и деньги, и время. Потом уже прогоняем интеграционные тесты на staging в облаке.
Так что полную копию прода в облаке можно оставить только для финальной валидации, а не для всего процесса разработки.
Спасибо за статью, хороший обзор базовых преимуществ 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. Он требует гораздо больше дисциплины, инструментов и архитектурных компромиссов. Об этих вещах стоит помнить и писать, особенно когда статья адресована инженерам и компаниям, стоящим на пороге перехода.
Да, это и есть классический bus-фактор — и в вашем списке чётко видны все симптомы. «мотивация через освобождение» — это действительно работает: передал знания → освободил себе путь к новым задачам. Выгода для всех.
Не компетентность делает кого-то слабым звеном, а изоляция. Один эксперт, замыкающий знания на себе — это как сервер без бэкапа: пока работает, все довольны, но риск растёт каждый день. Статья не про «наказать лучших», а про то, как сделать команду устойчивее.
В нормальных компаниях как раз и есть learning budget, потому что развитие сотрудника = развитие бизнеса. Но даже без этого знаниевый монополизм остаётся риском. Здесь не про «выжимать», а про устойчивость процессов и здравое управление.
На этот счет у меня есть любимая фраза:
– А что, если мы обучим наших сотрудников, а они уйдут от нас? – А что будет, если мы их не обучим, а они останутся?
Ваша позиция вполне понятна, но, боюсь, вы немного не о том. В статье не предлагается «гнобить спеца» или отбирать у него автономию. Речь о системном риске, когда знания замыкаются на одном человеке.
Если специалист крут, то это не повод строить вокруг него культ. Это повод создать условия, при которых его знания масштабируются, а не становятся узким горлышком. Делегирование, развитие отдела, участие в прибыли — отличные идеи, если он сам к этому готов. А вот игнорировать риск — это управленческая халатность, а не уважение к профессионалу.
Согласен — документация, как и бэкапы, юнит-тесты, CI и мониторинг, не приносят прибыли напрямую. Зато очень хорошо показывают свою ценность в момент, когда всё начинает "идти по ...", вобщем, падать.
Это не про «лишние расходы», а про управление рисками. Как и страховка: дорого, скучно, но без неё больно.
Так что да — вопрос действительно организационный. Но игнорировать его техническим командам тоже себе дороже.
Согласен, если документация написана живым языком, покрывает реальные кейсы и кто-то её действительно читает, тогда да, может заменить. Но на практике чаще видим вики две тыщи лохматого года с "TODO: дописать", а потом всё равно идём спрашивать того самого человека. Так что документирование — однозначно нужный инструмент, но не волшебная панацея.
В идеале — да, если компания требует постоянного менторства, обучения и поддержки коллег, это должно быть отдельно зафиксировано и оплачено. Но тут есть нюанс: если разработчик претендует на senior-уровень, то способность объяснять решения и помогать команде — это не отдельная "услуга", а часть роли. Это не значит «читать лекции», но да — быть доступным, объяснять ключевые решения, помогать ориентироваться. Это про устойчивость команды, а не бесплатную нагрузку сверху.
Во многих европейских компаниях это вообще норма: сеньор без менторства там долго бы не продержался. Просто потому, что от него ждут не только кода, но и влияния на культуру, процессы и рост других. Это не бесплатно — это вшито в компенсацию и ожидания.
Ваш подход близок к инженерному идеалу. Но на практике он работает только в очень зрелых и дисциплинированных командах. В реальности люди не всегда читают, не всегда понимают сразу, и живое общение сильно ускоряет передачу контекста. Особенно если речь про принятие архитектурных решений, а не просто «как это работает».
Документация не заменяет живое общение. Когда знания живут только в коде и в вики, но не в головах команды, то скорость адаптации, дебага и развития падает. А "объяснять" — это не про семинар, это про часть командной ответственности senior-уровня. Не каждый день, не на каждую строчку, но регулярно и по делу.
Спасибо за комментарий — вы абсолютно правы, это хорошее дополнение.
Да, одиночка в хорошей форме действительно может сделать MVP или даже полноценный продукт на порядок быстрее и дешевле команды. И именно поэтому такие люди ценны, особенно в старте, R&D, на сложных участках. Но тут как с костылями в проде: помогает быстро в моменте, а потом может аукнуться.
Вы правильно подметили — работодатели не всегда осознают, что командная разработка не масштабирует результат линейно, а расходы — да, масштабирует. И если в голове был план «сейчас разовьём успех и передадим в команду» — начинаются проблемы: коммуникации, бриджинг знаний, падение скорости, рост расходов, нестыковки по качеству и ожиданиям.
Получается дилемма: или быстро и дёшево, но нестабильно; или стабильно и масштабируемо, но дороже и дольше.
Так что, согласен — эта часть стоит более явно обозначить в статье. Я подумаю, как аккуратно дописать про «причины» и «ожидания бизнеса».
Не просто синтаксический сахар. composite – это способ описывать логику без классов и this. Можно создавать объекты с состоянием, методами и геттерами в чистом, простом стиле. Меньше бойлерплейта, больше читаемости.
Нет, FastAPI ничем радикально не отличается от других Python-фреймворков/проектов. Отдельный сервис — это просто обертка с Dockerfile, зависимостями и стартовыми скриптами, чтобы быстро развернуть и стандартизировать запуск в их инфраструктуре.
Спасибо за уточнение. Согласен, что TLDR гораздо информативнее, но это и не статья, а просто новость. Я действитетьно не те примеры вставил. Поправил.
P.S. Не, нейронка там не заходила — там ее физически некуда "воткнуть" ;)
Tooling за последние годы подтянулся. Помимо LocalStack, можно посмотреть в сторону serverless-offline (если ты сидишь на serverless framework) — он как раз хорошо себя показывает при локальной отладке API Gateway + Lambda.
А для комплексных сценариев — когда надо гибко комбинировать локальные и контейнерные вызовы — есть подход с test doubles и симуляцией вызовов. Например, замещать часть AWS SDK или использовать AWS Step Functions Local, если дело в оркестрации.
Ну и, если хочется прям мяса, у Yan Cui есть пара отличных материалов про тестирование serverless-приложений — и как устроить интеграционные тесты, и как изолировать зависимости. Он прям по шагам показывает, как выстраивать пайплайн без полной копии прода на каждом этапе.
Соглашусь: это не “в два клика” и не “из коробки как у Django”. Но если подойти с умом и правильными тулзами — можно жить вполне комфортно.
На самом деле для локальной разработки и CI/CD давно есть хороший вариант — LocalStack. Это эмулятор AWS-сервисов, который позволяет поднять у себя на машине (или в CI) окружение с S3, Lambda, DynamoDB, API Gateway и многими другими сервисами. Конечно, он не покрывает всё, и бывают несовпадения с реалом, но для большинства задач — особенно на ранних этапах — этого вполне хватает.
Мы, например, тестируем event-driven архитектуру с Lambda + SNS + SQS и даже Amazon MSK полностью локально — и это реально экономит и деньги, и время. Потом уже прогоняем интеграционные тесты на staging в облаке.
Так что полную копию прода в облаке можно оставить только для финальной валидации, а не для всего процесса разработки.
Спасибо за статью, хороший обзор базовых преимуществ 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. Он требует гораздо больше дисциплины, инструментов и архитектурных компромиссов. Об этих вещах стоит помнить и писать, особенно когда статья адресована инженерам и компаниям, стоящим на пороге перехода.
Да, это и есть классический bus-фактор — и в вашем списке чётко видны все симптомы. «мотивация через освобождение» — это действительно работает: передал знания → освободил себе путь к новым задачам. Выгода для всех.
Не компетентность делает кого-то слабым звеном, а изоляция. Один эксперт, замыкающий знания на себе — это как сервер без бэкапа: пока работает, все довольны, но риск растёт каждый день. Статья не про «наказать лучших», а про то, как сделать команду устойчивее.
В нормальных компаниях как раз и есть learning budget, потому что развитие сотрудника = развитие бизнеса. Но даже без этого знаниевый монополизм остаётся риском. Здесь не про «выжимать», а про устойчивость процессов и здравое управление.
На этот счет у меня есть любимая фраза:
– А что, если мы обучим наших сотрудников, а они уйдут от нас?
– А что будет, если мы их не обучим, а они останутся?
Ваша позиция вполне понятна, но, боюсь, вы немного не о том. В статье не предлагается «гнобить спеца» или отбирать у него автономию. Речь о системном риске, когда знания замыкаются на одном человеке.
Если специалист крут, то это не повод строить вокруг него культ. Это повод создать условия, при которых его знания масштабируются, а не становятся узким горлышком. Делегирование, развитие отдела, участие в прибыли — отличные идеи, если он сам к этому готов. А вот игнорировать риск — это управленческая халатность, а не уважение к профессионалу.
Согласен — документация, как и бэкапы, юнит-тесты, CI и мониторинг, не приносят прибыли напрямую. Зато очень хорошо показывают свою ценность в момент, когда всё начинает "идти по ...", вобщем, падать.
Это не про «лишние расходы», а про управление рисками. Как и страховка: дорого, скучно, но без неё больно.
Так что да — вопрос действительно организационный. Но игнорировать его техническим командам тоже себе дороже.
Согласен, если документация написана живым языком, покрывает реальные кейсы и кто-то её действительно читает, тогда да, может заменить. Но на практике чаще видим вики две тыщи лохматого года с "TODO: дописать", а потом всё равно идём спрашивать того самого человека. Так что документирование — однозначно нужный инструмент, но не волшебная панацея.
В идеале — да, если компания требует постоянного менторства, обучения и поддержки коллег, это должно быть отдельно зафиксировано и оплачено. Но тут есть нюанс: если разработчик претендует на senior-уровень, то способность объяснять решения и помогать команде — это не отдельная "услуга", а часть роли. Это не значит «читать лекции», но да — быть доступным, объяснять ключевые решения, помогать ориентироваться. Это про устойчивость команды, а не бесплатную нагрузку сверху.
Во многих европейских компаниях это вообще норма: сеньор без менторства там долго бы не продержался. Просто потому, что от него ждут не только кода, но и влияния на культуру, процессы и рост других. Это не бесплатно — это вшито в компенсацию и ожидания.
Ваш подход близок к инженерному идеалу. Но на практике он работает только в очень зрелых и дисциплинированных командах. В реальности люди не всегда читают, не всегда понимают сразу, и живое общение сильно ускоряет передачу контекста. Особенно если речь про принятие архитектурных решений, а не просто «как это работает».
Кстати, про риски замены опытных специалистов на дешёвых я писал отдельно. Можете почитать, если интересно: https://medium.com/@dobeerman/the-hidden-costs-of-hiring-low-cost-developers-ac7f79027961
Документация не заменяет живое общение. Когда знания живут только в коде и в вики, но не в головах команды, то скорость адаптации, дебага и развития падает. А "объяснять" — это не про семинар, это про часть командной ответственности senior-уровня. Не каждый день, не на каждую строчку, но регулярно и по делу.
Спасибо за комментарий — вы абсолютно правы, это хорошее дополнение.
Да, одиночка в хорошей форме действительно может сделать MVP или даже полноценный продукт на порядок быстрее и дешевле команды. И именно поэтому такие люди ценны, особенно в старте, R&D, на сложных участках. Но тут как с костылями в проде: помогает быстро в моменте, а потом может аукнуться.
Вы правильно подметили — работодатели не всегда осознают, что командная разработка не масштабирует результат линейно, а расходы — да, масштабирует. И если в голове был план «сейчас разовьём успех и передадим в команду» — начинаются проблемы: коммуникации, бриджинг знаний, падение скорости, рост расходов, нестыковки по качеству и ожиданиям.
Получается дилемма: или быстро и дёшево, но нестабильно; или стабильно и масштабируемо, но дороже и дольше.
Так что, согласен — эта часть стоит более явно обозначить в статье. Я подумаю, как аккуратно дописать про «причины» и «ожидания бизнеса».
Не просто синтаксический сахар.
composite– это способ описывать логику без классов иthis. Можно создавать объекты с состоянием, методами и геттерами в чистом, простом стиле. Меньше бойлерплейта, больше читаемости.Нет, FastAPI ничем радикально не отличается от других Python-фреймворков/проектов. Отдельный сервис — это просто обертка с Dockerfile, зависимостями и стартовыми скриптами, чтобы быстро развернуть и стандартизировать запуск в их инфраструктуре.
так предусмотрено же не по порядку https://youtu.be/hFenspfGLTk?si=1kXYCTgpxGldKTyR&t=410
Да это я просто не в ту кнопку ткнул ;) Пятница :)
В любом случае, интересно будет, как минимум, понаблюдать за проектом.
Кстати, а что именно не понравилось в Heroku? Цены, ограничения, возможности или что-то ещё?