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

Усилия по ускорения 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.

#люди

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

Пост доступен на Медиум. Если по какой-то причине Медиум не работает, пост продублирован на Телега.пх.

Внутри поста:
- как изменилось поведение работодателей
- что писать в резюме, а что не писать
- кто такой этот ваш импакт
- что делать, если рекрутер все никак не позовет

В работе я ориентировался на западный рынок, но некоторые пункты применимы и для России/СНГ.

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

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

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

#машины_aws

Роскошный пример синтеза белошапочников и черношапочников.

https://buckets.grayhatwarfare.com/

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

За находку спасибо Юре @pyToshka