Я все пишу о разных подходах, процессах и прочей водичке, но вроде ниразу не писал про инструменты.

Чтобы вы понимали - моя работа не только стрелочки соединять и читать документацию. Иногда нужно работать “ручками”. Когда код писать, когда шаблоны для ресурсов, когда пайплайны пилить или конфигурацию серверов - стандартная работа любого инженера.

Расскажу сегодня о моих любимых инструментах.

Что касается IDE: PyCharm (Pro) с плагинами aws-toolkit и Cloudformation, Goland, для работы с БД - DataGrip. Когда приходится ковыряться в Scala - IntelliJ IDEA Ultimate с плагином Scala. Для “быстро посмотреть, поправить” - VS Code с тучей разных плагинов.

По работе с облаками - aws-shell, pure Cloudformation (пишу на YAML), SAM, ecs-cli, cfn-skeleton (позволяет очень быстро набросать скелет шаблона), Terraform для личных проектов, Packer.

Стрелочки соединяю в Lucidchart и draw.io.

Документация - в кодовой базе Python docstring, Markdown. Остальное идет в Confluence (на текущей работе полный стек Atlassian: JIRA, Confluence, Bitbucket).
Амазоновскую документацию держу локально на флешке в PDF (Cloudformation, ECS, EC2, RDS, DynamoDB, Lambda, API Gateway, SQS, IAM, etc), на случай, если нужно поработать без доступа в сеть.

Для набросков купил себе тетрадь формата А4 за пару евро в магазине рядом с домом. Всякие стикеры не понимаю, равно как и “умные” блокноты по 30 евро с молескинами.

Вот в целом и все.

Есть конечно и прикольные инструменты (для облака), типа Troposphere или GoFormation, но я привык к стандартному подходу и не очень горю желанием делать unit тесты вокруг шаблонов.

Если будут вопросы, пишите.

Напоминаю, что на DevOpsForum.ru можно попасть со скидкой по промокоду #Friends.

Я стараюсь не касаться тем политики, гендерного неравенства, толерантности и прочих “с жиру бесятся” и “проблемы первого мира” (не в этом канале, а вообще по жизни).

Однако, я не могу пройти мимо истории двух разработчиков и изображения черной дыры.

Для начала оглянусь чуть назад в историю, а именно в 2014-ый год, когда учеными из ESA была совершена посадка зонда “Розетта” на комету 67P/Чурюмова-Герасименко.
Доктор Мэтт Тейлор, после успеха миссии давший интервью, надел тогда рубашку с полуголыми нарисованными женщинами (парень вообще полный рок-н-ролл, поищите его изображения в интернете), чем вызвал фурор.

Стоит ли говорить, что все внимание общества было приковано не к прогрессу команды ученых, а к рубашке одного из ее членов?

Не скажу сейчас всех подробностей скандала, помню лишь, что доктору пришлось публично извиняться за то, что он надел “сексистскую” рубашку.

Теперь вернемся обратно в наше время.
Вторым по популярности изображением (первое это изображение собственно самой черной дыры) стало восхищенное лицо доктора Кэти Боуман, и появились новостные вырезки: “Доктор Кэти Боуман, лидер команды ученых […] вот ее выражение лица, когда фотографии были получены.”

Я восхищаюсь успехами женщин в области бизнеса, науки и спорта (нет, я не феминист), поэтому я искренне обрадовался за девушку - далеко не все в 29 лет имеют такие достижения.

Чуть позже стали всплывать очерки о неком ученом Эндрю Чейле, который, по словам этих ваших интернетов, написал 850 000 строк кода из 900 000, в то время как доктор Боуман написала только 2500 (а то ваши тимлиды больше кода пишут, лол).

В итоге только только начавшийся интернет-скандал был осажен самим Эндрю, который, если вкратце, сказал что: “большинство этих строк это модели, хватит принижать мою коллегу, сексисты.”

