#arch
Про арх. надзор
Одной из основных моих обязанностей в бытность сис. архом было осуществление арх. надзора. Это означает то, что помимо проработки решения и реализации PoC надо было еще и, каким-то образом, гарантировать, что реализация концептуально не отличается от задумки.
Проблема в том, что "вас много а я одна". Читать внимательно весь код времени нет, свои задачи ждать не будут, да и глаз со временем замыливается, а джуны тем временем не дремлют и в результате все эти ваши воздушные замки на бумажке начинают очень слабо походить на то, что попадает на продуктив.
Серебряной пули тут, к большому сожалению, нет. Но есть несколько способов все-таки снизить вероятность деградации наших любимых НФТ из-за шаловливых ручек.
Первый из них это уже упомянутые фитнесс функции. В результате достаточно плотного покрытия ими, можно получить достаточно неплохую "приемку". К сожалению, не все НФТ можно дешево "зафитить"(как насчет расширяемости и maintainability, например). Тут в дело врываются гексагональная(ну или чистая) архитектура и DDD. При правильной мотивации и сноровке эти 2 инструмента дадут не только достаточно аккуратный код, но и даже уменьшат time to market. Но тут на первый план выходит вопрос мотивации. DDD и clean architecture очень хрупкие и сильно подвержены закону разбитых окон, поэтому вся тима без исключения должна быть единодушна в их использовании. Ведь стоит кому-то одному по незнанию или из-за давящих сроков "наговнякать" и скоро все ваши усилия и человекочасы потраченные на ивент сторминги и проработку модели пойдут прахом. На C# и Go мне удавалось более-менее успешно бороться с этим используя линтеры и статический анализ, но, тем не менее, ревью по прежнему жрало конскую долю моего рабочего времени.
Если вам повезло и у вас есть сильная система типов и HKT(и, конечно же, команда готова к такому повороту событий), то можно попробовать еще сильнее закрутить гайки и зафорсить архитектурный стиль через интерпритаторы. Тут мне, к сожалению, ничего не понятно, но очень интересно, так что сильно рекомендую послушать замечательный выпуск scalalaz'а про TF и джун-пруф девелопмент. Там гуру классно рассказывают, что это и как с этим жить.
В заключение скажу, что как не крути, но код читать придется. Причем много. И, скорее всего, плохого. И свои тикета из-за этого закрывать по ночам тоже придется(в лес не убегут, да). Но в результате, когда общий уровень команды поднимется, процессы устаканятся, вы незаметно перестанете просыпаться от pagerDuty по ночам. А это, как не крути, приятно)))

#arch
Про проектирование "на берегу"
Как-то я уже писал пост про эмержентную архитектуру. Это такая штука, которая позволяет вашей системе легко адаптироваться к новым требованиям(привет аджайл), но при этом не скатываться в большой комок известной субстанции. Так вот, не смотря на все модные аджайлы и лин-стартапы фаза проектирования никуда не девается. Просто она становится более верхнеуровневой и концептуальной.
Расскажу байку: в бытность моей гребли на галере у нас был очень крупный заказчик, которому мы делали и внедряли хранилище данных. Досталось мне это поделие уже на изрядной степени готовности и ребята там решили для витрины заиспользовать одну известную отечественную колоночную СУБД. Все бы хорошо, но вот только в документации к этой СУБД было черным по белому написано, что деньги в нее класть не стоит, т.к. при определенных положениях лун юпитера возможны частичные потери данных. Угадайте что лежало в хранилище? Проблема обострялась тем, что сайзинг уже был рассчитан и тачки закуплены, а значит признание и устранение этой ошибки нам влетало в штрафы примерно равные бюджетам проекта.
История кончилась хорошо, проблему вовремя эскалировали и все решилось без особых денежных и репутационных потерь, но с тех пор я и сам стараюсь и всех призываю первым делом понимать что является реально "архитектурными" решениями. Под архитектурными я понимаю то, что потом будет очень сложно или даже невозможно(как в истории выше) поменять. Такие вещи надо обсуждать на берегу, аккуратно принимать решение и не менее аккуратно документировать вместе с контекстом, альтернативами и участвовашими в принятии решения стейкхолдерами. Я пользуюсь замечательным шаблоном от Майка Нейгарда, но вот тут кажется уже собрали пару-тройку неплохих альтернатив.
Смысл в том, что ваши потомки, а может даже и вы сами через какое-то время точно забудете нюансы под давлением которых было принято решение, а тут получается нужно только смахнуть пыль с пары десятков(у меня пара десятков скапливается за несколько лет) вики-статей и вуаля, вы снова полностью в контексте и нет желания орать на весь опенспейс "ну и какого оно вот ТАК!"

