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

Я почти закончил работу над статьей про Serverless.

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

#машины_aws

Должен признать, писать блоги по-русски становится все сложнее и сложнее.

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

#люди

В очередной раз прочитав очередной пост на Хабре про очередное (неудачное?) собеседование в очередную Большую Техническую Компанию, а также комментарии к ней, где люди в очередной раз заявляют о преимуществе простого и понятного кода со сложностью O(n^2) над сложным кодом со сложностью O(logn), я думаю пора поговорить о такой важной в нашей индустрии теме как дальновидность.

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

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

Режим “…, …, и в продакшон” - это этакий кризисный режим работы в условиях цейтнот: катиться надо сейчас, времени думать нет, time to market, impact assessment, blast radius, workaround, и много других прикольных словообразований. А все потому что тут принимается решение: сделать плохо, но запуститься, либо сделать хорошо, но никогда. И бизнес (собственно ваш - вы же мамкин предприниматель) не готов ждать.

И никогда не будет, так уж он устроен. Другое дело, когда вы оказываетесь погруженным в масштаб… Нет, не так.

В МАСШТАБ.

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

Как сказал мой шеф: “Мы проектируем крышу без дома. В нашей профессии так можно, если мы все правильно предусмотрим.”

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

Мне с ними еще интегрироваться потом.

Причем здесь сложность алгоритма? Ну вот пример: вы, внезапно - фронтендер. Запуск вашей компании планируется в понедельник, сейчас пятница, бекендеры не успевают выкатить для вас GraphQL, который эффективно и дешево выдаст нужные данные. У вас два пути - отложить релиз, или воспользоваться уже legacy REST, выкидывая с десяток запросов с клиента при загрузке страницы.

Очевидно, вы пойдете на тот самый архитектурный tradeoff и пожертвуете производительностью продукта в угоду time to market. Заводите себе задачу на рефакторинг, планируете к ней вернуться, когда завезут GraphQL Спойлер - вы скорее уволитесь, чем отрефакторите, но это неважно, потому что когда это станет проблемой (если когда-то и станет), ваша голова будет болеть совсем о другом.

А другой пример и того скучный: для красоты и чистоты и личного удовлетворения, или просто по незнанию прошлись по массиву 4 раза. И все было ничего, пока массив стал не 20 элементов, а 20 миллионов. Масштаб пришел откуда не ждали.

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

#пятничное

Нет ничего прикольнее, чем смотреть, как нудит дед.

Особенно, когда нудит по делу.

#машины_aws

Ребята из MadDevs сделали то, что я хотел как-то попробовать сделать чисто для себя - приватное облако на базе Kubernetes с разбиением по пространствам имен и прочими рюшечками для мультитенантоности.

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

Что я и сделал.

А у меня тут еще один флешмоб!

Friendly Asked Questions #1 — про уникального эксперта

Я руководитель команды из 10 человек. Когда мой разработчик Алексей уходит в отпуск, куча вопросов "встаёт" до его возвращения, нет никого, кто был бы настолько же в курсе отдельных частей проекта. Разработчику это похоже очень нравится, на моё предложение, чтобы он кого-то научил, передал свои знания реагирует агрессивно. Что делать? Если будут проблемы — всех собак повесят на меня.

Ответы дали авторы каналов Уютный Адочек, Человек и машина и Scrum Master Notes
А мы ждём ваших вопросов в: https://forms.gle/sKyaEuqQMMyFJBxJ8

@scrummasters — Василий Зорин

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

@manandthemachine — Карен Товмасян

Ох уж эти Всезнающие Алексеи!
Позволю предположить, что Алексей в конторе был задолго до %username%, иначе непонятно, как подчиненный смог выстроить такую политическую игру.
Не стоит просить кого-то заняться обучением других, это должно быть не просьбой, а задачей.
Если же человек не хочет выполнить такое поручение, то стоит задаться вопросом, не боится ли этот человек потерять ценность для команды и проекта/продукта? Я уверен, нормальная встреча 1-1 приоткроет завесу тайны.
Но предположим, что Леха-карьерист таким образом решил кого-то (вас) подсидеть, и поэтому контакт не налаживается. Решение в таком случае жесткое: уволить и принять удар.
Да, с собаками придется повозиться, но я не слышал ни об одном предприятии, которое закрылось из-за ухода ключевого сотрудника.

@lovely_it_hell — Цупко Игорь