Интернет в свою очередь отреагировал как: “ну подумаешь, он больше написал, Кэти тоже молодец, ну че вы ребята, успокойтесь”. Смешно смотреть (особенно смешно смотреть такие дискуссии на LinkedIn).

Поступок Эндрю вызывает исключительно уважение. Настоящий ученый - “творец” - должен быть скромен, ведь он делает то, что делает не для популярности, а для прогресса человечества.

Но мне интересно - а если бы было наоборот? Как бы отреагировала общественность, если б фото Эндрю пестрило по сети, а затем выяснилось, что основную работу выполнила Кэти?

Впрочем, даже знать не хочу.

К коллегам по цеху (не важно в вашей команде/компании или вне) нужно относиться с уважением.

Взаимное уважение дает нам полезное взаимодействие (collaboration) и минимизирует риск конфликтов (нет “токсичности” - нет конфликтов).

Благодаря взаимному уважению живет и здравствует OpenSource.

Поэтому, когда я встречаю статью, с которой совершенно несогласен, я, вместо того, чтобы улюлюкать и показывать пальцем, стараюсь вчитаться в нее, найти в ней идею автора, и - если получится - вступить в дискуссию.

Но порой я вижу такой “контент”, от которого, кроме как смеха, другой реакции выдать не могу.

Если вам, мои дорогие читатели, нечем заняться, и вы, как это обычно бывает, задумались о бренности бытия - вашему вниманию шикарная статья на тему Docker: https://habr.com/ru/post/445914/

Безотносительно компетенций автора статью можно разобрать на “мемесы”. Я, словно 10-летний тролль-сношатель-чужих-мамок, хихикал буквально от каждый строчки.

Разбора статьи, конечно, не будет. Нечего разбирать.

Если автор оригинальной статьи увидит этот пост, я с удовольствием обсужу его труд с ним.

Уважайте друг друга. Всем любви.

Съездив в Москву и выступив на форуме, я был приятно удивлен интересу к теме моей презентации (Кто не помнит - она была про миграцию в Амазон).

Я прекрасно понимаю, что “большая тройка” облаков давит на русских инженеров тремя факторами: ценой, законодательством и риском.

Однако, не смотря на все сомнения, я увидел не только много (я бы даже сказал слишком много) слушателей моей презентации, но и целый ворох каверзных вопросов, на которые, я надеюсь, ответил.

Видеозапись лекции обещали прислать в течение месяца. Как она будет у меня, я с радостью ей поделюсь.

Большое спасибо организаторам за то, что выдернули меня из загнивающей.

А также спасибо @stekov_me, @SinTeZoiD, @mo1seev, @count0ru, @aftertime и @Shader444 за очередные веселые посиделки. 😉

Но не все мне рассказывать о своих веселостях. Ожидайте контент на тему knowledge sharing.

Когда мы говорим про обмен знаниями, мы подразумеваем два аспекта: документацию (knowledge base) и образование (onboarding, knowledge sharing, тренинги и прочее).

И если с документацией все понятно и прозрачно, то с обменом знаниями у людей все еще возникают недопонимания.

Вот, например, самый странный способ, подготовить новичка - вручить ему доступ к кодовой базе и документации, пусть читает.

Такой способ солидно экономит время команды, но подходит он только для опытных спецов - иными словами, такой onboarding подходит для medior/senior/principal уровня, когда человек знает, как и что делать, и ему надо узнать как все сделано в условной конторе/команде.

С junior уровнем, понятно дело, все иначе. И пусть и есть садисты, которые выпускнику дают кодовую базу на изучение, в большинстве (я надеюсь) случаев, к человеку привязывается ментор, который готовит новичка, используя тот же shadowing/reverse shadowing.

Однако рассмотрим ситуацию с другого угла, когда нужен обмен знаниями не внутри команды, а между командами.

У нас есть база знаний, в котором все документировано, но вот нюанс - в базе знаний обычно фиксируют уже совершенные действия и решения.
Проще говоря, если команда А приняла решение запустить сервис Х, разработав его определенным образом, остальные команды увидят документацию уже после того, как сервис создан и работает. Это повышает риск неправильно принятых решений, поскольку команда А может не обладать экспертизой в определенной области и не консультировалась с командой Б, где экспертиза уже есть, и команда Б могла помочь советом или направить в нужное место.

