не используем, но вот - https://dzone.com/articles/problem-with-kafka-streams-1

Ввиду того, что ваш покорный слуга живет и работает в Штатах, последние несколько дней прибываю в Рождественских каникулах.
Поэтому было затишье в этом канале.
LinkedIn в твиторе для инженеров https://twitter.Com/LinkedInEng в выложил несколько интересных видосов

-история развития stream processing framework Apache Samsa
- все что вы хотели знать про Consumer Groups
- подробно о том, как работает Controller в Kafka кластере
- много мякотки на тему дисковой подсистемы - JBOD и Kafka

Напоминаю, что у нас появился чат https://xn--r1a.website/proKafka

А вот тут Кафка в картинках для самых маленьких (I kid you not)!
Местами присутствуют косяки небольшие (типа offsets уже не хранятся в zookeeper), но выглядит достаточно интересно и весело


https://medium.com/learning-with-diagrams/learning-w-diagrams-intro-to-kafka-510c8f4d7030

На сайте конференции Jax DevOps появился рейтинг "влиятельных твиттер-блоггеров" из мира DevOps.

Рейтинг на самом деле несного странный: во первых, методология оставляет впечатление того, что оценка была чисто формальной: кто больше натвиттил -- тот и главный. Во-вторых, не ясно, как считать "influence", ну я к тому, что понятно: колличество Твиттов даже по делу != influence

Однако, интересные личности в данном списке, конечно же, присутствуют. Я вот тоже решил поделиться некторыми своими подписками с кратким описанием, почему стоит подписаться

- Adrian Cockcroft -- человек с огромным опытом в cloud computing. Сейчас, вроде, работает в AWS
- Jeff Barr -- евангелист в AWS. Его именем подписано огромное колличество статей в AWS блоге
- Fatih Arslan -- создатель Vim-go, работает в Digital Ocean
- Ian Lewis -- инженер из GCP. Иногда, правда, твиттит на японском
- Jason Fried -- CEO Basecump. Не техническоий товарищ, но кидает интересные штуки по бизнесу
- Julia Grace -- начальница инфарструктурной команды в Slack. Рассказывает много интересного о культуре
- Yevgeniy Brikman -- автор "Terraform Up and Running" и вообще достаточно интересный дядька. Кстати, при первом знакомстве с Terraform, рекомендую к его заметкам обращаться
- Carlos Sanchez -- представитель Apache Foundation. Пишет про CI/CD, Docker, автоматизацию и другие интересные вещи
- Brendan Gregg -- nuff said. Лучшие статьи по анализу производительности систем
- Cindy Sridharan -- авторка той самой статьи о тестировании микросервисов
- Mitchell Hashimoto -- основатель Hashicorp
- Kelsey Hightower -- nuff said. Евангелист Kubernetes
- Julia Evans -- zine wizard. Авторка знаменитых комиксов о технологиях

P.S.: в списке присутствуют только люди. Аккаунты компаний, shared аккаунты я во внимание не брал
P.P.S.: буду рад, если вы поделитесь своими интересными подписками(на @grem1in). В конце концов, больше источников -- больше материалов здесь 🙂

Container Structure Tests — тестовый фреймворк для Docker образов от Google.

Анонс: https://goo.gl/NgrJwb

GitHub: https://goo.gl/wFAoX9

И снова Google. Вчера они анонсировали open source библиотеку для реализации сбора метрик и трейсинга в приложениях.
Поддерживается отправка данных в Prometheus, SignalFX, Stackdriver и Zipkin.
Сама библиотека реализована для всех популярных языков и даже PHP))

Анонс: https://goo.gl/CrjCUn
Сам проект: https://goo.gl/wjJueX
GitHub: https://goo.gl/Zzwqwj

Cindy Sridharan на этой неделе опубликовала свою выборку лучших докладов в 2017 году.
В списке 19 отличных докладов на темы Monitoring, Observability, Go, Python.

https://goo.gl/jMquik

Обновился гайд по использованию Windows контейнеров в Kubernetes до актуальной версии 1.9.

https://goo.gl/9Q6hNv

