Forwarded from Грефневая Кафка (pro.kafka)
Кафка для детей от автора Mastering Kafka Streams and ksqlDB https://www.gentlydownthe.stream/
Здарова, котаны! Сорян, что долго без постов -- словил очередную итерацию депрессии, выгорания и отвращения к IT и уехал греть кости на море, но обязательно исправлюсь)) В ближайшее время ждите пару постов про мои любимые проявления культа карго и, наверное, про функциональщину.
Добра вам и морского хаскеля))
Добра вам и морского хаскеля))
#kafka
Посмотрел несколько шикарных докладов про освобождение Кафки от Зукипера
- Вот тут можно ознакомиться что вообще происходит и охренеть от количества проделанной работы
- Вот тут шикарный но хардкорный доклад про KRaft(кафковский кворумный протокол для метадаты)
- А вот это на закуску: история про приготовление кафки на мульти дц. Чет есть подозрение, что с учетом беззукиперности доклад придется переснять, но все равно рекомендую. Прям через экран сочится вся боль мультидц
Посмотрел несколько шикарных докладов про освобождение Кафки от Зукипера
- Вот тут можно ознакомиться что вообще происходит и охренеть от количества проделанной работы
- Вот тут шикарный но хардкорный доклад про KRaft(кафковский кворумный протокол для метадаты)
- А вот это на закуску: история про приготовление кафки на мульти дц. Чет есть подозрение, что с учетом беззукиперности доклад придется переснять, но все равно рекомендую. Прям через экран сочится вся боль мультидц
YouTube
Виктор Гамов — Разошлись как в море корабли: Кафка без Zookeeper
Подробнее о Java-конференциях:
— весной — JPoint: https://jrg.su/gTrwHx
— осенью — Joker: https://jrg.su/h7yvG4
— —
. . . Совсем скоро придет тот день, о котором грезили Kafka-опсы и Apache Kafka ® больше не будет нуждаться в ZooKeeper! С KIP-500 в Kafka…
— весной — JPoint: https://jrg.su/gTrwHx
— осенью — Joker: https://jrg.su/h7yvG4
— —
. . . Совсем скоро придет тот день, о котором грезили Kafka-опсы и Apache Kafka ® больше не будет нуждаться в ZooKeeper! С KIP-500 в Kafka…
#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 -- это эволюция принципа разделения команд и запросов(CQS) Бертрана Мейера, который был призван принести в мейнстримовые языки(в созданный им Eifell) лучшие практики, в частности, local reasoning из набирающих популярность функциональных языков. Основной смысл в том, что вы всегда можете глядя на сигнатуру функции однозначно понять что она делает без нежданчиков типа изменения значения параметров функции или глобального стейта. Таким образом кодец становится сильно проще читать и понимать, что уменьшает так же и порог входа для новых членов команды.
CQS для этого предлагает поделить все методы на запросы и команды, где запросы всегда только возвращают результат, ни коим образом не влияя на состояние каких-то объектов системы, а комманды как раз меняют стейт, но не возвращают ничего кроме ошибки.
CQRS же достаточно сильно развивает эту концепцию обильно сдабривая все это асинхронщиной и канкаренси, что впринципе не мудрено, с учетом того что Грег Янг изобрел ее для решения задач мастабируемости своих приложений. Смысл в том, что мы аккуратно переходим от синхронной архитектуры с логически разделенными частями на чтение и изменение к архитектуре основанной на обмене сообщениями. Основная идея в том, что мы выделяем 3 типа сообщенек: команды, ивенты и нотификации, где ивенты -- это сообщения которые рождаются при любом изменении стейта системы, команды -- это сообщения на которые система обязана отреагировать изменением стейта(и, как следствие, рассылкой ивентов), нотификации -- опциональная штука для уведомления системы о недоменных историях, например чисто техническая инфа или что-то для интеграции с остальным ландшафтом.
Отдельно надо сказать о кверях. Главное допущение всего этого великолепия заключается в многократном превышении нагрузки на чтение нагрузки на запись. Т.о. что бы иметь возможность скейлиться окололинейно до бесконечности нам надо научиться окололинейно и до бесконечности скейлить нагрузку на чтение. Для этого cqrs предлагает во-первых, выделить отдельную подсистему чтения (далее read part RP) от сложной и достаточно неторопливой подсистемы изменения (write part WP) со всеми описанными выше сообщеньками. Т.е. фактически мы сохраняем нашу концепцию cqs'ных кверей, максимально отделяя ее от WP, желательно в отдельный процесс.
Далее, нам надо научиться нашей нагрузкой на чтение не мешать нагрузке на запись. Ну тут все просто, давайте просто читать с реплики! Вот тут вот мы подходим к самому важному на сегодня: cqrs никогда из коробки не даст вам глобальных гарантий выше eventual consistency, которая является самой слабой гарантией консистентности и почти никогда бизнес не устраивает. На самом деле даже для того что бы построить casual consistency систему (что еще может как-то устроить бизнес) придется очень много плясать с бубном. Фактически же, надо очень четко понимать какой уровень консистентности устраивает бизнес и что вам придется навернуть из говна и палок что бы этого достичь. Ведь если у вас пуши на экране вывалятся не в том порядке, то вы, скорее всего этого даже не заметите, а вот если у вас списания и пополнения в бухгалтерской сводке перепутаются, то вам возможно придется придумывать что делать с полотенцем брошеным под ноги.
Wikipedia
Карго-культ
группа религиозных движений в Меланезии
I hate overtime
#cqrs Кажется уже как-то писал сюда, что самым грустным в нашей индустрии на сегодняшний день я считаю культ карго. Благодаря огромному количеству информационного шума разработка ПО из инженерии превращается в набор лучших практик, которые натягиваются на…
Это первая часть истории моих страданий с cqrs, обязательно рожу продолжение, а пока рекомендую сходить к Илье на митап послушать про сабж
Telegram
Kaznacheev Feed
А вот и анонсы: 25 сентября на 404fest в Самаре буду рассказывать все-все-все про CQRS, и как он рабочему человеку жить помогает.
Забегайте на огонек, мероприятие будет оффлайн.
Забегайте на огонек, мероприятие будет оффлайн.
I hate overtime
#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ами. Как бы нам еще подтюнить наш 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 при неправильном использовании примерно во столько же усложняет жизнь девелоперам, во сколько упрощает при правильном, но об этом как-нибудь в другой раз.
I hate overtime
#cqrs Всем привет, котаны, погнали дальше с нашими CQRSами. Как бы нам еще подтюнить наш RP? А что если вместо ванильной 3й нормальной формы, в которой лежат данные в нашем WP заиметь сразу хранилище с готовыми к выдаче на клиент данными? Такой себе локальный…
#cqrs
Итак, подытожим: за возможность практически линейно скейлиться до небывалых высот мы заплатим:
- консистентностью данных
- конским порогом входа (нам нужен чувак, как минимум, умеющий в EDA, CQRS и DDD)
- риском выплюнуть пользователю мусор вместо данных из нашего RP, если считаем аггрегаты
- скотски запутанной логикой на сагах и FSM
Выглядит не очень радужно, правда? На самом деле все не так плохо. Есть очень много областей, где можно уверенно тащить cqrs и не знать горя. Отличный пример -- уже упоминавшиеся выше нотификации. Новостные ленты, тоже отлично строятся на cqrs. Более того, я встречал достаточно много людей успешно выстраивающих приложения на cqrs и в e-commerce и даже в финансовой сфере. Помимо этого, есть еще набор фреймворков c Lagom во главе для облегчения жизни и уменьшения бойлерплейта. Главное, тащем-то как и всегда, сначала думать головой а не просто делать так же как сосед слева😉
Итак, подытожим: за возможность практически линейно скейлиться до небывалых высот мы заплатим:
- консистентностью данных
- конским порогом входа (нам нужен чувак, как минимум, умеющий в 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
Котаны, привет! Так уж получилось, что последнее время мне очень часто приходится считать сайзинг для всяких разных опенсурсных коробочек и, соответственно, всеми правдами и не правдами искать рекомендации от производителя по прожорливости их изобретений. И вот мне это надоело, так что решил тут сколлекционировать:
+ Apache Kafka
+ Dremio
+ Redis
+ Elasticsearch (здесь все сложно. По ссылке статья на хабре с кучей полезных ссылок на вебинары elastic'а с рекомендациями по расчетам)
+ MongoDb (тут видос. Извинити)
+ Postgres (пдфка про форк, но и к обычному постгресу подходит. Ну и отличный видос про настройку)
+ Kubernetes (раз и два)
+ etcd
+ minio
+ Prometheus память диски
Наверняка подъедет что-то еще, так что будут UPD
#postgres
Шикарнейший лонгрид про тюнинг постгреса от выбора железок и до всеми любимого postgresql.conf
Шикарнейший лонгрид про тюнинг постгреса от выбора железок и до всеми любимого postgresql.conf
EDB
PostgreSQL Performance Tuning: Optimize Your Database Server
Enhance your PostgreSQL database performance with EDB's expert tuning tips. Optimize queries, autovacuum, and more for a faster, more efficient database.
Forwarded from Bortlog
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.
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.
YouTube
How Slack Works
QCon San Francisco, the international software conference, returns November 17-21, 2025. Join senior software practitioners from early adopter companies as they share real-world insights and actionable advice to help you adopt the right technologies and practices.…
Forwarded from dd if=/dev/stuff of=/dev/tg
Я сдул пыль со своего блога, немного его причесал и выложил туда все публичные статьи, которые писал про функциональное программирование, в том числе переведенные на английский статьи из цикла «Введение в 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
В дальнейшем все материалы, которые я буду создавать, будут в первую очередь публиковаться именно в блоге.
Встречайте: 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
В дальнейшем все материалы, которые я буду создавать, будут в первую очередь публиковаться именно в блоге.
ybogomolov.me
Intro to fp-ts, part 1: Higher-Kinded Types
Forwarded from ДевОпс Інженер 🇺🇦 (Oleg Mykolaichenko)
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, но уже отчетливо видно, где следующая итерация. 😅
Весной я упоминал спеку 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, но уже отчетливо видно, где следующая итерация. 😅
GitHub
GitHub - slok/sloth: 🦥 Easy and simple Prometheus SLO (service level objectives) generator
🦥 Easy and simple Prometheus SLO (service level objectives) generator - slok/sloth
ДевОпс Інженер 🇺🇦
Sloth, Pyrra Весной я упоминал спеку OpenSLO и вероятность реализации оператора, или контроллера по этой спецификации для создания дашбордов или алертов. Эта поделка была удачно забыта, но вчера в соседнем чатике нахожу тулу: ✅ https://github.com/slok/sloth…
вот люблю красивые решения для мониторинговых дашбордов с зонтиками, бантиками и интуитивным дрилл-дауном. Но тут нашел просто идеал дашборда.
Даже если выкинуть весь хайповый мусор типа AI и NLP, то оно красивое, удобное и полезное.
Самое интересное, что видосу уже 5 лет)
Даже если выкинуть весь хайповый мусор типа AI и NLP, то оно красивое, удобное и полезное.
Самое интересное, что видосу уже 5 лет)
YouTube
Intelligent Dashboard to help total factory optimization
Fujitsu Forum 2016: https://journal.jp.fujitsu.com/en/ff2016/
#postgres #db
Очень полезная статья про тюнинг чекпоинтов в постгресе + бонусом инструкция как рассчитывать размер WAL
Очень полезная статья про тюнинг чекпоинтов в постгресе + бонусом инструкция как рассчитывать размер WAL
2ndQuadrant | PostgreSQL
Basics of Tuning Checkpoints - 2ndQuadrant | PostgreSQL
Let me walk you through the basics of tuning checkpoints in PostgreSQL, which may significantly affect performance in write-intensive workloads.
#arch
Так уж получается, что последнее время на работе чаще рисую картинки в draw.io чем кодец в ide. И проблема обычно в том, как при разрастании картинки, не превратить ее в паутину из стрелочек. Недавно открыл для себя вот такое: https://blogs.mulesoft.com/api-integration/strategy/a-visual-language-for-digital-integration/ и пока что доволен как черт! Тем кто часто рисует data-flow диаграммы и страдает -- очень рекомендую!
Кстати, в блогпосте есть несколько ссылок на крутейшие книги по системной архитектуре. Подарочек тем, кому нечего читать;)
Так уж получается, что последнее время на работе чаще рисую картинки в draw.io чем кодец в ide. И проблема обычно в том, как при разрастании картинки, не превратить ее в паутину из стрелочек. Недавно открыл для себя вот такое: https://blogs.mulesoft.com/api-integration/strategy/a-visual-language-for-digital-integration/ и пока что доволен как черт! Тем кто часто рисует data-flow диаграммы и страдает -- очень рекомендую!
Кстати, в блогпосте есть несколько ссылок на крутейшие книги по системной архитектуре. Подарочек тем, кому нечего читать;)
MuleSoft Blog
A visual language for digital integration
In my last blog, I introduced terminology that can be used to label common concepts and patterns in the realm…
Пожалуй прикопаю тут отличное объяснение на пальцах BGP anycast'а. Вдруг кому-то тоже пригодится сшивать датацентры и строить метеоритоустойчивость из палок и шишек
here blog
Об Anycast
Как сделать так, чтобы ваш сервис был всегда доступен? Дублировать, запускать несколько экземпляров. Собственно, та самая балансировка нагрузки. Когда за одним балансировщиком стоит несколько серверов, и запросы распределяются между ними. Но сам балансировщик…
Дорогие подписчики, всегда старался держать канал в стороне от политики, но то что сейчас происходит -- это полный п$здец. Украинцы, держитесь! Сил вам и здоровья! #нет_войне
#network #proxy
В очередной раз объясняя коллеге как клиенты работают с HTTP-прокси(нет, не просто меняем урл на урл прокси-сервера) понял, что надо найти хорошую статью. Внезапно нашлось с трудом, так что решил поделиться
В очередной раз объясняя коллеге как клиенты работают с HTTP-прокси(нет, не просто меняем урл на урл прокси-сервера) понял, что надо найти хорошую статью. Внезапно нашлось с трудом, так что решил поделиться
Ibm
Advanced HTTP and TCP proxy configuration
The HTTP protocol runs on top of the TCP protocol, but provides extra information about the message destination. For that reason, the two proxies are configured differently.