Классический пример из опыта - разработчики решили использовать DynamoDB для batch обработки событий. Чего разработчики не знали, так это того, что DynamoDB как решение для batch обработки стоит слишком дорого, но всплыло это уже не в качестве вопроса (“Эй, Томас, мы тут думаем использовать динаму, потому что она очень шустрая. Нам нужно обрабатывать 10 000 событий в минуту, как нам лучше сделать? Подойдет ли она?”), а в качестве проблемы (“Эй, Томас, мы тут сделали Динаму, но она почему-то выплевывает нам 400 Throttling, как нам заставить это работать?”).

Не углубляясь в детали - DynamoDB имеет определенные лимиты на API вызовы, и 10 000 операций в минуту (допустим запись), это около 170 вызовов в секунду, что приблизительно 0.765 USD в час или 558.5 USD в месяц.

Чтобы вы понимали - это очень дорого.

Могло бы быть иначе, если разработчики сначала пришли ко мне за консультацией, но такой подход (разрабы, бегающие к SME) не работает и имеет ряд недостатков, но о них позже.

Я уже писал про таких SME (Subject Matter Expert) - специалистов, имеющих экспертизу в определенной области.

В контексте обмена знаниями, давайте рассмотрим первый кейс - мой любимый и ненаглядный GSMG.
Наша core команда - небольшая группа лиц, отвечающих за определенный “участок” (как это обычно бывает в стартапах).
Я отвечаю за эксплуатацию и AWS, наш бекендер лучше всего знает, собственно, бекэнд, фронтендер - фронтэнд, двое человек отвечают за маркетинг и PR, а наш “Один Всеотец” лучше всего шарит в торговле криптоактивами (с его небольшого скрипта на питоне все и началось) и диктует направление разработки.

Для того, чтобы эффективно разрабатывать и развивать нашу систему, мы постоянно взаимодействуем между собой, отдавая “авторитет” в принятии решений друг другу в контексте определенного участка.
Проще говоря, я не буду говорить нашему бекэндеру как использовать asyncio, а он не будет рассказывать мне, как конфигурировать proxy-кластер.

Нас очень мало (по количеству рук) в условиях такого масштабного проекта, поэтому обмен знаниями очень простой и работает в бОльшей части вербально - мы созваниемся, обсуждаем, приходим к выводам и принимаем решения. Что решили - быстренько документируем в базе знаний, либо в документации к приложению.
Разработчики при проектировании систем приходят ко мне за советом, как реализовать некий кейс в условиях AWS, а я консультируюсь у них по правилам балансировщика, чтобы Fargate task’и успевали подняться.

В этом ключе небольшой silo по экспертизе не мешает, поскольку разработка проекта хаотична, и Scrum головного мозга по нам не бьет.

Теперь рассмотрим другую ситуацию - моя основная работа, которая меня кормит.

В конторе есть департамент, в департаменте 5 команд - 4 команды разработки и 1 команда DevOps (хотя по факту больше Ops), в которой я и состою.

Взаимодействие между эксплуатацией (нами) и разработкой (ними) идет по сервисной модели.
То есть мы, как эксплуатация, предоставляем набор сервисов и инструментов разработчикам (AWS, CI/CD и прочие сис. админские прелести), а разработчики это настраивают под себя и разворачивают свои приложения направо и налево.

Я не могу сказать, что этот “тот самый” DevOps, который я хочу видеть, но до “того самого” у нас пока нет.

Главной проблемой такой “сервисной” модели являются те самые архитекторские решения, принимаемые разработчиками без нашего участия.

По процедуре у каждого продукта есть свой специальный чек-лист, в котором один из пунктов стоит: “Продукт одобрен одним или несколькими системными инженерами.”

