О планах на март

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

15 марта очередная встреча кейс-клуба, будем проектировать выпуск виртуальной карты, думать об управлении процессом, вспоминать о CQRS. Кто каждый раз просит напоминалку - вот она.

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы же поняли, к чему я?
На курсе интеграция и архитектура в распределенных системах раскопаем тему. Это last call, он звонит по тебе. Стартуем в воскресенье, в этом полугодии проводить больше не буду.

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

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

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

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

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

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

#API #интеграция

Пока запись вебинара в пути, расскажу про наш курс по проектированию API.

Когда-то он возник как короткий интенсив для начинающих, чтобы научиться базовым вещам: протокол HTTP, каноничное REST API, документирование в OpenAPI (Swagger), тестирование через Postman.

Эта программа давала участникам набор инструментов, которые позволяли успешно работать “с классическим рестом”. Увы, мир несовершенен, и каждый однажды слышит:

— Зачем все эти ваши глаголы?! Я все через POST сделаю - упирается разраб

— Не трогайте статус коды, у нас на них мониторинг завязан! - кричит инфра

— Вот вам драфт макетов, сделайте хорошо - невинно заявляет заказчик

Поэтому мы добавили в программу:

• Проектирование взаимодействий от бизнес-требований до реализации в API

• Альтернативы REST API для сложных пользовательских сценариев

• Асинхронность и HTTP

• Что важно учитывать с точки зрения мониторинга и инфры

Так небольшой интенсив превратился в полноценную подготовку по проектированию боевых API, после которой можно осознанно принимать инженерные решения и защищать их перед коллегами, а не ссылаться на асбстрактное: “Так нам в REST завещали”.

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

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

Все, хватит салатов, просыпаемся.

Детальный разбор реализации Transactional Outbox, когда у тебя постгря с кафкой. Варианты реализации, проблемы, инструменты - просто и понятно. Отдельно можно скачать презу.

Здесь можно подробнее почитать, зачем нужны все эти аутбоксы, и что это такое.

#оффтоп #манагерское

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

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

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

- Не нуачо? Раз народ сказал, надо идти делать
Так появился ArchWays. Потом решили объединиться с Аней, и он трансформировался в NextWay. Мораль я не придумал, но если вы узнали себя в это истории - спасибо за веру и чудесную возможность))

Пытаюсь понять, как у людей (команды) в рамках одной активности одновременно уживаются понятия «заказчик» и «продукт».

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