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

Недавно Коля (@mykola7799) написал с вопросом, не знаю ли я кого из разработчиков YDB. Пока мы с ним обсуждали, что за прекрасная СУБД эта ваша ЙДБ, возник дискуссионный момент - раз УайДиБи распределенная СУБД, и она поддерживает ACID-транзакции, то она нарушает САР.

И тут я крепко призадумался, потому что САР нарушить невозможно.

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

Мы часто думаем про С (консистентность) и А (доступность), но забываем про P (partition tolerance - не знаю, как правильно перевести). Partition tolerance подразумевает, что при разрывах в сети система будет обслуживать трафик в штатном режиме.

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

Узел же, конечно, об этом ничего не знает и искренне верит, что вернул нам консистентные данные... но об этом вы уже читали в кабанчике.

В комментарии приглашаются причастные к YDB, подтвердить/опровергнуть мое мнение. Да и Коля хочет познакомиться!

P.S. Надо уже взять себя в руки и написать уже про это вашу строгую консистентность в распределенных системах.

#пятничное

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

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

Поиск "лучшее из литературы" очевидно выдал мне "По ком звонит колокол", а заодно рассказал, что Эрнест лауреат нобелевки.

Абсолютно не проникся и читаю "Колокол" только для галочки, не люблю бросать начатые книги. Жизнью Хемингуэйа тоже не заинтересовался (знал только, что он застрелился из дробовика), пока не нарвался на ультракороткую биографию.

Чем и делюсь с вами.

#пятничное

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

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

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

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

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

#машины_aws

Теперь, когда у нас есть AWS SDK для SAP ABAP, какой язык будет следующим?

Ставлю на COBOL.

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

Потрясающе интересная археологическая история о том, как появился Python.

#машины_aws

Особо за re:Invent не слежу, потому что вкатился в backend разработку, а с AWS'ом дел имею редко.

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

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

У меня увольняется коллега, и я как-то спросил его за перерывом на смузи с тапиокой (перечитал, что написал, и самого передернуло), ради чего он уходит на новое место.

Коллега, надо уточнить, уходит из Убера в логистическую контору масштабом поменьше, но на должность повыше, из Staff'ов в Senior Staff'ы.

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

Я про себя тогда хмыкнул: кто ж тебе, сеньор стаффу, делать что-то руками даст, ты же очень дорого!

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

Мне такое в только в радость, пара кликов и команд, и все красиво само работает из коробки.

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

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

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

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

Вернемся на 30 лет назад. Типичный сисадмин, в зависимости от размеров и специфики конторы, отвечает за программно-аппаратный комплекс в определенной степени. Если представить себе торт из таких слоев: приложение - зависимости - midlleware (читай, какая-нибудь WebSphere/Weblogic) - ОС - прошивка железа - железо; то сисадмин владеет всем до midlleware.

Затем происходит НЕЧТО, из-за чего сисадмин учится масштабировать свою работу и берет на себя роли build и release инженера, начинает тащить всякие Jenkins’ы с Ansible’ми. Граница "владения" медленно ползет вверх, наш сисадмин чуть ли не сам код уже пишет, а некоторые и пишут!

Затем опять происходит НЕЧТО, и сисадмины на время исчезают. Теперь у нас есть инженер, который управляет какой-то облачной инфраструктурой, суть-то программируемыми абстракциями. Дай мне виртуальную сеть, виртуальную машину, виртуальную оркестрацию контейнеров, виртуальный кластер баз данных - словом, инфраструктура вроде как есть, но ей и управлять особо не надо. Тогда сисадмин, а ныне модный SRE/DevOps инженер может выступать в двух ипостасях.

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

Облачные провайдеры вовсю продают fully managed сервисы; всерьез идут разговоры о NoOps и даже Low Code; машинное обучение подсказывает готовый код; я заношу виртуальное перо над своим блогом, ведь вот она, эта прекрасная индустрия будущего!..