Стоит ли говорить, что этот чеклист начинает отрабатываться, когда продукт спроектирован, разработан, запущен в тестовом окружении, и наша “подпись” нужна только для того, чтобы выкатить продукт в промышленное окружение?

А теперь представьте, что я изучаю продукт и вижу, что там используется та же DynamoDB для редкой обработки больших объемов данных (что, как я писал, дорого и неэффективно). Одобрю ли я такое решение? Разумеется, нет.
В итоге я оказываюсь в положении, что должен завернуть разработку и заставить все переписать, ломая весь план и архитектуру, а это - дни и недели потерянной работы.

Этого можно избежать, если члены инженерной команды будут участвовать в проектировании решения (что делается в любой конторе, где DevOps это культура, а не человек).

С этой проблемой я столкнулся сразу, как мы запустили on-call ротацию в нашей команде, и в следующем посте я напишу, как мы это дело “чинили”.

Итак, мое первое дежурство, и я вижу, что некоторые системы падают с завидной регулярностью.
После анализа я вижу следующее:
1. Система выступает как центральное звено, ее падение вызывает падение зависящих от нее приложений.
2. Система используется для решения задач, для которых она не предназначена (Например event sourcing система используется так же как долгосрочное хранилище событий).
3. Система была спроектирована под определенную нагрузку и объем данных и теперь она не справляется.

С ростом объемов и нагрузки можно справиться либо оптимизацией производительности и рефакторингом, либо добавлением ресурсов, если рост органичен.

Другое дело с неправильной архитектурой.

Первым и, разумеется, неверным шагом было придти к коллегам с предложением бросить все и переписать. Конечно, такой шаг не увенчался успехом.

Здесь нужно сделать небольшую ремарку: недавно в группе DevOps Moscow обсуждалось понятие личного бренда (об этом я тоже напишу отдельно), и как оно помогает в работе.
В Нидерландах все несколько иначе, личный бренд - ничто, всеобщая уравниловка, социализм и прочие прелести коммунизма.

То есть старший инженер с 10+ годами в конторе и вчера нанятый младший разработчик имеют одинаковый вес голоса.

Я поставил перед собой две цели:
- Избавить нас от проблем 1 и 2 в кратчайшие сроки.
- Сделать так, чтобы этого не повторилось в будущем.

Чтобы достичь первой цели в первую очередь нужно думать по принципу win-win.
То есть не идти к разработке с operations требованием (сделайте так, чтобы ваши приложения не падали), а мотивировать их разрабатывать с reliability in mind, что в итоге будет плюсом и для всех.
Решение было простым, но потребовался административный ресурс. Я поговорил с нашим техническим директором, и мы договорились о следующем:
- Необходимый SLO ставится одной из целей в KPI команды (от KPI зависит годовой бонус)
- 20% спринта выделяется на уничтожение технического долга. Ops определяют приоритет задач, как stakeholders.
- В нашей (Ops) команде на ближайшее время 50% ресурсов уходит на уничтожение технического долга.

Для второй цели пришлось сделать некоторые манипуляции с процессом разработки.

Во-первых, общение между инженерами и разработкой как пункт чек-листа перенесли из Definition of Done в Definition of Ready. Это позволило инженерам участвовать в grooming и planning сессиях (то есть на самих ранних стадиях) разработки.
Участником от инженерной команды назначается текущий дежурный инженер. Это позволяет соблюдать определенный нейтралитет и минимизировать риск принятия неправильного решения под воздействием эмоций или дружеских отношений между инженером и разработчиком. Также нет “привязки” конкретной задачи к конкретному инженеру, и тот может спокойно идти в отпуск или на больничный.
Помимо этого перед планированием дежурный инженер и один или несколько разработчиков разрабатывают несколько PoC с использованием разных сервисов AWS, которые затем демонстрируются перед началом работ по разработке и имплементации. Наилучшее решение (то есть то, которое эффективнее всего решает данную задачу и не конфликтует с зависимостями) уходит непосредственно в разработку.