Многое зависит от того, сколько у вас времени на решение этой проблемы и какие есть доп. ресурсы. Когда они есть – можно либо вникнуть самому, либо попробовать организовать каким-то образом вытаскивание информации из Алексея (даже при наличии сопротивления).
Сложнее — если ресурсов нет.
Мне бы в первую очередь хотелось поговорить с Алексеем, чтобы, а) показать ему, что его job security в порядке и будет таковым; б) его ценят и любят за его экспертность и это так и останется даже если он будет делиться знаниями; в) понять его мотивы и попробовать придумать, как в них (и возможно ли) в них встроить идею о передаче знаний.
Если удастся договориться с Алексеем, то вытаскивание и распространение знаний станет уже его осознанной и прямой задачей и останется только помогать ему методологически и ресурсно. А если не удастся — надо попробовать найти способ аккуратно разойтись.

#пятничное

Да, я добавил комменты!

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

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

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

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

Это не я, это все пандемия ваша дурацкая!

По рекомендации приятеля вступил в клуб Вастрика, а раз я несу кому-то деньги (целый доллар!), то хочу их отбить (целый доллар!!!). Вот так я и прочитал Ту Самую Статью Про Квантовые Компьютеры, увидел словосочетание "Отрицательная Вероятность", и теперь это словосочетание не дает мне покоя.

Собственно, к чему я это все? К тому, что можно по-разному чувствовать себя в индустрии и профессии, но мой личный кайф в ощущении себя глупым. А чем дальше поднимаешься по карьерной/профессиональной лестнице, тем меньше остается неизвестного.

И я сейчас не про known unknowns, я осведомлен, что есть машинное обучение, микрофронтенды, Rust и даже C++ - словом, все, что я и так не знаю и могу сесть изучать, но это "не то".

Интерес именно в unknown unknowns, особенно когда те перестают быть unknown. До отрицательной вероятности меня так взбудоражило только внутреннее устройство индустрии телевещания. Одни только digital assets с метаданными чего стоят.

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

По долгу (уже новой) службы мне приходится иметь дело с PCI-DSS - набором регуляторных требований к программным продуктам, которые хранят и/или обрабатывают информацию с платежных карт.

У PCI есть одно интересное требование, которое в упрощенной форме гласит: "разработчики не могут разворачивать свой код в production". Это очень интересное требование, потому что под "разработчика" может попасть каждый, кто вносит изменения в кодовую базу, попадающую под PCI.

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

Поэтому PCI сам собой вносит небольшой silo - в цепочке поставки обязательно должна быть Кнопка Валидации, которую должен нажать Специальный Уполномоченный Человек.

Не сказать, что это сильно влияет на скорость доставки, если только не гореть желанием катиться 20-30 раз в день, и есть надежная интеграционная среда - в таком случае можно собирать изменения и катиться раз в неделю, соблюдая все ритуалы.

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

Friendly Asked Questions #3 — про уровень зарплат

Почему мы платим разные зарплаты сотрудникам на удаленке? У них одинаковые должности и обязанности, но один находится дома в Москве, а другой дома в Саратове.

Ответы дали авторы каналов Уютный Адочек, DocOps, Человек и Машина, Евгений Потапов
А мы ждём ваших вопросов в: https://forms.gle/sKyaEuqQMMyFJBxJ8

Евгений Потапов (канал @eapotapov_channel)

Платить на удалёнке разные зарплаты для разных регионов выглядит странной затеей в 2021 году. Такой тренд был давно (и не только в РФ), когда можно было в регионах с более низкими зарплатами нанимать дешёвые кадры, но, имхо, сейчас ситуация уже сильно изменилась и рынок сформирован компаниями, которые платят универсальную зарплату без привязки к региону.

Карен Товмасян (канал @manandthemachine)

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

Поэтому даже приехав из уездного города N, где зарплата была 30к, в Первопрестольную, то ценник сразу обретает нолик с конца, что работает и в обратную сторону. Не вы первый задаетесь этим вопросом, кстати. 😉

Ник Волынкин (канал @docops)

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

Цупко Игорь (канал @lovely_it_hell)

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

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

Гвидо ван Россум, отец Python и вернувшийся из пенсии в Microsoft инженер, поставил перед собой очень амбициозную цель, а именно - увеличить производительность своего детища аж в два раза.

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

Впрочем, мой интерес чисто технический, что именно собираются сделать для увеличения производительности? Поэтому я открыл PEP-554, автор которого отдельно отмечает, что не намерен решать проблему GIL (но мы-то с вами все понимаем).

Способов обойти GIL и так хватает: от использования multiprocessing до других движков, например PyPy.