Sonobuoy — диагностическая утилита от Heptio для проверки состояния Kubernetes кластера.

https://goo.gl/eNr8Rn

Why my Java application is OOMKilled · Banzai Cloud
https://banzaicloud.com/blog/java-resource-limits/

Reusable CloudFront configuration with Terraform – buildo blog
https://blog.buildo.io/reusable-cloudfront-configuration-with-terraform-4c1de144c735

Data Science in Production: Packaging, Versioning and Continuous Integration - Florian Wilhelm
http://www.florianwilhelm.info/2018/01/ds_in_prod_packaging_ci/

My Notes about a Production-grade Ruby on Rails Deployment on Google Cloud Kubernetes Engine | AkitaOnRails.com
http://www.akitaonrails.com/2018/01/09/my-notes-about-a-production-grade-ruby-on-rails-deployment-on-google-cloud-kubernetes-engine

Supercronic — cron от Aptible, предназначенный для использования в контейнерах

https://goo.gl/ZkV6qi

GitHub: https://goo.gl/ANN1ta

Реализация канбан доски на баше для работы в терминале))

https://goo.gl/RVRmbL

kubeval — удобная утилита для верификации Kubernetes YAML или JSON конфигурационных файлов.
Может встраиваться как библиотека в другие программы.

https://goo.gl/mPjmjL

Нашел в сети шедевральный awesome-список — awesome-scalability. Кладезь для тех, кто хочет погрузиться в тему масштабирования приложений и data engineering. Советую добавить к себе в watch-лист на гитхабе и поставить звезду, чтобы следить за обновлениями.

А ещё, Brandon Rhodes у себя в твиттере объявил о том, что каждую неделю он будет писать на сайте http://python-patterns.guide/ про новый дизайн-паттерн на Python. Уже есть 1 пост про Decorator Pattern.

Также в сети стали доступны доклады с прошедшего митапа San Francisco Python. Из всех стоит отметить основательную презентацию новой фичи в предстоящем релизе Python 3.7 — Data Classes от Raymond Hettinger. Смотрим.

Идея! Давайте тегировать error rate еще и build number'ом

Всем привет.
Рубрика «По Вашим письмам»

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

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

или такое

«А какие есть best practices на тему хранения сообщений разного типа в одном Kafka топике?
Например, чтобы все сообщения класть в одно место, а уже Consumer сам разберется.
Или наоборот, деть fine-grained топики - под определенный тип сообщения.

И как вы понимаете, ответ на этот вопрос - it depends (duh).
Давайте подумаем, от чего это может depends:

- Если порядок сообщений важен, сообщения должный попадать в один топик.
Важно помнить - Kafka гарантирует порядок только на уровне partition.
Для этого необходимо указывать правильный ключ (например, если важен порядок банковских транзакций ID аккаунта может использоваться в качестве ключа). Или иметь топик с 1 partition.
- Сообщения разного типа, но связанные бизнес-логикой (как в предыдущем примере, сообщения могут быть разного типа - CreditEvent, DebitEvent, etc)
- Еще такой момент - не надо бояться использовать Kafka для хранения RAW сообщений - порезать, отфильтровать и разделить их можно всегда, а объединять может оказаться не всегда просто / нужно.
Вычитывание сообщений достаточно «легкая» операция, но тут надо иметь меру - не имеет смысла сидеть и слушать сообщения, 90% из которых придется выбросить.
- еще интересный момент с Kafka Streams. API заточен на семантику «один топик - один тип сообщений, что может затруднить использование этого фреймворка в ситуации, когда в топике присутствуют сообщения разного типа.

Кстати, этим вопросом так же озадачился Мартин Клеппманн и накатал добрую портянку текста.
Полную версию (eng) можно прочитать тут
https://www.confluent.io/blog/put-several-event-types-kafka-topic/

Там, кстати, так же затрагивается вопрос «A как же быть со схемами?»
Он даже запилил PR https://github.com/confluentinc/schema-registry/pull/680 для Confluent Schema Registry, который, если вы используете Avro Serializer позволяет работать с разными типа сообщений более проще.