Во-вторых, чтобы изменения, приходящие со стороны инженеров, не встречали усиленного сопротивления, мы стали проводить “облачные” тренинги для разработчиков.

Например, мы решили заменить DC/OS на Fargate. Эта инициатива требует переработки всех существующих CI/CD pipeline’ов, тестирования и, как результат, - времени разработчиков.

Прежде чем презентовать Fargate как преемника контейнерной оркестрации мы проводим тренинг, где разработчики сами создают кластер и разворачивают dummy приложение на оном.

Разработчик, видя, что новая система имеет ряд преимуществ, уже охотно хочет ей воспользоваться. Видя восторженные возгласы и разные вопросы из разряда “Ну что, когда мы это запустим в прод?”, инженеры понимают, что первый барьер сломан и можно презентовать решение на общем собрании.

Похожего рода тренинги теперь проводятся регулярно, мы покрываем разные сервисы и подходы (не только те, которые хотим “продать”), чтобы мотивировать разработчиков думать не только о разработке нового функционала, но и об использовании нативных амазоновских сервисов, которые упрощают жизнь и им, и нам.

P.S. А спустя полгода я все то же самое читаю в книжке Site Reliability Engineering.

Коллеги, один из участников сообщества AWS_ru ведет прекрасный канал про разные плюшки в AWS.

В канале неприлично мало людей. Если волею Рока вы связали свою жизнь с этим ужасающим своими масштабами монополистом рынка облачных провайдеров, присоединяйтесь.

https://news.1rj.ru/str/aws_notes

В канале очень много полезной информации.

