#машины_разное #люди

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

Хочу подчеркнуть 3 основных закона, которые мне аукнулись.

“A technology that was built for good will eventually be also used for bad.”

Я бы сократил это до “A technology will eventually be also used for bad.”, причем так можно говорить не только про новые блестяшки, как (де-)генеративный ИИ, но и про внутренние системы, которыми неизбежно будут злоупотреблять или использовать не по назначению. Соответственно, я, как разработчик-владелец, должен не допустить такого поведения.

“The most painful, and least useful projects are migration projects, yet companies will replace technologies every 4 years.”

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

“A highly communicative and collaborative team of average engineers, is going to outperform an uncommunicative and non-collaborative team of great engineers.”, и за ним же: “Left alone, a product team will optimize to the closest and easiest goal.”

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

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

#машины_aws

Разработчикам CloudFormation Extensions, да и в целом команде CFN - мое почтение, такого удобства как человек, который хочет писать бизнес-логику и только, я с сервисами AWS не испытывал примерно никогда.

Собственно, в чем цимес. Разработчики CFN придумали расширения, в которые входят Modules (по аналогии с Terraform), Hooks (валидация изменений, но теперь на лету) и Resource Types - та самая мякотка, которая позволяет выкинуть в окно и сжечь Custom Resource со всеми его Lambda’ми.

От разработчикам расширения требуется строгое следование спецификации. Оно и понятно, ведь ресурс управляется бекендом CFN, а значит входящий тип должен спокойно перевариваться. В помощь разработчику дается cloudformation-cli с набором плагинов, в который оборачивается логика жизненного цикла ресурса.

Чтобы сгенерировать стартовый скелет, нужно просто напечатать cfn init и пройти интерактивный опрос. Обертка подготовит структуру проекта, сгенерирует модель, хендлеры, скелеты тестов, и даже набросает схему.

Посмотрев на результат работы init-скрипта, я поймал сильный вайб от SAM. Предположив, что мне нужно будет руками поправить сначала схему, потом переписать приблизительно все. Однако, открыв models.py, я увидел подозрительную строчку: # DO NOT modify this file by hand, changes will be overwritten

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

Весь остальной опыт +- такой же как у SAM CLI, но вот генерация и регенерация кода - мое увожение, я был приятно удивлен.

#пятничное #воскресное

"Он понял из этого отрывочного бормотания, что Сомс - отвергнутый, нелюбимый муж - восстановил свои права на жену путем величайшего, наивысшего акта собственности."

Какой интересный способ выбрал Джон Голсуорси чтобы в "Саге о Форсайтах" описать обыкновенное домашнее насилие!

#машины_разное

Усилия по ускорения Python продолжаются! Теперь Гвидо при поддержке инженеров из Меты намерен выкинуть из него GIL.

Нелюбовь к GIL сама по себе не новость. Из-за него для эффективной параллелизации приходится использовать multiprocessing, что неэффективно по памяти, хотя multithreading vs multiprocessing - отдельная дискуссия в сообществе.

Толчком к движению PEP-a вперед стало желание фейсбушников помочь, выделив на этот проект 3 человеко-года.

#машины_разное

Дизайн документ нередко предшествует абстракт - пару-страничник, задача которого ответить на вопрос “Зачем?” и “Почему то, что есть сейчас, не работает?”. Ответить на “Что?” тоже можно, буквально одним абзацем. Но “Зачем/Почему” куда важнее.

“Зачем” в первую очередь помогает посмотреть на проблему с нетехнической точки зрения. Технарей же хлебом не корми, дай пописать или поделать что-то прикольное, а вот нетехнарский анализ направит энергию в правильное коммерческое русло. В эту секцию складывают либо бизнес проблему, либо расчеты полученной прибыли / сокращенных расходов, либо оба два. Математика дубовая - если на проект тратим 10 баксов, а зарабатываем 100, то это хорошо и проект надо пускать вперед.

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

И вот эта самая история нужна, чтобы ее не повторить в новом дизайне.

#анонсы #машины_разное

Согласованный кеш на базе Redis Cluster, Highload Serbia.