PEP-554 интересен тем, что предлагает по-новому взглянуть на sub-интерпретаторы и (пере)изобрести конкурентное программирование. Причем пользоваться эти можно будет донельзя легко. Вот кусок кода, прямиком из PEP:

interp = interpreters.create()
print('before')
interp.run('print("during")')
print('after’)

Но не это самое “вкусное”. Если пройти дальше по предложению до раздела “About Subinterpreters”, то можно увидеть слово, которое очень знакомо разработчикам на Golang - каналы! По словам автора Предложения, каналы будут единственным объектом, доступным всем интерпретаторам, а обмен объектов будут проходить через них.

Подытожим: в версии 3.11 собираются ускорить CPython, и поможет нам в этом новый модуль interpreters, который имплементирует конкурентное программирование, схожее с Golang.

Вот что скучная пенсия с людьми делает!

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

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

Оно и очевидно, observability попала в “тренды” незадолго после появления eBPF, и к кому бы не сходить за ее определением, как к одному из пионеров индустрии… Однако, получаем больше вопросов, чем ответов.

По сути, что одно, что второе имеют схожее определение, да и решают одну и ту же задачу - знать о состоянии системы.

Отличий как таковых и нет - наблюдаемость дополняет мониторинг. Если мониторинг опирается на определенные метрики, глядя на которые можно понять, как чувствует себя программный продукт, в инструментарий observability еще входят обработка логов и отслеживание запросов (tracing).

Что позволяет “наблюдать” не только за одной системой, но и ее связкой с остальными.

Спорим, это снова Cloudflare?

UPD: Ан нет, на этот раз возможно Fastly.

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

Прекрасный повод в очередной раз поделиться одним из моих любимых докладов.

#машины_aws

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

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

Отправить бекап диска виртуальной машины или базы данных - задача частая и вполне стандартная. И шифровать эти самые бекапы тоже идея не из глупых. Шифрование делается с помощью мастер-ключей конкретного аккаунта - Customer Master Key или CMK.

Так вот раньше (а точнее до вчерашнего анонса) эти ключи были уникальны на регион, что означало следующую цепочку действий.

1. Делаем нешифрованный бекап
2. Копируем в другой регион
3. Шифруем

Дела были еще хуже, если бекап автоматически шифровался:

1. Дешифруем шифрованный бекап
2. Копируем
3. Шифруем!

Стоит ли добавить, что помимо потраченного времени на дешифрование/шифрование, каждый поход в KMS за ключом стоит денег и отражается в счете?

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

Впрочем, у AWS'а 1000 и 1 способ от таких историй защищаться.

#люди

Говорят, на этом докладе можно увидеть авторов @anykeynotes и @manandthemachine.

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

Навеянная историей грандиозного рефакторинга Lingualeo (поищите в сети, если не застали), интересная находка.

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

P.S. Для веб-хипстеров есть и GraphQL-версия.

#машины_aws

На той неделе AWS выкатил интересное, но спорное по полезности обновление.

Правила Security Group обзавелись собственными идентификаторами, а значит стали де факто отдельными ресурсами. Базово о практическом применении можно прочитать здесь.

В целом, у новой функциональности хватает плюсов. Во-первых, если одно правило используется несколькими SG одновременно, то не придется больше ходить и везде их менять (до этого “общее” правило цепляли на отдельную SG и назначали на все нужные области сети). Во-вторых, это упрощает управление, если за правило отвечает другая группа - теперь она может сама поменять, что нужно, а не заводить, ну не знаю, Change Request. В-третьих, это безусловно хорошая внутренняя оптимизация, которая положительно повлияет на квоты и лимиты (или нет).

Однако есть жирный минус - правила, пусть и со своими идентификаторами, все еще не живут без самой SG и заводить их отдельно нельзя. А бонус от изменения, описанный в примере выше, применим к тем, кто по какой-то причине управляет своей инфраструктурой только через Bash и awscli.

Как будто хотя бы одна маломальски серьезная организация так делает.

К сожалению, новая “фича” выглядит сыроватой, а анонс словно сделан в спешке. Тем не менее, если правила смогут стать полноценным независимыми сущностями и попадут в RAM, то просторов для использования много.

#жиза

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

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

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

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

Но чего я не могу понять, так это бессмысленной, на мой взгляд, экономии умственных сил. Ну то есть, что произойдет, если 5 минут потратить на выбор блюда на завтрак или одежды? Мозг лопнет? "Таски" не закроются?

Стоит ли настолько скупиться мозгом для себя, чтобы отдать его с концами на работу? Зачем копировать повадки Джобса и Цукерберга?

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