#concurrency
Очень хорошая статья из серии "да кто такие эти ваши фиберы/ко(го)рутины ...". В частности объясняют какую проблему они решают и почему так не получится сделать на обычных ОС тредах. Рекомендую!
З.Ы. не смотря на то, что блог java'овый про java в статье только пара упоминаний proj loom

​​Кафка для детей от автора Mastering Kafka Streams and ksqlDB https://www.gentlydownthe.stream/

Найди свой стек на картинке))
Кстати, картинка абсолютно реальная. Сфотано в Индийской провинции

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

#kafka
Посмотрел несколько шикарных докладов про освобождение Кафки от Зукипера
- Вот тут можно ознакомиться что вообще происходит и охренеть от количества проделанной работы
- Вот тут шикарный но хардкорный доклад про KRaft(кафковский кворумный протокол для метадаты)
- А вот это на закуску: история про приготовление кафки на мульти дц. Чет есть подозрение, что с учетом беззукиперности доклад придется переснять, но все равно рекомендую. Прям через экран сочится вся боль мультидц

#cqrs
Кажется уже как-то писал сюда, что самым грустным в нашей индустрии на сегодняшний день я считаю культ карго. Благодаря огромному количеству информационного шума разработка ПО из инженерии превращается в набор лучших практик, которые натягиваются на абсолютно любой кейс. Удивительно то, что забивать гвозди исхитряются всем чем угодно: архитектурными стилями, технологиями и даже процессами. В этом тредике расскажу про проявления этой болячки от которых у меня больше всего бомбит.
Начнем пожалуй с одной из последних таких серебряных пуль. Прошу любить и жаловать CQRS
CQRS -- это эволюция принципа разделения команд и запросов(CQS) Бертрана Мейера, который был призван принести в мейнстримовые языки(в созданный им Eifell) лучшие практики, в частности, local reasoning из набирающих популярность функциональных языков. Основной смысл в том, что вы всегда можете глядя на сигнатуру функции однозначно понять что она делает без нежданчиков типа изменения значения параметров функции или глобального стейта. Таким образом кодец становится сильно проще читать и понимать, что уменьшает так же и порог входа для новых членов команды.
CQS для этого предлагает поделить все методы на запросы и команды, где запросы всегда только возвращают результат, ни коим образом не влияя на состояние каких-то объектов системы, а комманды как раз меняют стейт, но не возвращают ничего кроме ошибки.
CQRS же достаточно сильно развивает эту концепцию обильно сдабривая все это асинхронщиной и канкаренси, что впринципе не мудрено, с учетом того что Грег Янг изобрел ее для решения задач мастабируемости своих приложений. Смысл в том, что мы аккуратно переходим от синхронной архитектуры с логически разделенными частями на чтение и изменение к архитектуре основанной на обмене сообщениями. Основная идея в том, что мы выделяем 3 типа сообщенек: команды, ивенты и нотификации, где ивенты -- это сообщения которые рождаются при любом изменении стейта системы, команды -- это сообщения на которые система обязана отреагировать изменением стейта(и, как следствие, рассылкой ивентов), нотификации -- опциональная штука для уведомления системы о недоменных историях, например чисто техническая инфа или что-то для интеграции с остальным ландшафтом.
Отдельно надо сказать о кверях. Главное допущение всего этого великолепия заключается в многократном превышении нагрузки на чтение нагрузки на запись. Т.о. что бы иметь возможность скейлиться окололинейно до бесконечности нам надо научиться окололинейно и до бесконечности скейлить нагрузку на чтение. Для этого cqrs предлагает во-первых, выделить отдельную подсистему чтения (далее read part RP) от сложной и достаточно неторопливой подсистемы изменения (write part WP) со всеми описанными выше сообщеньками. Т.е. фактически мы сохраняем нашу концепцию cqs'ных кверей, максимально отделяя ее от WP, желательно в отдельный процесс.
Далее, нам надо научиться нашей нагрузкой на чтение не мешать нагрузке на запись. Ну тут все просто, давайте просто читать с реплики! Вот тут вот мы подходим к самому важному на сегодня: cqrs никогда из коробки не даст вам глобальных гарантий выше eventual consistency, которая является самой слабой гарантией консистентности и почти никогда бизнес не устраивает. На самом деле даже для того что бы построить casual consistency систему (что еще может как-то устроить бизнес) придется очень много плясать с бубном. Фактически же, надо очень четко понимать какой уровень консистентности устраивает бизнес и что вам придется навернуть из говна и палок что бы этого достичь. Ведь если у вас пуши на экране вывалятся не в том порядке, то вы, скорее всего этого даже не заметите, а вот если у вас списания и пополнения в бухгалтерской сводке перепутаются, то вам возможно придется придумывать что делать с полотенцем брошеным под ноги.

