Да я же не против :) Более того, я за развитие людей в команде.
Но ведь читатели могут начать применять Ваши рек. И я не могу не отметить, что в истории не хватает слов о ресурсах, уходящих на контроль джуниоров, о чем написали в параллельных комментариях. А это довольно ощутимый ресурс: ментор должен учить, тщательно просматривать код, давать рекомендации — ментором работать.
А ещё не каждый разработчик согласиться брать на себя эту ответственность просто так. Да, «во имя команды» и все такое. Но так из-за джуна можно и мидлов и выше потерять.
Джуниоры в команде — это как кредит. Доступный практически всем инструмент. Но если им не уметь пользоваться и набирать один за другим бездумно, можно залезть в яму.
Без ментора, планируемого роста, программы обучения, документации внутри команды это будет просто генератор говнокода. Надо понимать, что джуны нанимаются не потому, что дёшево и быстро, а потому, что получившийся миддл (при правильном приготовлении) вырос внутри системы и знает, как с ней обращаться. А также его не надо искать.
Другое дело, что я встречал множество примеров, когда джун вырастал, и его начинали кормить завтраками с повышением в зп, должности и так далее. Неудивительно, что потом такие компании пишут: «Джуны уходят». Хочется добавить: «Только джуны?».
Возвращаясь к финансовым аллегориям, джуны являются долгосрочными инвестициями на случай, если Вы понимаете, что поиск одного миддла и выше занимает много времени/стоит дорого/свой вариант (нужное подчеркнуть).
Джуны также часто плохо переваривают критику, графики работы (хотя их необходимость вообще под вопросом) и прочие строгие процессы. Они зачастую только что из института, не привыкли к таким вещам. И без правил игры начинаются истории с пустым рабочим местом и фразой: «Я что-то вчера устал».
Резюмируя: если не знаете, зачем Вам джуны, или думаете, что это просто дешёвые программисты, то лучше не нанимать их.
>> Хотелось бы между лямбдами, чтобы один запрос из вне проходил под общим айдишником
Лямбда отвечает строго на один запрос. Если хочется создать пайплайн, то надо просто это учитывать и создавать некий ID запроса. Изначально лямбды под это просто не отточены. Это просто дешёвый запуск маленького сервиса.
>> На сколько я вижу, Step Functions конфигурируется с помощью собственного языка и UI
Да ну нет. «You can access and use Step Functions using the console, the AWS SDKs, or an HTTP API»
Мой опыт работы с AWS говорит о том, что там почти любой сервис (если не совсем любой) управляется через API.
>> Например, можно ли использовать аутентификацию по JWT токену, выпущенному внутрикорпоративным OAuth сервисом, в лямбдах?
Поскольку запускаемый сервис написан на каком-то выбранном языке, то он умеет всё то же, что и обычный скрипт, запускаемый на Serverful (если можно так выразиться :) ) окружении.
Идея тут достаточно простая — в Serverless удобно и выгодно запускать маленькие сервисы, описываемые не огромным количеством кода.
В минусы я точно могу занести Vendor lock. Если Serverless и начинает появляться на других платформах, то я очень сомневаюсь, что на него можно гладко переехать.
>> как дебажить
Смотря что вкладывать в это понятие. Логи можно собирать в тот же S3, например. Или в ELK-кластер. Это если хочется логов. Также есть сбор метрик через CloudWatch.
>> есть ли сквозная трассировка
Внутри одной лямбды есть встроенный трассер. Вот пример для Java (https://docs.aws.amazon.com/lambda/latest/dg/java-tracing.html)
Сквозную трассировку вызова я бы собирал в ту же Кибану. Но тут возникает вопрос — что входит в один вызов? Говоря на высоком уровне, не погружаясь в реализацию, я бы сказал, что инстансы должны уметь выкидывать информацию о своём состоянии и своей работе вовне. И они умеют это делать.
Конечно же есть! И в базовой грубой версии они не особо даже сложные.
НО:
1. Надо узнать, что идёт атака. То есть, нужен мониторинг. Если его нет, то атака может идти долго, делая сервис недоступным.
2. Надо правильно выделить атаку. Атаковать может большой ботнет с огромным пулом. То есть одним только анализом IP не обойдёшься.
3. Если идёт DDoS, а сервер слабенький, то есть вероятность того, что команды будут выполняться довольно долго.
Разумеется, для проектов, не подразумевающих SLA, это допустимо. Но у крупного ресурса простой в несколько минут может исчисляться несколькими нулями после единицы.
Кстати говоря, почитал тут документацию по Lambdas, и там тоже есть лимиты по параллельным вызовам. Но всё равно они гораздо больше, чем лимиты среднего такого сервера.
Тут уже суровая экономика включается. Для своего блога и площадки под мелкие сайд-проекты достаточно простой виртуалки на хостинге или того же AWS EC2. Лямбды становятся выгодными в Enterprise-сегменте, где реально важной становится гибкость расширения, а также высокая отказоустойчивость. В моём понимании, лямбды хороши в быстро растущем бизнесе в случае, когда по каким-то причинам нет SRE или DevOps практик, но хочется в гибкость и не падать на очередной условной распродаже.
Хорошо, пусть даже отбивание атаки будет стоить порядка 1000 долларов. Если люди отбили эту атаку разово, это все равно оставит ресурс работающим за относительно небольшие деньги по меркам бизнеса, который конкуренты собрались ддосить. Дальше, имхо, если уж люди дошли до использования serverless, логично, что они, скорее всеоо, сделают выводы и подключат тот же экран Shield. Но в теории, при определенном стечении обстоятельств и вводных компанию таки можно разорить через Лямбды.
Кстати, ещё надо знать, что из функционала отдаётся лямбдами, а что классическими серверными скриптами. Отдавать монолит на лямбды — такая себе идея.
Мне довелось поработать, например, с NewRelic в рамках веб-проектов. Они довольно активно идут на личный контакт, готовы собирать прям полноценные воркшопы, чтобы выделить метрики именно на уровне приложения, что приятно удивило. Но и ценник там был не самый дешёвый. С другой стороны, гораздо ниже, чем месячная зарплата DevOps-инженера.
Говоря о «скучности» задачи мониторинга, её довольно легко можно отдать и на аутсорс. Сейчас есть куча SaaS-мониторингов, которые умеют собирать правильные метрики и KPI из коробки. Довольно актуальная история, если в компании IT-ресурса не хватает, а мониторить очень хочется.
Во-первых, стоимость идёт порядка 0.20USD за миллион запросов, либо 0,00001667 USD за превышение порога 400000 гигабайт-секунд (https://aws.amazon.com/ru/lambda/pricing/).
Во-вторых, доступ извне к тем же лямбдам обычно пускают, например, через амазоновский Route 53, где есть такая прекрасная вещь, как AWS Shield. Да и без него, ЕМНИП, Амазон даст знать (но это неточно).
Но, так или иначе, необлачный сервер при той же DDoS-атаке ляжет и перестанет предоставлять услугу. И тут тоже стоит подумать, что дороже: переплатить за лишние пару сотен миллионов вызовов или вообще не предоставлять сервис, теряя клиентов (деньги).
Да я же не против :) Более того, я за развитие людей в команде.
Но ведь читатели могут начать применять Ваши рек. И я не могу не отметить, что в истории не хватает слов о ресурсах, уходящих на контроль джуниоров, о чем написали в параллельных комментариях. А это довольно ощутимый ресурс: ментор должен учить, тщательно просматривать код, давать рекомендации — ментором работать.
А ещё не каждый разработчик согласиться брать на себя эту ответственность просто так. Да, «во имя команды» и все такое. Но так из-за джуна можно и мидлов и выше потерять.
Без ментора, планируемого роста, программы обучения, документации внутри команды это будет просто генератор говнокода. Надо понимать, что джуны нанимаются не потому, что дёшево и быстро, а потому, что получившийся миддл (при правильном приготовлении) вырос внутри системы и знает, как с ней обращаться. А также его не надо искать.
Другое дело, что я встречал множество примеров, когда джун вырастал, и его начинали кормить завтраками с повышением в зп, должности и так далее. Неудивительно, что потом такие компании пишут: «Джуны уходят». Хочется добавить: «Только джуны?».
Возвращаясь к финансовым аллегориям, джуны являются долгосрочными инвестициями на случай, если Вы понимаете, что поиск одного миддла и выше занимает много времени/стоит дорого/свой вариант (нужное подчеркнуть).
Джуны также часто плохо переваривают критику, графики работы (хотя их необходимость вообще под вопросом) и прочие строгие процессы. Они зачастую только что из института, не привыкли к таким вещам. И без правил игры начинаются истории с пустым рабочим местом и фразой: «Я что-то вчера устал».
Резюмируя: если не знаете, зачем Вам джуны, или думаете, что это просто дешёвые программисты, то лучше не нанимать их.
Лямбда отвечает строго на один запрос. Если хочется создать пайплайн, то надо просто это учитывать и создавать некий ID запроса. Изначально лямбды под это просто не отточены. Это просто дешёвый запуск маленького сервиса.
>> На сколько я вижу, Step Functions конфигурируется с помощью собственного языка и UI
Да ну нет.
«You can access and use Step Functions using the console, the AWS SDKs, or an HTTP API»
Мой опыт работы с AWS говорит о том, что там почти любой сервис (если не совсем любой) управляется через API.
>> Например, можно ли использовать аутентификацию по JWT токену, выпущенному внутрикорпоративным OAuth сервисом, в лямбдах?
Поскольку запускаемый сервис написан на каком-то выбранном языке, то он умеет всё то же, что и обычный скрипт, запускаемый на Serverful (если можно так выразиться :) ) окружении.
Идея тут достаточно простая — в Serverless удобно и выгодно запускать маленькие сервисы, описываемые не огромным количеством кода.
В минусы я точно могу занести Vendor lock. Если Serverless и начинает появляться на других платформах, то я очень сомневаюсь, что на него можно гладко переехать.
>> как дебажить
Смотря что вкладывать в это понятие. Логи можно собирать в тот же S3, например. Или в ELK-кластер. Это если хочется логов. Также есть сбор метрик через CloudWatch.
>> есть ли сквозная трассировка
Внутри одной лямбды есть встроенный трассер. Вот пример для Java (https://docs.aws.amazon.com/lambda/latest/dg/java-tracing.html)
Сквозную трассировку вызова я бы собирал в ту же Кибану. Но тут возникает вопрос — что входит в один вызов? Говоря на высоком уровне, не погружаясь в реализацию, я бы сказал, что инстансы должны уметь выкидывать информацию о своём состоянии и своей работе вовне. И они умеют это делать.
>> как оркестрировать сложные системы (>20 AWS Lambda/Az Functions)
aws.amazon.com/ru/getting-started/tutorials/create-a-serverless-workflow-step-functions-lambda — Amazon предоставляет механизм Step Functions. Кажется, это то, что Вы ищете.
>> как прикрутить кастомную аутентификацию
К чему? Аутентификацию кого и чего? Не совсем понятно.
НО:
1. Надо узнать, что идёт атака. То есть, нужен мониторинг. Если его нет, то атака может идти долго, делая сервис недоступным.
2. Надо правильно выделить атаку. Атаковать может большой ботнет с огромным пулом. То есть одним только анализом IP не обойдёшься.
3. Если идёт DDoS, а сервер слабенький, то есть вероятность того, что команды будут выполняться довольно долго.
Разумеется, для проектов, не подразумевающих SLA, это допустимо. Но у крупного ресурса простой в несколько минут может исчисляться несколькими нулями после единицы.
Кстати говоря, почитал тут документацию по Lambdas, и там тоже есть лимиты по параллельным вызовам. Но всё равно они гораздо больше, чем лимиты среднего такого сервера.
Хорошо, пусть даже отбивание атаки будет стоить порядка 1000 долларов. Если люди отбили эту атаку разово, это все равно оставит ресурс работающим за относительно небольшие деньги по меркам бизнеса, который конкуренты собрались ддосить. Дальше, имхо, если уж люди дошли до использования serverless, логично, что они, скорее всеоо, сделают выводы и подключат тот же экран Shield. Но в теории, при определенном стечении обстоятельств и вводных компанию таки можно разорить через Лямбды.
Кстати, ещё надо знать, что из функционала отдаётся лямбдами, а что классическими серверными скриптами. Отдавать монолит на лямбды — такая себе идея.
Не совсем. Вот выдержка из прайсинга:
Но даже по Вашим расчётам выходит что-то в рамках 100$ потерь за одну атаку. При этом:
Во-вторых, доступ извне к тем же лямбдам обычно пускают, например, через амазоновский Route 53, где есть такая прекрасная вещь, как AWS Shield. Да и без него, ЕМНИП, Амазон даст знать (но это неточно).
Но, так или иначе, необлачный сервер при той же DDoS-атаке ляжет и перестанет предоставлять услугу. И тут тоже стоит подумать, что дороже: переплатить за лишние пару сотен миллионов вызовов или вообще не предоставлять сервис, теряя клиентов (деньги).