Ну и чтоб два раза не вставать: с коллегами из Минска обсудил аварию AWS, пытался понять, чем Boundaries отличается от SSM Session Manager, и почему нельзя пользоваться ничем младше версии 1.0.

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

#машины_aws

Дождались!

Глубокое погружение в DynamoDB, глава 2: Таблицы, операции, вторичные индексы, пропускная способность.

Мой самый большой лонгрид: >4000 слов, приблизительное время чтения - 15 минут.

#жиза

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

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

Из хороших новостей: на 2021 у меня довольно большие планы, как карьерные, так и образовательные. Где-то с начала февраля будете меня снова наблюдать на видео (как только @sonkintammio поможет мне со звуком). Стримить буду на русском и английском, про AWS и про то, что сам учу. Ну и обещал доклад для митапа @AWS_Kz.

В общем жизнь меняется к лучшему.

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

#люди

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

Будучи сотрудником EPAM, я решил взять на себя роль так называемого bar raiser'а. Не то, чтобы я хочу сделать из консалтинговой конторы второй Amazon (масштабы и потребности не те), но хочется по мере сил поднять уровень инженеров, с которыми мне еще работать. Не знаю, много ли нас таких, но официально такое не практикуется (а если практикуется, то я не в курсе).

Так вот, пришел однажды ко мне на техническое собеседование не абы кто, а PhD в области этого вашого Computer Science, да еще и докторской по распределенным системам. Радости моей не было границ - не каждый день можно подискутировать на тему производительности Raft и сложности имплементации Paxos...

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

Раз у нас тут новый год, новые цели (очень грандиозные, кстати!) и новый я, то решение такое: перед собеседованием ни в коем случае не смотреть резюме и предыдущие интервью. Определился с темами на оценку, выписал ряд вопросов и вперед.

#машины_aws

Если в DynamoDB соединить TTL и Streams, то можно получить serverless Kafka.
А если к этому добавить глобальные таблицы, то получится planet scale.

#машины_aws

Ваше выходное чтиво - третья глава по DynamoDB.

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

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

Во время своего выступления Дор Лаор, СЕО Scylla анонсировал новый проект Circe, который в корне меняет структуру консенсуса ScyllaDB.

Взамен Paxos в ядро этого немалоизвестного конкурента Cassandra и DynamoDB будет использоваться Raft, что по словам Дора сделано в угоду консистентности и позволяет быстрее синхронизировать новые узлы в кластере.

Интересно попробовать собрать POSIX FS over Scylla... когда-нибудь.

Всем зашла статья про олдов? Василия знаю лично, и получаю удовольствие не только когда слушаю его, но и когда читаю.

Комментировать статью я не буду, потому что в этом нет необходимости. Расскажу две истории из жизни.

Первый за долгое время пост по тегу #жиза. 🙂

---
Будучи системным инженером на заводе Рено, я отвечал за IP телефонию и автоматизированные контакт-центры на базе Cisco UCCX. Все это чудо чудное было на поддержке от одного крупного оператора связи в России, поэтому ко мне часто командировали одного очень крутого инженера. Как сейчас помню, Серега Лавров. Очень умный и в очках.

Так вот, под монотонный бубнеж записи из IVR, Серега сказал, что пора бы ему менять профиль деятельности и идти в менеджмент. А все потому что я за полгода, что с ним работал, с нуля выучил, как алгоритмы в UCCX делать, да что это за SIP транки непонятные - дескать молодежь технические навыки быстрее обретает, конкурентоспособной становится.

Серега, если ты это видишь - надеюсь у тебя все получилось!

---
На очередном звонке мой шеф делился отзывами о моей скромной деятельности - и одно замечание мне очень понравилось.

По своей гиперактивной природе, я стремлюсь любое изменение дотащить до продукта как можно скорее. Fail fast, fail cheap, trial-and-error, вот это все. Ну и как результат, нарываюсь на преграды, которые надо обходить, а обходить бы не пришлось, будь я несколько предусмотрительней, да и проговори идею с парой-тройкой архитекторов. Всего-то несколько десятков писем, с десяток часовых созвонов по Webex - кого волнуют эти человеко-дни вообще?

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

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

Просто потрясающий lightning доклад про интересные особенности двух небезызвестных языков.

За ссылку спасибо @zn11ch, орал как лама.

Знаете, что мне больше всего нравится в этом видео?

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

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

#машины_aws

Мой “контент-план” по блогам на Январь 2021 официально выполнен!

Вниманию моих читателей - финальная (на данный момент) глава по DynamoDB.
Моделирование данных, лучшие практики, Single-Table Design… И разумеется, полезные ссылки для страждущих!

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