Как вдруг мою виртуальную руку с виртуальным пером нежно хватает незнакомец в маске. На ней красивым шрифтом светится надпись Platform Engineer, и незнакомец, медленно качая головой, говорит: "Еще рано." Я с недоумением смотрю на него, но погодя на меня снисходит озарение. Я снимаю маску с гостя и узнаю в нем того самого Системного Администратора!

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

Раньше сисадмин давал вам проприетарный интерфейс VMware с минимальным доступом к созданию виртуалок в своем пуле ресурсов, а теперь у вас есть красивый удобный UI и куча автоматики, чтобы вам не приходилось думать лишний раз.

Тупиковая ли это ветвь эволюции или еще один виток, покажет история.

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

Тонкое искусство наблюдаемости (оно же observability), прошло не один десяток лет, прежде чем заматереть.

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

После SRE научил не просто мерять сигналы, а выработать некий стандарт из 4 золотых сигналов , тот же Брендан Грегг использует метод USE (Utilisation/Saturation/Errors) для выявления проблем с производительностью.

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

Если отвлечься от технической части, то наблюдаемость нам нужна, чтобы ответить на вопрос “Оно работает?”, и этот вопрос куда сложнее, чем многие думают.

Автор этих строк помнит активные дискуссии на том же Хабре и тематических чатах времен 2014-2018, когда сильные умы мира сего задавали эти титанически сложные вопросы “А что значит не работает?”, “А что мы понимаем под работой?” или мое любимое “А когда оно у вас в последний раз работало?”.

Очевидно, что работающая система это та, которая выполняет свои задачи. Система может работать в нормальном или деградированном режиме, может совсем не работать, тут уже как мы контракты написали. Для того, чтобы определять “рабочесть” у нас есть огромный пласт методов и инструментов. Все они направлены на то, чтобы научить приложение говорить от своего лица о своем самочувствии, так что в целом все логично.

Но я не зря написал про толкования “рабочести” и изменчивость нашей индустрии. Видите ли, система может быть по всем фронтам “здоровой”, значения метрик приемлемыми, пейджер тихим, дежурство спокойным… А система все равно не будет работать! 😱

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

Определить это немногим сложнее, чем набросать метрик и логов в нужных местах нашего кода. Достаточно взять бизнес-метрики на определенные процессы, строить по ним графики, выявлять аномалии и несовпадения. Лукавить не стану, на практике это не так тривиально, как на словах.

Например, если у нас есть определенный SLA на техподдержку, то рабочая система такая: 10 человек завели по жалобе, 10 жалоб создалось, 10 жалоб получили по назначенному специалисту ТП, 10 жалоб разрешилось в рамках SLA. Любое отклонение - вне зависимости от причин - является симптомом нерабочей системы. 🎉

---

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

С наступающим!

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

Своих дорогих читателей, соратников и друзей, я хочу поздравить с наступающим, а для кого-то наступившим Новым Годом!

Оставайтесь здоровыми и находитесь в кругу близких вам людей и союзников. Пусть 2023 будет к вам благосклонен!

Мирного неба над головой!!

Искренне ваш,
Чел и Маш. :)

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

Я посмотрел на The state of open source software и заметил пару очень интересных моментов, которыми хочу с вами поделиться.

Python выбился на второе место среди популярных языков.

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

Конторы продолжают инвестировать в open source.

Что не новость, да и хитрость. Такие проекты повышают имидж и привлекают большое количество бесплатной рабочей силы. 🙂

HCL - самый быстрорастущий язык на GitHub.

Вот это очень интересно при условии, что HCL не язык программирования, а DSL. 🙂 Что однако не мешает писать на нем скрипты, судя по его README.

#машины_aws

У меня есть программа, которая выполняет следующее действие:

def pin_lt_version_to_asg(asg, asg_name, lt_name, lt_version):
    return asg.update_auto_scaling_group(
        AutoScalingGroupName=asg_name,
        LaunchTemplate={
            'LaunchTemplateName': lt_name,
            'Version': lt_version,
        },
    )