Коллеги, у меня есть мысль написать про так называемый «личный бренд», про который будет митап DevOps Moscow 16 мая, но сегодня я вдоволь наигрался со штукой под названием Troposphere (https://github.com/cloudtools/troposphere).

По Troposphere если и писать, то много, так что придется использовать Telegraph.

Вопрос к аудитории: с чего начать?
Робот - Troposphere
Человечек - Личный бренд

Напишу по обеим темам в любом случае.

Я удивлен, как ноздря в ноздрю идут две абсолютно разные темы.

Это хорошо. Это показывает мне, что у вас, коллеги, разнообразные интересы и цели, преследуя которые, вы читаете мой канал.

Я подержу верхний пост до пятницы, хотя видно, что “личный бренд” с небольшим перевесом опережает troposphere, так что сначала я дам контент по нему.

Что касается Troposphere - думаю, это будет моим дебютным материалом в Medium (До этого я писал только на Хабр и сюда).

А пока предлагаю вам ознакомиться с материалом @SinTeZoiD про то, почему стоит ответственно относиться к вопросу хранения персистентных данных: https://habr.com/ru/post/452174/

Миша на этом деле не только собаку съел.

По поводу аварии в Яндекс.Облако.

Амазон терял данные пользователей на EBS в 2011 году.
Сервис S3 лежал несколько часов в одном из регионов. Из-за этого у конечных пользователей были проблемы различного масштаба, от сломавшихся холодильников до неработающих пультов от телевизора.

GitLab убил production базу. Во время восстановления выяснилось, что бекапы работали некорректно, и восстановили в итоге из снимка ФС по чистому везению.

ЦОД GCP ушел в отказ, когда в него ударила молния два раза подряд. Два. Раза. Подряд.

Github в результате цепочки отказов работал в деградированном режиме 24 часа и 11 минут.

Про отказы Facebook, Instagram и ВК я вообще молчу.

У меня нет инсайдов о том, что именно произошло в Я.О, но по тем крупицам информации, что я нашел - это не самое страшное, что могло случиться, и масштаб трагедии гораздо меньше, чем пишут на Pikabu и Хабре.

На DevOps Forum Moscow я сказал, что будущее ИТ за развитием публичных и гибридных облаков, и Яндекс делает титаническую работу.

Я желаю команде Яндекс.Облако удачи в решении инцидента, и пусть это будет их последняя крупная авария.

Прекращайте спекуляции и own your reliability (c)

Про личный бренд.

В моем понимании личный бренд состоит из:
- узнаваемость в организации
- узнаваемость в индустрии в пределах одной страны
- узнаваемость в индустрии по всему миру

У нас на слуху имена Торвальдса и Столлмана.
Многие из нас так же знают Митчелла Хашимото и Брандона Грэгга.

Мы прекрасно знаем, что это за люди, мы прекрасно к ним относимся, и мы доверяем им и тому, что они говорят.

Личный бренд может решить (но необязательно решит) следующие задачи:
- прием на работу в желаемую компанию и/или желаемую должность
- продвижение идей внутри компании или индустрии


В Нидерландах личный бренд только упростит устройство на работу. Например, когда я устраивался на должность Cloud Architect, мне, как незнакомому организации лицу, нужно было подтвердить свои знания в 3 технических собеседованиях и одном тестовом задании.
Моему коллеге, который до этого работал в Philips на такой же позиции, было достаточно одного. Его background и запись в резюме сказали за него больше, чем он сам.

Однако нам обоим необходимо проводить подробное исследование, чтобы протолкнуть наши идеи: вы помните из моих предыдущих постов, что в NL в условной команде или департаменте все равны, и задавить авторитетом не получится.

В РФ (я предполагаю) дела обстоят несколько иначе. Приди я на очередной митап DevOps Moscow, буду выглядеть для тусовочки диковинной зверушкой (если только вся тусовочка не читает этот канал), мой доклад будут прогонять, а аудитория будет слушать вполуха (что ожидаемо).

В итоге, чтобы протолкнуть что-либо, мне нужно будет раз за разом выступать с первоклассными докладами, зарабатывая очки авторитета у аудитории.

Но по мере роста доверия доклад будет уменьшаться в размере: в нем будет меньше аргументов, потому что главный аргумент - сам докладчик. Он уже все, кому надо, доказал.

Похожим образом личный бренд может развиваться и в пределах одной организации, а узнаваемость в индустрии, заработанная на конференциях и митапах, будет приятным бонусом.

Иными словами, задача инженера своими действиями показать: «Вася Пупкин - крутой инженер».

Достигать этого вы будете через превосходную работу, проактивность, исполнительность, доклады или knowledge sharing - уже вторично.

По себе могу сказать, что времена, когда можно было строить карьеру, просто занимаясь своим делом и «прокачивая» hard skills, закончились.

People marketing плотно вошел в индустрию, и если не хотите встрять на 2-3 линии поддержки до самой пенсии, придется красиво одеваться и торговать лицом.

Поверьте мне, это окупится сполна.

А вот и обещанный доклад с конференции в Москве.

https://www.youtube.com/watch?v=LHnOhG1BtEE

P.S. Да, звук отстает.

По моему недавнему посту про аварию Я.О я получил несколько сообщений, так что вот небольшое summary и мнение.

Нет, уничтожать инфраструктуру клиента не является нормальной или стандартной практикой облачных провайдеров.

Нет, клиент не должен создавать свои продукты, опираясь на то, что провайдер услуг будет их всячески ломать.
Но между клиентом и провайдером услуг есть так называемая shared responsibility модель (за что отвечает он, а за что клиент). Провайдер никогда не будет гарантировать вам, что железо, на котором живет ваша виртуальная машина, никогда не упадет. Провайдер так же не будет гарантировать, что его сотрудники никогда не допустят ошибок.

Провайдер чаще всего прямым текстом говорит, что берет на себя задачи по эксплуатации железа, но вы (клиент) несете ответственность за резервирование и дублирование данных. Вот ЭТО как раз-таки нормально, потому что провайдер отвечает за снижение операционной нагрузки клиента за счет модели managed service’ов (и именно так он и зарабатывает деньги).

Если провайдер дает вам какие-то гарантии, т.е. “у нас никогда ничего не падает вообще” - с таким провайдером не надо иметь дел от слова совсем.

Нет, наличие собственной инфраструктуры не уменьшает риска потери данных, оно переносит риск с провайдера услуг на вас. Если доверяете себе и своим сотрудникам больше, чем сотрудникам провайдера - не пользуйтесь услугами провайдера.

Нет, это ненормально, если провайдер гарантирует 100% uptime SLA. Если он гарантирует - подробно читайте условия SLA, найдете там много интересного (например, посмотрите SLA Cloudflare).

Нет, я не являюсь сотрудником AWS или другого облачного провайдера. Я не получаю от провайдеров денег, у меня нет партнерского соглашения ни с одним из них.
Я не являюсь евангелистом или, прости Боже, influencer’ом, и если когда либо стану - вы об этом узнаете первыми (после меня и работодателя).
Я крайне критично отношусь ко всем провайдерам и настоятельно рекомендую так делать своей публике.

Если есть неотвеченные вопросы - дайте знать.

(Ушел писать про Troposphere)

Материал по Troposphere занимает гораздо больше времени, чем хотелось бы, но такого рода статью лучше преподнести позже, но подготовленнее.

Вот вам немного спойлеров для затравки:
«Когда Bool совсем не Bool.»
«Получаем гибкость Python и его же проблемы.»
«cfn-lint испортит вам все удовольствие.»
«Документацию пишет мизантроп-социопат.»

И много-много других подводных камней, которые я любезно собираю, чтобы выложить перед вами.

Оставайтесь на связи. ;)

