Apache Kafka — это платформа потоковой обработки событий, которую используют 30% компаний из Fortune 500. У Kafka много функций, благодаря которым платформа задает стандарт обработки событий, и здесь мы поговорим о пяти самых важных аспектах, которые должны быть известны любому, кто работает с Kafka.

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

В начале этого года я прочитал на habr любопытную статью "Почему Discord переходит с Go на Rust", переход был связан с неэффективным механизмом сборки мусора в Go. Тогда подумалось, что, наверное, было бы проще доработать приложение и не переходить. Но еще проще было бы избежать таких проблем на стадии разработки.

Прим. перев.: автор этого материала — Герман Осин, старший архитектор решений в Provectus. Осин сравнивает функциональность восьми UI-инструментов, которые помогают решить проблемы наблюдаемости и мониторинга Apache Kafka. Стоит отметить, что обзор скорее вводный. Он будет полезен для первоначального знакомства с возможностями решений.

Apache Kafka — незаменимый инструмент для обработки данных в реальном времени и отслеживания активности приложений. К сожалению, мониторинг кластеров Apache Kafka и управление ими — непростая задача. Решить ее помогают сторонние коммерческие или Open Source-инструменты с графическим интерфейсом и дополнительными функциями в области администрирования и мониторинга.

В статье представлен краткий обзор таких инструментов.

Что за Debezium и вообще CDC?

Здесь опишу пример сериализции данных через Avro и передача в Kafka. Для Avro есть сериализатор данных для Kafka, он использует в своей работе реестр (registry) схем и поддерживает версионность на отдельном развернутом сервере. Здесь будет только сериализатор, а версионность если потребуется, то например может быть реализована своя, например в БД.

Всем привет.

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

Спойлер: на данный момент реестр схем данных настроен и используется в боевой системе, каких-то проблем, связанных с SR, замечено не было.

Этот небольшой гайд для тех, кто давно хотел сделать свой сайт на своем домене и разместить на своем сервере, но все никак.

С чем будем работать далее: 

• Узнаем, что такое доменное имя и как оно связано с DNS.

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

• Настроим ресурсные записи, чтобы привязать доменное имя сайта к вашему IP‑адресу. Дополнительно рассмотрим, как при помощи DDNS автоматизировать обновление адресов, если у вас нет выделенного IP.

• Развернем виртуальную машину, на которой будет работать сайт. (аналогичные действия можно проделать и на каком‑нибудь специально выделенном для этого физическом железе или VPS).

• Развернем http‑сервер NGINX.

• Настроим конфигурацию для размещения сайта и проверим, что сайт‑лендинг открывается.

• Узнаем, как прикрутить ssl сертификаты и https.

• Если используются какие‑то другие сервисы, например, nodered, узнаем, как использовать купленный домен в своих сервисах в варианте, например, nodered.mydomainhere.ru и т.д., вместо 77.88.111.222:1880 или mydomainhere.ru:1880 (т. е. поработаем с доменами третьего уровня).

• Получим бесплатные Wildcard SSL сертификаты от Lets Encrypt при помощи утилиты Cerbot, и настроим их для использования в NGINX.

Тех, кому интересно, приглашаю далее.

Свежая подборка новостей и материалов.

Интересное в этом выпуске

Выпущен Go 1.20, консольный клиент chatGPT, система управления пользователями (zitadel), Платформа сбора информации для телефонных номеров (phoneinfoga), Как развиваться GoLang разработчику? (подкаст)

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

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

Сегодня я хочу рассказать о первой из трёх задач из категории Crypto с прошлогоднего CTF HTB «Cyber Apocalypse». Задачи на криптографию моя отдельная любовь, поскольку позволяют нетрадиционно взглянуть как на привычные криптографические алгоритмы, так и на неудачные попытки их использования. Особенно интересно искать уязвимость в самописных алгоритмах. Последнее наиболее опасно в реальной жизни, поскольку некоторые разработчики уверены, что уж они то смогут как минимум правильно реализовать известный алгоритм, а не тянуть за собой OpenSSL. Некоторые даже стараются написать свой собственный алгоритм и тем самым обеспечить надежную защиту данных! Множество CTF задач разной сложности обычно позволяют быстро развенчать этот миф :-)

