Человек и машина

#машины_aws У CloudFormation два классных нововведения. Про первое уже написал Рома, обязательно пройдите и прочитайте, если вас задолбала последовательность: создал стек с бакетом - набил бакет объектами - удалил стек - стек не удалился - матерясь, чистишь бакет - удаляешь стек снова - раздраженно снимаешь галочку с “игнорировать удаление”. Но мне, честно говоря, больше понравилась новость про дебаг с помощью CloudTrail. Когда я работаю с новым или мало изученными сервисом, у меня часто происходят итерации trial and error. Где-то опечатался, где-то перепутал параметр, где-то добавил несовместимые свойства, где-то забыл построить зависимость с помощью DependsOn. До того, как появилась возможно управлять стеками с disable rollback, обычный цикл разработки выглядел похожим на цикл удаления стека с непустыми бакетом: 1. Создаем стек 2. Стек валится, откатывается назад. Пока он откатывается, смотрим ошибку API 3. Ждем пока стек откатится. Поскольку это новый стек, мы его удаляем, потому что перенакатить изменения на новый стек, который сломался и откатился в пустоту ПОЧЕМУ-ТО ДО СИХ ПОР НЕЛЬЗЯ 4. Находим ошибку в шаблоне, исправляем. Повторяем итерацию с пункта 1. Чем же тут хорош CloudTrail? Тем, что раньше у нас была скучная консоль с логом стека, где мы по куску ошибки должны были сделать вывод. Теперь же можно пройти в CloudTrail, посмотреть подробно не только ошибку, но и какие параметры были у запроса в API, со всеми полями. Это так же упрощает разбор ситуаций, когда создание валится не из-за опечаток в шаблоне, а например если у роли, с которой CloudFormation создает ресурс, недостаточно прав.

#машины_aws Роскошный пример синтеза белошапочников и черношапочников. https://buckets.grayhatwarfare.com/ По ссылке - список из всех публичных, т.е. открытых наружу бакетов во всех крупных поставщиках облачных услуг. За дополнительную плату можно получить доступ к поисковому API, регулярные выражения и даже сортировку по размеру.

#машины_разное Мой прошлогодний доклад про строго-согласованный кластер Redis получил расшифровку. Если вы предпочитаете текст вместо видео - милости прошу.

#люди Если жестокий капитализм не пощадил вас или ваших друзей и заставил искать новую работу, испытывая стресс от автоматических отказов или игнора - я написал пост про то, как в 2024-ом стоит оформлять резюме для итшников, чтобы увеличить шансы на первую встречу с работодателем. Пост доступен на Медиум. Если по какой-то причине Медиум не работает, пост продублирован на Телега.пх. Внутри поста: - как изменилось поведение работодателей - что писать в резюме, а что не писать - кто такой этот ваш импакт - что делать, если рекрутер все никак не позовет В работе я ориентировался на западный рынок, но некоторые пункты применимы и для России/СНГ. Уточняющие вопросы можно задать в Медиуме или тут в треде. Я также не против перевода статьи на русский, если у кого-то есть время и ресурс, и буду признателен, если переводчик сошлется на оригинал.

#пятничное AWS CodeDeploy научился цеплять несколько балансировщиков к EC2 машинам. Это вызвало у меня радость, поскольку я мог вычистить кодовую базу от нескольких хаков, которые пришлось применить, чтобы подружить машину с двумя балансировщиками. Зайдя в доку, я обнаружил что нововведение не появилось в провайдере (хотя 3 месяца прошло, могли бы и завести). Беглый поиск показал открытый запрос на поддержку, висящий в очереди, потому что HashiCorp расставляет приоритеты на основе... лайков! Удивительно, что Хаши раньше добавляли новые фичи и сервисы быстрее команды CloudFormation.

#машины_разное Рик Хулихан, известный политтехнолог NoSQL в свое время разработал стандарт Single Table Design, который подразумевает хранить все поля сущностей в одной, как следует из названия, таблице. Про STD есть превосходная презентация, которая раскрывает суть, детали и имплементацию. Честно скажу, что это моя самая любимая презентация. Однако, индустрия делает очередной виток, и снова начинаются гонения на, вроде бы, принятые подходы. Создателя паттерна это, можно сказать, задело, и он разразился большой ответкой в Твитере. Настоятельно советую прочитать ответ. Без апелляции к авторитету, можно снова сказать, что был потерян контекст. STD никогда не подразумевал складывать вообще все в одной таблицу. Паттерн подразумевает что атрибуты одной сущности должны храниться в одном месте, а не в разных. И определение этих атрибутов идет в первую очередь с помощью определения паттернов доступа - какие данные мы читаем и для каких целей. От себя замечу, что пока мы, как индустрия, продолжаем терять контекст, мы обречены использовать инструменты и подходы не по назначению, а потом героически их переизобретать.