Это первая часть истории моих страданий с cqrs, обязательно рожу продолжение, а пока рекомендую сходить к Илье на митап послушать про сабж

#cqrs
Всем привет, котаны, погнали дальше с нашими CQRSами. Как бы нам еще подтюнить наш RP? А что если вместо ванильной 3й нормальной формы, в которой лежат данные в нашем WP заиметь сразу хранилище с готовыми к выдаче на клиент данными? Такой себе локальный DWH внутри. Ну давайте попробуем изобрести GoldenGate на коленке.
Во-первых, у нас есть event'ы, которые содержат всю инфу о происходящем с нашей системой и на которые мы можем подписаться в любой момент. Теоретически мы могли бы сделать event handler'а для ивентов системы и последовательно применять их к нашей "реплике", что бы получить данные в совершенно произвольной удобной нам форме. Практически тут 2 проблемы: во-первых, информация в ивентах, как правило, отражает только то, что изменилось в системе, а в нашей реплике может лежать сложный аггрегат, для построения которого нужно будет откуда-то получить инфу, которой в ивентах нет. Например, нам надо показать среднюю температуру по больнице, но мы получаем ивент, что температура одного пациента изменилась с 39 на 36.6. Придется откуда-то взять кол-во пациентов, их температуры и перерасчитать наше среднее. Универсально тут порешать не получится, каждый изголяется как хочет. Кто-то кладет больше инфы в ивенты, в итоге ивенты распухают и вот у вас уже сообщенька на 100500 полей в которых черт ногу сломит. Кто-то строит "дубль" данных WP в нашей любимой 3й нормальной, из которой можно забрать все нужные данные для обновления нашего аггрегата. Кто-то лезет за данными в WP впринципе нивилируя тем самым все плюшки CQRS. Кароч крассивого решения я не видел, если кто умеет решать такое не костылем, прошу в комменты.
Во-вторых, все сообщеньки, как правило, идут по какому-то транспорту, что опять же привносит в наш идеальный мир щепотку геморроя с гарантиями(знаете это непередаваемое ощущение когда понимаешь, что ивенты приходят не в правильном порядке и у тебя в RP уже пол-года лежит мусор). И это хорошо, если транспорт хотя бы персистентый, а если ивенты еще и теряются по дороге, то тут вообще шляпа.
Но перейдем к самому интересному, к WP. Тут все еще веслелее: как правило WP в CQRS строится с использованием замечательных практик DDD. В частности у нас есть корень аггрегата, который принимает команды, что-то у себя внутри транзакционно делает и выплевывает ивент. Звучит вроде просто, но и тут у нас интересное.
Для начала, надо понимать, что при таком подходе граница транзакции у нас совпадает с границами DDDшного аггрегата. Впринципе, если верить светилам DDD, то этого достаточно, но вот как показывает моя практика, очень часто бизнес хочет транзакционность внутри всего bounded context, а не внутри отдельных аггрегатов и тут мы плавно въезжаем в удивительный мир распределенных транзакций, саг и координаторов. Программировать конечные автоматы с 3хфазными коммитами, компенсаторами и прочей мишурой конечно увлекательно, но только первые 5 раз. А дальше начинается наши любимые отрицание, гнев, торг и т.п.
Во вторых, надо сказать, что DDD это очень круто, но очень сложно. Если вы не умеете вот в эти event stroming'и, bounded context'ы и context map'ы, то учиться придется. Но самое "приятное" тут то, что DDD очень хрупкое и очень чутко реагирует на косяки разработчиков в доменной модели. Есть у меня такое ощущение, что DDD при неправильном использовании примерно во столько же усложняет жизнь девелоперам, во сколько упрощает при правильном, но об этом как-нибудь в другой раз.