Код Хабра день за днём впитывает в себя время, мысли и чаяния многих людей. Этому коду более 10 лет: он оброс множеством знаний, в том числе и тайных. Места c bus factor = 1 — не эка невидаль, а вполне конкретные люди с ответами на часто задаваемые вопросы.

Меня зовут Антон Каракулов, я тимлид команды бэкенд-разработки Хабра. Хабр стартовал в 2006 году, и за всё время здесь поработало, наверное, команд пять. Мне посчастливилось быть в двух из них, забегал в третью.

Эту статью я написал в рамках проекта Хабра «IT-гид», где разработчики рассказывают про свои направления. Постарался собрать в ней главные практические выводы и интересные грабли, которые нам попадались в процессе превращения старого хабракода в чистый, масштабируемый и понятный для всех — то есть человекочитаемый.

Все события утрированы, а совпадения — беспочвенны.

Создание простого проекта потоковой обработки событий – не самая простая задача. В сегодняшней статье мы расскажем, как можно достаточно просто сделать это при помощи Kafka, BigQuery & Looker Studio.

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

Вероятно, один из главных в мире текстов об автоматизации — статья «Ironies of Automation» когнитивного психолога Лизанны Бейнбридж, опубликованная в 1983 году в журнале Automatica. На неё ссылаются более 1800 других академических работ, про неё есть страница в Википедии, её продолжают вспоминать спустя сорок лет после публикации. Думаю, что сейчас, когда ChatGPT и беспилотные автомобили порождают новый виток замены людей машинами, этот текст по-прежнему очень актуален.

Но вот на Хабре об этой статье вроде бы никогда не писали. Я и сам узнал о ней почти случайно: мы проводим Java-конференции, где её упомянул один из спикеров. И ощутил, что она была бы полезна здесь на русском. Но поскольку исходная публикация академическая, она не вполне в стилистике Хабра. Поэтому я решил не переводить её дословно, а пересказать ряд тезисов оттуда своими словами и добавить немного от себя. Для тех, кому хочется полной точности, даю ссылку на оригинал.

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

Но без делегирования полномочий не решается проблема загруженности ТОП менеджмента. Происходит интересная ситуация, когда есть человек “отвечающий” за проект, но все решения принимает ТОП менеджмент. Проблема становиться менее видимой, потому что “виноват” во всех принятых решениях ПМ. ПМ, как правило, ответственный человек, то он упорно ищет причины неудач в себе. В компании могут звучат красивые слова про то, что каждый может повлиять на ситуацию, у нас Lean, Agile и вот это все. Но это только мешает увидеть несоответствие обязанностей и полномочий.

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

Недавно мы проводили вебинар «Обкафкился по полной. Фейлы с Apache Kafka». На нём спикер Всеволод Севостьянов, Engineering Manager в HelloFresh, поделился фейлами из личной практики, а ещё рассказал, как мастерски ходить по тонкому льду Kafka и прокачать свой бэкенд. Для тех, кто пропустил или предпочитает читать, а не смотреть, подготовили текстовый вариант.

Хабр, привет! Меня зовут Екатерина Герт, я ведущий аналитик и ресурсный менеджер одной из групп аналитиков в КРОК. В этих двух ролях я много работаю с новичками. Как аналитик на уровне проекта знакомлю новичка с проектной командой и спецификой предметной области, а как руководитель погружаю в стандарты и практики работы аналитиков в компании. 

За последние 3 года количество аналитиков-новичков, которые приходят к нам в команду, выросло почти в 6 раз. К нам приходят новички разного уровня, от младших до ведущих. У каждого – свой багаж знаний и практический опыт. Важно адаптировать этот опыт и знания к практикам работы, которые приняты компании. Если не заниматься адаптацией, то каждый новичок будет работать так, как он привык. Команда и заказчики будут ожидать совсем другого результата, к которому они тоже привыкли. В итоге – хаос неизбежен. 

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

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

Я не художник, но иллюстрации в тексте – мои :)