Обещанный материал по Troposphere: https://bit.ly/2EAk7A9

Как вам новый формат лонгридов на Медиуме?

Почему Medium и почему на английском?

Потому что работать над личным брендом нужно по всем фронтам, и так получилось, что ЦА над которой я начинаю работать не говорит по-русски. Medium же популярная платформа, только и всего.

Заменит ли Medium мой канал? Абсолютно нет, потому что Medium - мой инструмент продвижения, Телега - мое хобби.

Всякие лонгриды будут идти в Медиум (результаты исследований, не попадающие под NDA, и прочие интересные материалы), что-то по чтению не больше 2 минут - в канал.

По итогам работы с Troposphere могу сказать лишь одно: динамическая типизация - зло.

Мой близкий друг и соратник @sonkintammio с месяц назад сподвиг меня приобрести электронную книжку.

Надо сказать, до этого я читал книги с телефона или компьютера, что приводило к уставшим глазам и плохо усвоенной информации (попробуй пойми прочитанное, когда в тебя со всех сторон нотификации стреляют).

Важным вопросом для меня был возврат инвестиций. Покупать устройство за 80 USD и класть его в полку не хотелось.

Женя в свою очередь убедил меня, что книжки я после этого буду пихать, как не в себя, и оказался прав.

С момента покупки (20ые числа апреля), я прочитал Site Reliability Engineering, Site Reliability Workbook, Systems Performance и Database Reliability Engineering.

На данный момент давлюсь Thinking: Fast and Slow (@count0ru, я смогу!), на очереди: Designing Distributed Systems.

Получается где-то по книжке в неделю (до этого была в лучшем случае одна в месяц).

Спасибо, Жека!

Вот эта статья (https://advancedweb.hu/2019/05/28/aws_config_credentials/) воистину “ор выше гор”.

Советы в ней из разряда “мойте руки перед едой и после туалета”, что огорчает меня еще больше.
Тема аутентификации в AWS прожевана вдоль и поперек, давно рекомендуется не использовать IAM пользователей и группы, а аутентификацию и авторизацию делать через IAM роли. Для пользователей - использовать SAML и опять же заставлять их assume’ить роль. Для EC2 - Instance Profile’ы.

При этом в статье нет таких полезностей как авторизовывать операцию sts:AssumeRole через Conditions (а там тоже много вкусного, от проверки MFA до Source IP Address).

В целом статья выглядит даже не как повторение всем известных постулатов, а очередной Security 101.

При всем при этом тему можно развить! Добавить туда такие вещи как Hashicorp Vault, Secrets Manager, SSM Parameter Store и сделать из посредственной материала настоящую рафаэлку.