#ненависть #оффтоп

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

Кто ждал запись - вот она

#API

В разговоре отличное сравнение возникло: уровни зрелости REST API это как нормальные формы БД - описывают подходы к проектированию, но никак не отвечают на вопрос эффективности. Зрелый и нормальный - не значит эффективный для текущей задачи.

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

Хотя само слово “зрелость” выбрано максимально неудачно - Ричардсон, иди думай еще.

Классная мини книга про вебсокеты.

• История и проблематика
• Детали работы протокола
• Масштабирование и отказоустойчивость

#интеграция

#интеграция #архитектура

На фоне стабильной тенденции к переходу из аналитиков в архитектуру не менее стабильно возникает вопрос: “А как это делать вообще?”

Есть минимум два варианта:

— закопаться в книгах по архитектуре и штурмовать вакансии архитектора

— понять, что уже есть для нужной роли, и постепенно двигаться к ней, отбирая у кого-нибудь подходящие задачи

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

Сначала копнем в работу сетей и инфры, чтобы понять влияние на выбор технологий. Здесь же разберемся, как и почему работает балансировка. Дальше начинаем думать о надежности, и учимся использовать circuit breaker’ы, адаптивные ретраи и другие паттерны отказоустойчивости. Где-то рядом придется задуматься о производительности и кэшировании, а там и выборе технологии под кэш. А потом потребуют развесистый бизнес-процесс реализовать на несколько сервисов, и вот вам проектирование распределенной системы с транзакциями.

Таким образом получаем трек: локальные интеграции -> интеграционная архитектура -> полноценный сисдизайн. Останется еще с хранилищами попрактиковаться.

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

#интеграция

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

Рега тут

Эти выхи буду на WAW. Кто еще там? Го чай пить и знакомиться.
А завтра утром веду воркшоп по сисдизайну - заходите, чтобы посмотреть, чем мы в нашей архсекте занимаемся.

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

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

Категорически рекомендую как нанимающим лидам, так и кандидатам.

У меня лишь один вопрос остался: если вот это все делает аналитик, то чем вообще занимается разработка?

WAW 2025