https://youtu.be/Sqxsm2oQDsw

Приятного просмотра!

#машины_aws

Крайне неприятным и премерзейшим образом открыл для себя, что подключиться к Aurora Serverless DataAPI из другого AWS аккаунта нельзя. Даже если есть IAM роль с cross-account доступом и этим самым.

Спекулирую, что причиной тому вероятно отсутствие доступа к KMS ключам для дешифровки в Secrets Manager, опять же, другого аккаунта, и решается это путем создания того же секрета у себя, но такой возможности у меня нет.

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

Причем хотелось переключиться на RDS Proxy, чтобы безопасно, так эта зараза тоже хочет в Secrets Manager логины пароли держать.

Как проект будет завершен и отправлен на золото, раскрою подробности. А пока разрешить позлиться.

#машины_aws

А давайте еще неприятное про AWS. На этот раз про непредсказуемое и блокируещее поведение DynamoDB Global Tables, Billing Mode и лимитов.

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

Теперь представим, что реплики работают в режиме primary/secondary, т.е. мы сначала обращаемся к реплике в регионе А, а если что-то идет не так, то в регионе Б.

Поскольку таблица А получает львиную долю запросов, которых очень много, лимиты на употребление W/RCU превышают значение по умолчанию в 40 тысяч. Лимит увеличивается до 100 тысяч, и является верхним значением автоскейлинга. В регионе Б в это время лимит по-прежнему стоит 40 тысяч.

Далее, мы совершим небольшую шалость, и переведем таблицу из режима provisioned в режим pay-per-request, а затем обратно. Вопрос: как поведет себя DynamoDB?

Она, конечно же, не сможет вернуться в режим provisioned!

Следите за руками:
1. Если режим provisioned был с включенным автоскейлингом, при переводе из pay-per-request в provisioned автоскейлинг включен по умолчанию с предустановленными параметрами. "Не включать" его нельзя.
2. DynamoDB принимает решение поставить максимальное значение для глобальной таблицы, а значит и реплик в обоих регионах - в нашем случае 100 тысяч запросов в секунду, как настроено в регионе А.
3. При попытке настроить схожим образом реплику в регионе Б, DynamoDB упадет с ошибкой в связи превышением регионального лимита.
4. Изменения откатятся, обе реплики будут работать в режиме pay-per-request.

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

Lessons learnt, мать его, the hard way.

#машины_разное #люди

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

Как-то раз мне дали одну задачу на собеседование. Задача про пиццу, она же Lazy caterer's sequence, была крутая. Так и не смог понять, как к ней подойти, но я и математику не знаю, что с меня взять. А коллега, давший мне задачу, намекнул, что решение задачи не должно превышать 40 символов, чем вызвал желание написать этот пост.

Зная формулу, решить эту задачу можно в одну строку, а олимпиадники их так наверняка и решают. Однако такое решение имеет мало шансов обеспечить кандидату найм, ведь интервьюер смотрит не только на такие характеристики как эрудицию, отладку и прочее, но и читаемость кода. А все потому что в индустрии код пишется не для машин - компилируемый код машина и так пожрет - но для людей. Если кандидат не в состоянии внятно объяснить свой ход мыслей словами через рот и невербально через код, то о командной работе и сопровождаемости и речи быть не может.

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

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

#машины_разное #люди

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

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

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

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

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

#анонсы #машины_aws

Лучшая книга по AWS CloudFormation получила второе издание!

В новой версии:
1. Переработаны почти все главы в соответствии с изменениями у самого AWS'а, обновлен весь код, и мне за него даже почти не стыдно
2. В главе Advanced Template Development добавлена секция по работе с Language Extensions
3. Глава про Macros была переписана полностью и теперь включает в себя Nested Stacks и Modules
4. Новая глава, посвященная работе с CloudFormation Registry
5. В главе по CDK используется CDK v2

Отдельная благодарность @VasilyPantyukhin и @patrick239 за то, что заставили меня вылизывать все почти до мельчайшего знака препинания!

#машины_разное