Python: Beautiful is better than ugly
Also Python: https://twitter.com/gvanrossum/status/1354305179244392453

#анонсы

10-ого февраля для сообщества AWS Казахстан я и мои коллеги предоставим интересный контент про всякое!

1. Талгат Нурлыбаев, МУИТ расскажет про академическую программу Amazon AWS в МУИТ и Казахстане.
2. Анатолий Макеев, RedPad Games - про личный опыт использования AWS в GameDev с использованием managed services.
3. Карен Товмасян, EPAM - про тоску смертную под названием Compliance и как с помощью AWS Config и SSM обеспечить полный контроль над состоянием своей инфраструктуры.
4. Непревзойденный Василий Пантюхин, AWS расскажет про конкурентный доступ к файлам и как готовить Amazon EFS.

Выступление будет транслироваться в Twitch.
Время проведения мероприятия: 15.00-17.00 по Москве.

Начинаем через час!

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

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

Очевидное отличие этого интервью от других (например от алгоритмов) - отсутствие одного правильного ответа и какого-то логического конца. Напротив, здесь идет игра против времени и нужно “успеть” покрыть максимум тем.

Поэтому к такому интервью нужно относиться как к reverse bullshit bingo: чем больше ключевых слов вы успеете назвать (CDN, LB, Cache, Queue, DB, NoSQL, SQL, Read/Write API, Sharding, Consensus, CAP, и т.д.) - тем лучше. Интервьюер, cпускаясь в нужных местах пониже, проверяет вашу эрудицию.

Дескать, сказал “балансировщик” - накинь базовые алгоритмы балансировки. Кеширование - caching algorithms и eviction policies. Базы данных - ну расскажи про индексы и какие бывают разновидности. Тут можно помнить, что не все удастся знать наизусть, да и интервьюер не дурак - будет лезть туда, где сам разбирается.

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

Неопытный кандидат в таком случае начинает нервничать - ведь есть где-то “правильный” ответ, который все аспекты учитывает! И ищет собеседуемый серебряную пулю, да не найдет - нет ее. Ваш покорный, кстати, не исключение.

Достаточно сказать: “Да, можно сделать. Но”. И далее списком откупы.

#пятничное

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

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

К чему это я? Буквально на днях, Земфира выпустила… "коллаб" с разработчиками игры, где зрителю предлагается взглянуть на эту историю совсем под другим углом - страх за умирающих в одиночестве родителей, тонущих в жиже из дерьма и масла; тайная любовь, растворяющаяся буквально в руках героя; чувство вины; родной дом и атрибуты детства, разрушающиеся под ударами аукционного молотка.

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

Когда соединяешь квадратики одинакового цвета, в голову лезут разные мысли… но точно не такие.

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

В продолжение https://t.me/manandthemachine/650

Олег очень правильное замечание сделал. Есть "классический" system design, а есть NALSD - Non-Abstract Large System Design.

Иными словами, эскалаторы в ТЦ - это NALSD. Запили мне Инстаграм - это SD.

NALSD очень любят FAANG, потому что к FAANG'у ваши знания кубов и авсов неприменимы - у них свои системы, и учиться работать с ними придется по новой. Там от вас просят набросать некий дизайн, а потом наскоро посчитать сколько и какого размера узлов надо, чтобы обработать входящий трафик с объемом 3.57 Гбит/с.

В обычном дизайне подход более прагматичный и приближенный к обыденности. Он, повторюсь, ожидает от вас reverse bullshit bingo ("назови так много ключевых слов, сколько успеешь") и готовность утонуть там с интервьюером.

Состоит оно из 4 шагов:
1. Сбор требований
2. Высокоуровневый дизайн
3. Низкоуровневый дизайн в некоторых частях
4. Обоснование решения

Что SD, что NALSD, кстати, проверяют умение кандидата ориентироваться в ограниченном пространстве и с минимальным набором требований.

Так, например, у меня был диалог, где я проектировал систему сбора метрик. Как ожидается, я спросил по объемам трафика.

- Ну сам как думаешь?
- Ну у меня порядка 2000 тысяч продюсеров, каждый будет слать метрики раз в минуту. Одна метрика будет висеть.. ну максимум 4 кб. Я могу предположить, что одновременно метрик будет отправляться 10? Или может больше?
- Может больше.
- 100?
- Может и 100, а может и больше.
- Ну тогда два стула: либо я буду начинаю с 10 и делаю throttling, либо считаем ресурсы из расчета 1000 метрик с индивидуального продюсера в секунду. Но это будет неоправданно дорого.

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

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

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