Мозгом я понимаю, что мой код сделает вызов autoscaling:UpdateAutoScalingGroup, и разрешаю это действие в IAM.

Запускаю код, получаю следующую ошибку:

botocore.exceptions.ClientError: An error occurred (AccessDenied) when calling the UpdateAutoScalingGroup operation: You are not authorized to use launch template: myTemplate

Неожиданно! Окей, Гугл, какие еще действия нужно добавить в политику? Беглый поиск привел меня в StackOverflow, где решением было, конечно же, дать EC2FullAccess.

"Вздор!" - подумал я, сходил в документацию и увидел там тоже самое. 🤦‍♂️

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

Утечки утечками, а в этом коде еще разобраться надо будет!

Из очевидного вижу статический анализ кода на какие-нибудь CVE + захардкоженные секреты.

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

Безопасникам Яндекса сил и терпения. Разгребать это придется долго, знаю по печальному опыту.

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

Моя лента в Твиттере - пачка академиков и технологов, от которых я узнаю всякие оккультные вещи навроде CRDT.

И вот в мою ленту занесло волной превосходный срач дискурс между Риком Хулиханом и Алексом ДеБри, темой которого были транзакции DynamoDB.

Из него я узнал, что:
1. Транзакции не предоставляют настоящий ACID. Item'ы, записанные в транзакции, доступны к чтению до того, как транзакция завершена (Read Commited). Это создает проблемы при конкурентном доступе.
2. Транзакции - дорогая в разработке фича, которой мало кто в итоге пользуется.

По схожей логике я не стал включать транзакции в серию DynamoDB Deep Dive. Неканонично.

Этот спор был особенно интересен тем, что Рик - бывший амазонец, эксперт NoSQL и изобретатель Single Table Design, а Алекс - автор DynamoDB Book.

Как если бы Алексей Миловидов и Брендан Грегг схлестнулись на тему производительности.

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

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

Такого рода поиск познакомил меня с CRDT и проектом Automerge. Но для того, чтобы объяснить сначала рассказать, как работают конкурентные записи, и при чем тут Google Docs.

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

В так называемом "коллаборативном" ПО (доски Miro, Google Docs), важно обеспечивать конкурентный доступ без перезатирания данных. В Google Docs используется механизм Operational Transform, который обслуживает транзакции на уровне операций. CRDT же опирается на состояние - то есть вы набили текст в документ, состояние документа зафиксировалось и улетело на сервер. Далее сервер уже сверяет разные состояния от разных авторов.

Чем же это интересно? Тем, что CRDT направлен на децентрализацию и local-first коллаборацию. Его идея - я должен иметь свои изменения в том виде, в котором указал, а дальнейшая резолюция должна быть под моим контролем. Технические реализации CRDT обеспечивают работу не только с центральным сервером, но и децентрализованно.

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

#люди

На Хабре вышла статья Практикума о том, как живется наставникам и ревьюерам.

Если вы учитесь и хотите видать картину "по ту сторону" или рассматриваете работу в ЯП - милости прошу. Мое видение там тоже есть.

#жиза

Как похорошела Москва бюрократия при Собянине Мишустине!

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

С Россией меня преимущественно связывают личные отношения, так что я со спокойной душой приступил к выполнению своих обязательств. Запускать процедуру выхода из гражданства в России мне не хотелось, а значит нужно прогуляться до консульства в Гааге 3 раза, чтобы:
1. Выписаться из отчего дома
2. Забрать справку, что я выписался из отчего дома
3. Подать заявление на выход из гражданства

Задача тривиальная, но запись в консульство еще во времена COVID-19 было тем еще приключением, а с 22-ого года стала практически невозможной. Дровишек в костер подкидывает и местное правительство, проводя сокращение штата русских консулов в Нидерландах... Словом, на момент написания этого поста запись в консульство в Нидерландах невозможна.

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