На выхах добрался до WAW, который оставил неожиданно приятные впечатления. За счет небольших размеров получилось очень лампово и душевно, было время обсудить интересное. Только 1,5 дня мало((

Выделялись три основных темы: сисдизайн, лидерско-манагерское, AI. Трек сисдизайна получился особо удачно, спасибо Ане Вичуговой, Зое Степчевой и скромному мне. Надеюсь, никого не упустил?

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

Я же делал воркшоп по сисдизайну, где разбирали кейс доставки карты в сокращенном виде. Прошло бодро и активно, 5 из 6 команд дошли до конца, все довели решение до рабочей версии.

Несколько закономерностей, которые заметил еще в рамках нашего кейс-клуба:

Реализация НФТ
Характерное поведение аналитика: определить требования к нагрузке, доступности, масштабированию… и забыть про них. Не происходит валидации, как мы реализовали требования на уровне архитектуры, основное внимание уделяется бизнес сценариям. Не надо так;)

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

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

На другие секции удалось только мельком заглянуть, ничего конкретного не скажу.
Спасибо оргам и всем участникам за конфу, встретимся через год ❤‍🔥

#конференции

Отправка событий от бека к фронту

Лень монтажить вебинар, пока вынесу с него интересный вопрос:

- Если WebSockets, HTTP/2, SSE позволяют слать сообщения с бека на фронт, то почему в основном говорят о WebSockets для двухстороннего взаимодействия?

Server Sent Events
Чтобы получать события с сервера клиент кидает GET-запрос с указанием в заголовках, что хочет сохранить соединение и получать события. Если сервер так умеет, то создается длительное соединение, и он начинает слать сообщения клиенту, пока кто-нибудь соединение не закроет.
Работает SSE поверх HTTP/1.1 и выше.

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

Если честно, я даже не знаком с людьми, которые использовали SSE. Нашел пару примеров:
⁃ В SuperJob их юзают просто чтобы не заморачиваться, как я понял.
⁃ Тут их используют для реализации subnoscriptions в GraphQL. Ну ок, есть логика

У вас был такой опыт? Поделитесь в комментах, плз.

HTTP/2
Взаимодействия между клиентам и сервером делятся на стримы. Каждый стрим состоит из одного request-сообщения и одного response-сообщения. Каждое сообщение может состоять из одного и более фреймов.

Причем сервер может начать слать фреймы ответа до того, как получил от клиента все фреймы ответа. Причем количество фреймов неограничено, и я необязан указывать его в первом фрейме сообщений. Такой вот стримминг внутри стрима получается. Внезапно, правда?

Получается, что внутри стрима мы можем слать фреймы в двух направлениях. НО - создать стрим может только клиент. Т.е. парадигма request-response в протоколе сохраняется.

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

На практике проще сразу брать gRPC, который использует эту механику. Но это новый стек, новые проблемы.
Либо заюзать те же SSE.

Почитать: Хардкорный разбор HTTP/2

WebSockets
Полнодуплексный протокол, в котором мы устанавливаем соединение, клиент кидает GET запрос с нужными заголовками и вместе с сервером переключается на общение поверх вебсокетов. Клиент и сервер могут в произвольном порядке слать друг другу сообщения, пока кто-нибудь не закроет соединение
Работает поверх TCP.

Позволяет слать события только в обе стороны: сервер <—> клиент.
Сложнее в реализации, чем SSE, т.к. многие не умеют его готовить, нужно затаскивать новый протокол и тулинг в проект.

Почитать: основы вебсокетов, мини книга с погружением.

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

#интеграция

#манагерское

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

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

Как продакту, мне интересно делать идеальные продукты с совершенным UX и мегафичами, кастдевить пользователей и получать восторженный фидбек. И чтобы все было аналитикой обвешано - тестить дерзкие гипотезы и дизраптить рынок. Потому что это мегакруто. Правда еще выручку растить нужно, и чтобы экономика сходилась, иначе инвесторы денег не дадут. А тут эти технари с нытьем про техдолг и костыли.

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

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

#архитектура

Есть академические штуки, о которых много говорят, но непонятно, как их применять на практике.

Например, CAP-PACELC теорема. Она рассматривает синхронизацию между нодами хранилища и задает нам два простых вопроса:

— Если сбой, что важнее: консистентость или доступность?

— Если штатно, что важнее: консистентность или скорость отклика?

Круто, и что мне с этим делать? Я архитектуру кафки и постгри проектировать не собираюсь. Чтобы кто-то садился и задавался вопросом: “Какую же модель мне выбрать для сервиса заявок: CP или AP??” - тоже никогда не встречал. Тогда зачем мне это кроме шаблонных собесов?

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

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

Есть пара: процессинг заказов и платежный сервис, что критичнее
— консистетность или доступность?
— консистентность или время отклика?

А для пары процессинг заказов и бухгалтерия?

Из ответов следует выбор модели strong / eventually consistency. А из этого следует, как будем управлять распределенными транзакциями: оркестрация, хореография, воркфлоу и т.д. А из этого, где нам нужны будут ретраи с идемпотентностью, а где события будем кидать.

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

Часто фундаментальные концепции из computer science не дают конкретные рекомендации для локальных задач, но позволяют расширить сознание, чтобы более системно и целостно подходить к проектированию.

#архитектура

Выложили записи докладов с ArchDays’2024.

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

Работа Кафки просто и наглядно

Шикарная визуализация работы Кафки: https://softwaremill.com/kafka-visualisation

И менее шикарная, но тоже пригодится: https://evoura.com/kafka-traffic-visualizer

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

Разбираемся с основами, начинаем здесь:

1. Установите: 1 брокер, 1 консьюмер группа, 1 консьюмер, 2 партиции. Посмотрите, как сообщения распределяются между партициями.

2. Добавьте второго консьюмера в существующую группу. Посмотрите, как распределяются между ними сообщения.

3. Добавьте третьего консьюмера в существующую группу. Посмотрите, как распределяются между ними сообщения.

4. Перенесите третьего консьюмера в отдельную консьюмер группу. Сравните потребление сообщений в двух консьюмер группах.

Теперь понаблюдаем за работой с ключами, переключитесь сюда:

5. Установите 2 партиции, key range = 4. Посмотрите как сообщения с одинаковым ключом распределяются между партициями

6. Установите 3 партиции, потом 4.

7. Установите 6 партиций. Что изменилось? Почему так происходит?

Возвращаемся в основной симулятор:

8. Установите: 2 брокера, фактор репликации - 2, 1 консьюмер группа, 1 консьюмер. Посмотрите, где и как реплицируются партиции и сообщения.

9. Установите: 3 брокера, фактор репликации = 2. Посмотрите, как теперь работает репликация.

10. Установите: фактор репликации = 1. Посмотрите, как теперь работает репликация.

11. Установите: фактор репликации = 3. Обратите внимание, как распределяются между брокерами мастер-партиции (яркие) и их реплики (блеклые)

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

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

#брокеры

#брокеры

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

Нашелся репозиторий вида "все про интеграцию": технологии, паттерны, протоколы. Не знаю, как использовать, но может вам полезно будет: https://github.com/stn1slv/awesome-integration

#манагерское #книжное

Уже писал, что "требований" как вещи-в-себе не существует.

Ибо нет человека, который точно знает: если (не) сделать Х, то мы получим такой-то профит / урон. Бизнес всегда оперирует неопределенностью и вероятностями. Исключениями могут быть:

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

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

Что тогда приносят стейкхолдеры, продакты, бизнес-эксперты? Да что угодно: боли, хотелки, потребности, готовые решения, поток сознания - причем никогда не угадаешь, что они принесли в этот раз. Тогда что делать? Разбираться в людях и контексте.

Мне в этом плане нравится книга The Mom Test / Спросите вашу маму

Кратко суть:
 • все люди врут
 • люди врут потому, что вы их провоцируете постановкой вопросов
 • как разговаривать с людьми, чтобы извлечь полезную инфу

Кому стоит прочитать:

 • Продакту и заказчику - чтобы понять контекст и проблемы клиентов / пользователей

 • Аналитику и тимлиду - чтобы понять, зачем эта фича нужна заказчику

 • Разрабу и QA - чтобы понять, зачем аналитик запихал этот метод в апи

 • Владельцу внутренней платформы типа ESB, CI/CD и т.п. - чтобы заранее планировать развитие ваших сервисов

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