#cqrs
Итак, подытожим: за возможность практически линейно скейлиться до небывалых высот мы заплатим:
- консистентностью данных
- конским порогом входа (нам нужен чувак, как минимум, умеющий в EDA, CQRS и DDD)
- риском выплюнуть пользователю мусор вместо данных из нашего RP, если считаем аггрегаты
- скотски запутанной логикой на сагах и FSM

Выглядит не очень радужно, правда? На самом деле все не так плохо. Есть очень много областей, где можно уверенно тащить cqrs и не знать горя. Отличный пример -- уже упоминавшиеся выше нотификации. Новостные ленты, тоже отлично строятся на cqrs. Более того, я встречал достаточно много людей успешно выстраивающих приложения на cqrs и в e-commerce и даже в финансовой сфере. Помимо этого, есть еще набор фреймворков c Lagom во главе для облегчения жизни и уменьшения бойлерплейта. Главное, тащем-то как и всегда, сначала думать головой а не просто делать так же как сосед слева😉

#sizing
Котаны, привет! Так уж получилось, что последнее время мне очень часто приходится считать сайзинг для всяких разных опенсурсных коробочек и, соответственно, всеми правдами и не правдами искать рекомендации от производителя по прожорливости их изобретений. И вот мне это надоело, так что решил тут сколлекционировать:
+ Apache Kafka
+ Dremio
+ Redis
+ Elasticsearch (здесь все сложно. По ссылке статья на хабре с кучей полезных ссылок на вебинары elastic'а с рекомендациями по расчетам)
+ MongoDb (тут видос. Извинити)
+ Postgres (пдфка про форк, но и к обычному постгресу подходит. Ну и отличный видос про настройку)
+ Kubernetes (раз и два)
+ etcd
+ minio
+ Prometheus память диски

Наверняка подъедет что-то еще, так что будут UPD

#postgres
Шикарнейший лонгрид про тюнинг постгреса от выбора железок и до всеми любимого postgresql.conf

Recently I've got a few interns to look after and mentor, so one of them asked for some advice on improving their system design skills.
So I gave a long monolog on digging through the layers of abstractions and being curious and genuinely understanding how things work. After it, I suggested them to read a "Designing Data-Intensive Applications" book and also prepared a shortlist of talks that can work as conversation starter or places from where you can start digging deeper.
Here is the list:

https://youtu.be/WE9c9AZe-DY
https://youtu.be/j6ow-UemzBc
https://youtu.be/1TIzPL4878Q
https://youtu.be/CZ3wIuvmHeM
https://youtu.be/I32hmY4diFY
https://youtu.be/hnpzNAPiC0E
https://youtu.be/y2j_TB3NsRc
https://youtu.be/t7iVCIYQbgk
https://youtu.be/IO4teCbHvZw
https://youtu.be/6w6E_B55p0E
https://youtu.be/B5NULPSiOGw
https://youtu.be/_M-oHxknfnI
https://youtu.be/lKXe3HUG2l4
https://youtu.be/r-TLSBdHe1A
https://youtu.be/fU9hR3kiOK0
https://youtu.be/lJ8ydIuPFeU
https://youtu.be/5ZjhNTM8XU8
https://youtu.be/9RMOc0SwRro
https://youtu.be/tM4YskS94b0
https://youtu.be/H0i_bXKwujQ
https://youtu.be/m64SWl9bfvk
https://youtu.be/cNICGEwmXLU
https://youtu.be/em9zLzM8O7c
https://youtu.be/ohvPnJYUW1E
https://youtu.be/HJIjTTHWYnE

Write in the comments: what else would you recommend or what talk you'd add to the list.

Я сдул пыль со своего блога, немного его причесал и выложил туда все публичные статьи, которые писал про функциональное программирование, в том числе переведенные на английский статьи из цикла «Введение в fp-ts» с Хабра.
Встречайте: https://ybogomolov.me 🤘🏻

Серия "Intro to fp-ts":
https://ybogomolov.me/01-higher-kinded-types
https://ybogomolov.me/02-type-classes
https://ybogomolov.me/03-nullables-exceptions
https://ybogomolov.me/04-tasks

Серия #MonadicMondays:
https://ybogomolov.me/monadic-monday-compilation-april
https://ybogomolov.me/monadic-monday-compilation-may
https://ybogomolov.me/monadic-monday-compilation-june
https://ybogomolov.me/monadic-monday-compilation-july

Прочее:
Статья про типобезопасный фронт: https://ybogomolov.me/typesafe-typescript
Статья про пакет circuit-breaker-monad: https://ybogomolov.me/circuit-breaker-in-functional-world
Недавняя заметка про комментарии к функциям как образовательный ресурс: https://ybogomolov.me/comments-as-education

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

Sloth, Pyrra

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

✅ https://github.com/slok/sloth

Суть Sloth - описать SLO, дашборду и алерт как манифест в YAML, в OpenSLO формате. Прикол!

В README по ссылке есть пример, а в репозитории - helm чарт.

Дальше, в комментариях вижу:
✅ https://github.com/pyrra-dev/pyrra

Pyrra - status page на анаболических стероидах и тестостероновых бустерах. Выглядит космически - собираем все сервисы платформы, и генерим одну UI для SLO. Бомба.

В issues спрашивают, будет ли поддержка описания в OpenSLO, ответ - ‘yes, for sure’.

Спонсор поста - @oleg_log, подсмотрел там эти решения.

Наша реализация с grafana-operator и GrafanaDashboard CRD внезапно стала выглядеть как Monitoring Platform 101, но уже отчетливо видно, где следующая итерация. 😅

вот люблю красивые решения для мониторинговых дашбордов с зонтиками, бантиками и интуитивным дрилл-дауном. Но тут нашел просто идеал дашборда.
Даже если выкинуть весь хайповый мусор типа AI и NLP, то оно красивое, удобное и полезное.
Самое интересное, что видосу уже 5 лет)

#postgres #db
Очень полезная статья про тюнинг чекпоинтов в постгресе + бонусом инструкция как рассчитывать размер WAL

#arch
Так уж получается, что последнее время на работе чаще рисую картинки в draw.io чем кодец в ide. И проблема обычно в том, как при разрастании картинки, не превратить ее в паутину из стрелочек. Недавно открыл для себя вот такое: https://blogs.mulesoft.com/api-integration/strategy/a-visual-language-for-digital-integration/ и пока что доволен как черт! Тем кто часто рисует data-flow диаграммы и страдает -- очень рекомендую!
Кстати, в блогпосте есть несколько ссылок на крутейшие книги по системной архитектуре. Подарочек тем, кому нечего читать;)

Всем привет! Котаны, а тут вышли видосы с последней Гидры.
Конфа вышла -- огонь! Бесспорным лидером по количеству докладов стал TLA+, но лично я дико кайфовал с доклада Naama Ben-David. Прям вся боль катастрофоустойчивости за полтора часа. Крайне рекомендую!

Пожалуй прикопаю тут отличное объяснение на пальцах BGP anycast'а. Вдруг кому-то тоже пригодится сшивать датацентры и строить метеоритоустойчивость из палок и шишек