Мое пятничное чтиво - история load average (LA), которое, как выяснилось, существует аж с 70х годов прошлого века, и претерпело значительные изменения в 93-ем.

Для тех, кому LA в новинку, рекомендую мой источник. Там и пояснения, и увлекательное детективное расследование.

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

Иными словами, если раньше LA показывало количество процессов "ждущих" процессор, то сейчас оно показывает количество процессов ожидающих любой ресурс.

P.S. Вы наверняка столкнетесь с кадрами, которые считаю LA какой-то бесполезной фигней, например, разработчики Linux.

#машины_aws

AWS будет строить "суверенные" регионы в Еврозоне.

Ставлю, что это нужно для:
1. GDPR/PSD2/других европейских стандартов
2. GovCloud для ЕС

#машины_разное

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

s := someStruct{}
if s.Nested != nil || s.Nested.MoreNested != nil || s.Nested.MoreNested.EvenMoreNested != nil {
  // ...
}

Пропустить такие вещи, особенно обрабатывая сериализованные структуры, любезно сгенерированные gRPC или Thrift, раз плюнуть.

Хорошо, что теперь помимо зорких глаз ревьюера, у меня еще есть NilAway!

#пятничное #новогоднее

Многим из вас знаком закон Конвея, который гласит, что организационная структура и коммуникация между командами отражается на итоговой архитектуре систем.

Существует и обратный закон Конвея, предлагающий растить и развивать структуру предприятия в соответствии с архитектурой системы.

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

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

С наступающим Новым годом! 🎉

#машины_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.

#машины_разное

Если вам вдруг надоело флексить CAP теоремой, значит пришло самое время расчехлять "новый" "тренд" под названием PACELCA

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

В первую очередь, CAP теорема обманывает тем, что мы можем выбрать 2 из трех, в то время как выбрать мы можем одно из двух - А или С. Выкинуть из системы Р нереалистично, да и более того - кто такой этот ваш партишн толеранс? В каком-то случае, пропавший интернет в туннеле уже себе Network Partition, попробуйте предусмотреть это в своей системе.

Вернемся к PACELCA (кто-нибудь, отберите у итшников нейминг, пожалуйста).

Сама по себе эта, даже не теорема, а скорее алгоритм анализа компромисов звучит так: Если нам нужна терпимость к сетевым партициям (P), то мы выбираем между доступностью (А) и согласованностью (С). В противном случае (Else - E), компромис между задержкой (Latency - L) и выбором в сторону согласованности (С) или доступности (А).

Сложно? Сложно. Сначала академики придумали нам устойчивую договоренность, а потом пришли деды из индустрии и из этой договоренности сделала пес знает что. Потому что edge cases. 🤷‍♂️

P.S. В индустрии в принципе есть тренд то на усложнение, то на упрощение. См. прыжки из монолита в микросервисы, из микросервисов в макросервисы, из макросервисов обратно в монолит. В гибкости - сила!

#машины_aws

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

Так, например, в AmazonEC2ReadOnlyAccess добавили ec2:Get*. Все бы хорошо, но действие ec2:GetPasswordData дает администраторский пароль от Windows машины, что, скажем так, уже не совсем read-only 🙂

Изменение довольно шустро откатили. Лишний раз напомню, что лучше дополнительные пару часов потратить на дизайн доступа по Least Privilege Principle, чем потом быть на первой полосе новостей из-за взлома.

#машины_разное

Рик Хулихан, известный политтехнолог NoSQL в свое время разработал стандарт Single Table Design, который подразумевает хранить все поля сущностей в одной, как следует из названия, таблице.

Про STD есть превосходная презентация, которая раскрывает суть, детали и имплементацию. Честно скажу, что это моя самая любимая презентация.

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

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

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

#пятничное

AWS CodeDeploy научился цеплять несколько балансировщиков к EC2 машинам. Это вызвало у меня радость, поскольку я мог вычистить кодовую базу от нескольких хаков, которые пришлось применить, чтобы подружить машину с двумя балансировщиками.

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

Удивительно, что Хаши раньше добавляли новые фичи и сервисы быстрее команды CloudFormation.