Здесь надо сделать одну ремарку о бюрократии. В Нидерландах я практически любое действие я совершаю онлайн, авторизуясь с помощью ЭЦП, а визиты в офис миграционной службы нужны только чтобы сдать биометрию или забрать бумаги. С Россией же у меня была стойка ассоциация “собери 10 бумажек из 12 разных мест, приходи в определенный день недели”. Впрочем, с русской бюрократией я дел практически не имел, как переехал.

Так вот, в чем казус: почти все бумаги для выхода из гражданства РФ, кроме справки о выписке, я могу сделать онлайн и в электронной форме с ЭЦП! А вот чтобы уведомить миграционную службу Нидерландов о том, что я вышел из гражданства, мне нужно отправить бумажное письмо с переведенной справкой от консульства! Более того, чтобы запросить отсрочку (!!!) дедлайна, я тоже должен отправить бумажное письмо!

Чья бюрократическая машина теперь эффективнее - вопрос открытый.

#пятничное #люди

Открыл блог про то, "как создавать высокопроизводительные инженерные команды".

"Шаг 1: Наймите топовых инженеров"

Закрыл блог.

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

Обещанный пост про блокировки!

Если совсем просто, то механизм блокировок (lock) реализуется с помощью обычной хеш-таблицы/словаря/чего-бы-то-ни-было. Ключом к этому словарю обычно является сам объект блокировки, а значение - некий идентификатор/токен замочка.

Объектом блокировки в данном контексте может быть что угодно. Довольно древний, по современным меркам, storage engine MySQL под названием MyISAM блокирует целые таблицы, а более новый InnoDB - строки. Продвинутый механизм блокировок в PostgreSQL, который задействует snapshot isolation - блокировка назначается на строку, но в определенный момент времени! Записи, в том числе обновления и удаления данных, в таблицах Postgres, работают в режиме append only, заправляя это все крепеньким vacuum’ом, ну или как там это называется, знатоки пусть меня поправят.

Локальная система блокировок существует в памяти СУБД.
1. Подключился к СУБД
2. Запрашиваешь “замочек” на строку Х в таблице У (acquire lock)
3. Получаешь некий токен “замочка” - механизм тебя “запоминает”
4. Производишь запись, “освобождаешь” замок (release lock)

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

Но если вы работаете в смузихлебном стартапе, то скорее всего вы живете в условиях распределенных систем, а значит у вас распределенные хранилища, а возможно и распределенные системы блокировок!

И если вам сейчас показалось, что я несу откровенную чушь - то зря. В SRE книге Гугла в 4-ой главе рассказывается про распределенную систему блокировок Chubby. Другим примером распределенного замочка может быть ситуация, когда вы хотите заблокировать некую сущность в пределах нескольких независимых систем. Распределенный замок может быть реализован и в рамках самой системы, например Redlock в Redis. Мы к этому еще вернемся, но тут важно уточнить, что Redlock это фича для потребителя, а не внутренний механизм для работы с запросами.

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

Решается это еще интереснее, и вот тут я хочу поделиться наинтереснейшей статьей от автора того самого Кабанчика. Там вам и про блокировки, и почему Redlock говно. Не потому что Redlock, а потому что в распределенных системах все говно, если хорошенько докопаться.

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

История о том, как Amazon Prime, стриминговый сервис, мигрировал часть своего кода с AWS Lambda на монолиты в виртуальных машинах, вызвала пусть и дебильную, но предсказуемую реакцию.

Почему дебильную? Потому что любой, кто работал с AWS, знает, что рантайм Lambda поминутно дороже ЕС2, а serverless сильно дороже на больших мощностях. Serverless стек подходит для маленьких контор с минимальной нагрузкой (считай, не больше 100 запросов в секунду) и инженерным штатом из 3-5 человек, компетенции которых хватает на то, чтобы быстро написать код и запустить.

Все, что тяжелее, решается усилиями очень дорогих SRE/DevOps/PlatformEng, зарплаты которых дешевле расходов на инфраструктуру. Но сейчас не об этом.

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

Выходит, колесо Сансары таки сделало огромный оборот. Такими темпами еще и к частным ЦОДам на собственном оборудовании вернемся и будем правы.