#машины_aws При настройке доступа через IAM велик соблазн использовать сгенерированные самим AWS'ом политики, в которых нужная часть доступа уже предоставлена. Так, например, в AmazonEC2ReadOnlyAccess добавили ec2:Get*. Все бы хорошо, но действие ec2:GetPasswordData дает администраторский пароль от Windows машины, что, скажем так, уже не совсем read-only 🙂 Изменение довольно шустро откатили. Лишний раз напомню, что лучше дополнительные пару часов потратить на дизайн доступа по Least Privilege Principle, чем потом быть на первой полосе новостей из-за взлома.

#машины_разное Если вам вдруг надоело флексить CAP теоремой, значит пришло самое время расчехлять "новый" "тренд" под названием PACELCA И если вы сейчас подумали о зумерах, которые переизобрели распределенные системы, спешу вас расстроить - с критикой теоремы зашли пресловутые деды. В первую очередь, CAP теорема обманывает тем, что мы можем выбрать 2 из трех, в то время как выбрать мы можем одно из двух - А или С. Выкинуть из системы Р нереалистично, да и более того - кто такой этот ваш партишн толеранс? В каком-то случае, пропавший интернет в туннеле уже себе Network Partition, попробуйте предусмотреть это в своей системе. Вернемся к PACELCA (кто-нибудь, отберите у итшников нейминг, пожалуйста). Сама по себе эта, даже не теорема, а скорее алгоритм анализа компромисов звучит так: Если нам нужна терпимость к сетевым партициям (P), то мы выбираем между доступностью (А) и согласованностью (С). В противном случае (Else - E), компромис между задержкой (Latency - L) и выбором в сторону согласованности (С) или доступности (А). Сложно? Сложно. Сначала академики придумали нам устойчивую договоренность, а потом пришли деды из индустрии и из этой договоренности сделала пес знает что. Потому что edge cases. 🤷‍♂️ P.S. В индустрии в принципе есть тренд то на усложнение, то на упрощение. См. прыжки из монолита в микросервисы, из микросервисов в макросервисы, из макросервисов обратно в монолит. В гибкости - сила!

#машины_aws У нас с командой AWS CloudFormation есть славная традиция: как только я отправляю новое издание по Mastering AWS CloudFormation в печать, команда тут же выпускает новые фичи, про которые мне обязательно хотелось бы рассказать в книге. Сначала это был Fn::ForEach, который добавляет поддержку циклов (долгожданный конкурент Terraform'овского count и for_each), вышедший в релиз как только вторая глава со словами "Вот AWS уже делает нам циклы в клавдформейшоне" была сдана, сверстана и проиндексирована, ну а теперь, как вы наверное догадались - IaC generator. Генератор - это AWS-managed аналог Terraformer. Сканируем весь аккаунт (если надо, с фильтрами) и добавляем ресурсы для будущего стека. На выходе получаем сгенерированный код с импортированным состоянием. Этакий OneClick переезд с ClickOps на Infrastructure-as-Code. А любители высокоуровневых языков программирования могут сходу занести стек в CDK и забыть про ужасы правки длиннющих YAML'ов. Из очевидных недостатков: поддерживаются только "родные" ресурсы из CloudFormation Registry, что логично - оно не побежит в DataDog сканировать дашборды. Второй недостаток вытекает из первого - если вы накликали себе ресурсов из свежего мегасервиса, который не поддерживается CloudFormation, то никакой генерации не будет. P.S. Мне такими темпами скоро придется третье издание писать, пощадите. P.P.S. В комментарии приглашаются YAML-фобы, потому что я так и не понял разницу между поддержкой кодовой базы на тысячу строк и аналогичным шаблоном CloudFormation.

#пятничное #новогоднее Многим из вас знаком закон Конвея, который гласит, что организационная структура и коммуникация между командами отражается на итоговой архитектуре систем. Существует и обратный закон Конвея, предлагающий растить и развивать структуру предприятия в соответствии с архитектурой системы. К чему я это все? К тому, что и в первом, и во втором случае наблюдается натягивание одного на другое. Это не хорошо и не плохо, это данность за которой придется следовать. В конце концов мы субъекты вечно меняющихся обстоятельств, в которых нам надо существовать и оперировать. В 2024 году я хочу пожелать вам, дорогие друзья, крепости и силы для внешних обстоятельств и гармонии и покоя для внутренних. С наступающим Новым годом! 🎉