#devops #kafka
Очень ценная брошура с советами по оптимизации Кафки. Есть гайды как заоптимизироваться по латенси, throughput, durability и availability.

Статья о функциональной архитектуре от Скотта Влашина:
https://increment.com/software-architecture/primer-on-functional-architecture

TL;DR: принципы функционального программирования — использование функций как основных строительных блоков, композиция, чистота — могут быть применены не только для решения тактических задач в прикладном коде, но и для построения более общей, стратегической картины решения целиком. Скотт Влашин в деталях описывает свой подход — построение крупномасштабных «функций»-воркфлоу, применение слоистой архитектуры (onion architecture), определение ограничений (boundaries) и использование событий как входных и выходных точек решения. В конце затрагивается тема функционального фронтэнда на примере Elm и рекламируется книга автора «Domain Modeling Made Functional».

В продолжение кину еще бородатую статью про функциональную архитектуру на Free-контейнерах и ее продолжение.
Очень красиво строятся NLayer архитектуры и подмешиваются сторонние эффекты(типа логирования), которые в ООП пришлось бы делать АОПом или еще что-то придумывать. Кароч рекомендую

Очередной туториал от Фланта. На этот раз про Эластик

Разбиение монолита на части

При разделение монолита на части возникает проблема, что транзакции уровня базы данных становятся невозможны. Решение — распределенные транзакции. Этот механизм позволяет получить достаточно надежные транзакции для разделённых сервисов. А во многих случаях, стоит вовсе отказаться от транзакций и разработать самовостанавливающуюся систему (например, попытки записи могут повторяться несколько раз, пока не получится).

В микросервисной архитектуре не так просто реализовать отчеты. Мы не можем просто сделать большой запрос к единой базе данных и получить результат. Есть четыре варианта:
+ каждый сервис может слать свои данные для отчетов в сервис отчетов;
+ сервис отчетов может ходить к остальным сервисам за данными;
+ если сервисы общаются через события, то сервис отчетов может просто подписаться на эти события;
+ сервис отчетов может брать бекапы разных сервисов и генерировать отчеты на основе этих данных (так делает Netflix).

#микросервисы

Уже очень давно люблю просить кандидатов на собесе сравнить ленивую и энергичную модель вычислений(у нас используются обе). И, если с энергичной-то все ясно, то с ленивой не все так очевидно. Вот тут вот, наверно, одна из лучших статей на эту тему: https://apfelmus.nfshost.com/articles/lazy-eval-modular-code.html

Когда тебя чуть-чуть бесят коллеги и надо как-то назвать пейпер

Если вы работаете с Big Data, то вы часто работаете с продуктами Apache (Hadoop, Hive, Kafka). Так же вы слышали про Data Lake, особенно в контексте облака, где много инструментов, чтобы быстро его создать. Когда мы храним данные в озере данных, или вообще работает с большими данными, важно использовать правильный формат данных. Вот хорошая статья про Apache Parquet. Отличная компрессия (10x) и возможность партиционирования, сделала это формат лидером.

Оказывается у Confluent есть подкаст про Кафку. Причем, достаточно старый. Если кто катает до галеры по часу, то зацените))

#dotnet #async
Очень классный гайд по дотнетовым таскам(а-ля джавовые/скаловые future).
Тут и немного истории и мат.часть и подводные камни.
Я бы еще добавил сюда FRP для полноты картины(вот, например, годное интро), но даже без этого всем дотнетчикам и сочувствующим must read

P.S. упоминаемый там "документ"

Наверняка многих из-за короновируса перевели на удаленку. В связи с этим, ловите несколько советов от трелло как правильно комуницировать онлайн.

З.ы. обычно я пролистываю такой контент неглядя, но тут получилось интересно: я вот всегда к удаленке относился скорее негативно, но и ЧСХ мнение по поводу коммуникаций у меня всегда было полностью полярным(никогда не приветствовал болтовню на митах и всегда был за максимально лаконичные диалоги). Т.о., артикл заставил меня задуматься, что возможно я просто душный)) Поэтому я и решил поделиться: может и вас это заставит что-то переосмыслить)))

#sre
Лазил тут по интернетам в поисках ответа на вопрос "как правильно дизайнить приложение с метриками" и наткнулся на бомбическую статью по Metrics Driven Development.
Тут и практики и примеры и крутые ссылки, кароч очень рекомендую!
З.Ы. собственно сам вопрос: есть 2 стула, на одном injection точеного metricsExposer'а во все места где что-то нужно заэкспоузить, на другом — прикрутить какое-то апи к модулям, которые должны торчать метриками и собирать через это апи значения метрик в каком-то специальном инфраструктурном слое...запилю-ка опрос

#devops #docker

Хорошая статья про обмен знаниями https://habr.com/ru/company/oleg-bunin/blog/492478/

#sre #observability
Спасибо огромное, котаны, за ваше участие! Ваше мнение очень важно и интересно, но я все-таки присоединюсь к меньшинству.
Поясню свою позицию: допустим мы не инжектим условный Coda Hale Metrics в наш условный ApiClient и хотим собирать метрики по уходящим через этот клиент запросам. Скорее всего метрика будет не одна, а несколько. Возможно среди них будет гистограмма(т.е вот где-то тут уже придется навернуть все эти скользящие окна и т.д.). Потом мы все это добро прячем под отдельный интерфейс и получаем...тот же самый Coda Hale Metrics, только изобретенный заново.
Если я что-то не понимаю, то го в комменты.
З.Ы. вот вам шикарнейший гайд по обзервабилити от Digital Ocean

Для тех кто из-за карантина уже научил кота плясать, построил 3хэтажный карточный домик с террасой и сделал всякие другие нужные и полезные вещи вот тут вот в открытом доступе лежит книга type driven development with Idris.
Почему стоит почитать:
1. Это, наверное, первый "мейнстримовый"(неакадимический) язык с зависимыми типами
2. Idris -- реально странный! Там типы как first class citizen(можно передавать в функцию, возвращать и т.д.). Все функции тотальные и нет исключений.
3. А еще(имхо, самое важное) автор уверяет, что книжка-то не про идрис, а про программирование через типы. Т.е. про то как подружиться с компилятором на столько, что бы он помогал писать код, а не просто орал в конце "rejected!!1". Собственно ради этого люди и идут в функциональщину