11 сентября в Санкт-Петербурге прошел Java Meetup, полностью посвященный Apache Ignite. Огромное спасибо организаторам за приглашение и возможность рассказать об Open Source от лица разработчика этого самого Open Source. Учитывая позитивную реакцию зала, я решил поделиться презентацией и с теми, кто не смог присутствовать на митапе.

Под катом вас ожидает текстовая версия презентации, полная субъективного восприятия Open Source, как позитивного, так и негативного.

15 сентября в Авито прошёл митап, на котором мы говорили о масштабировании приложений на PostgreSQL. Сегодня я хочу поделиться материалами с него — видеозаписями, презентациями от докладчиков, показать фото. Также под катом публикую разбор вопросов викторины, которую мы проводили здесь, на Хабре, перед митапом. И рассказываю о своих впечатлениях от встречи.

Осталось буквально несколько дней до новой встречи #RuPostgres. Она пройдёт уже в эту субботу, 15 сентября, в офисе Авито. Будем говорить о масштабировании приложений на PostgreSQL. Хорошие новости — у нас немного расширилась программа, и осталось ещё несколько свободных мест для слушателей. Присоединяйтесь. А ещё мои коллеги придумали мини-викторину, посвященную Postgres. Её мы проводим онлайн, поэтому принять участие могут все. Подробности под катом.

Меня зовут Юрий Невиницин, и я занимаюсь системой внутренней статистики в «ОК». Хочу рассказать о том, как 50-терабайтную аналитическую систему реального времени, в которой ежедневно журналируются миллиарды событий, мы переносили с Microsoft SQL на колоночную базу под названием Druid. И заодно вы узнаете несколько рецептов использования Druid’а.

Здравствуйте, коллеги.

Мы только что отдали в перевод интересную книгу Брендана Бёрнса, рассказывающую о паттернах проектирования для распределенных систем

Кроме того, у нас уже полным ходом идет перевод книги "Mastering Kubernetes" (2-е издание) и готовится к выходу в сентябре авторская книга о Docker, о которой обязательно будет отдельный пост.

Полагаем, что следующая остановка на этом пути — книга о Prometheus, поэтому сегодня предлагаем вашему вниманию перевод небольшой статьи Бьёрна Венцеля о тесном взаимодействии Prometheus и Kubernetes. Не забудьте пожалуйста поучаствовать в опросе.

Мы давно стремимся быть максимально открытыми и делиться опытом, пусть и не всегда идеальным. Это помогает не только находить узкие места у себя в разработке, но и пробовать что-то новое.

И если в текстовом формате мы не первый раз рассказываем истории из разработки, то теперь решили организовать митап в сентябре вместе с друзьями из DevGAMM, где будем на реальных кейсах разбирать архитектуру в глобальном понимании — от системных решений и приложений до архитектурных паттернов и стилей. И в этот раз мы решили уйти от традиционного стиля «митапов», поэтому — всего 222 отобранных приглашенных, актуальные темы и крутой нетворкинг на митапе (А|а)рхитектура.

А для тех, кто заинтересовался — под катом FAQ и подробности.

Разрабатывая различные приложения, использующие популярную библиотеку Castle Windsor для внедрения зависимостей и Apache Ignite.NET в качестве «ключика», который открывает дверь в «облачные» вычисления, я столкнулся с небольшим неудобством: у меня не было никакой возможности внедрить зависимость в сервис, запускаемый через так называемый Service Grid.

Причина по которой это происходит довольна банальна. Apache Ignite.NET сериализует сервис, отправляет его на один из доступных серверов, где он десериализуется и запускается. Так как этот процесс никаким образом не имеет понятия о Castle Windsor, мы получаем то, что получаем.

Для решения этой проблемы нам необходимо создать плагин для Apache Ignite.NET, который получит контейнер, отвечающий за внедрение зависимостей и предоставить возможность сервису обратиться к нему, для получения того или иного объекта.

Понятие IoT (Internet of Things) давно вошло в лексикон IT-шников. Хотя я и не нашел такого хаба, но надеюсь это скоро будет исправлено :)

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

Введение

Решил проанализировать статью, описывающую некоторые интересные детали потоковой обработки ровно один раз: exactly-once. Дело в том, что некоторые авторы очень странно понимают термины. Разбор статьи как раз позволит прояснить многие детали более глубже, т.к. выявление нелогичностей и странностей позволяет более полноценно прочувствовать понятия и смысл.

Приступим.

Анализ

Начинается все очень даже неплохо:

На последней встрече сообщества Apache Ignite в Москве я рассказывал про:

• Open source-сообщество;
• Власть и деньги в open source;
• Как стать контрибьютором и коммитером, и зачем это нужно.

Ограниченное время доклада не позволило привести больше примеров, поэтому расширенную версию выкладываю на Хабре. Всё изложенное основано на моем личном опыте и не является официальной позицией какой-либо компании или организации.

Недавний пост о том как мы в Сбербанк-Технологиях разрабатываем Open Source раскрыл множество интересных подробностей о подходах, стремлениях и идеологии.

Сегодня я хочу рассказать о том реальном вкладе, который наша команда вносит в Open Source.

Как считать хиты страницы google.com? А как хранить счётчик лайков очень популярных пользователей? В этой статье предлагается рассмотреть решение этих задач с помощью CRDT (Conflict-free Replicated Data Types, что по-русски переводится примерно как Бесконфликтные реплицированные типы данных), а в более общем случае — задачи синхронизации реплик в распределённой системе с несколькими ведущими узлами.

1. Что такое Micronaut

Micronaut — это фреймворк на JVM для построения легковесных модульных приложений. Он разработан компанией OCI, той же компанией, что подарила нам Grails. Micronaut это современный фреймворк, призванный сделать создание микросервисных приложений быстрым и простым.

Micronaut содержит возможности похожие на существующие фреймворки, такие как Spring, но в то же время он реализует некоторые новые идеи, которые являются его отличительными чертами. Вместе с поддержкой Java, Groovy и Kotlin он предлагает множество путей создания приложений.

До недавнего времени в Одноклассниках около 50 ТБ данных, обрабатываемых в реальном времени, хранилось в SQL Server. Для такого объема обеспечить быстрый и надежный, да еще и устойчивый к отказу ЦОД доступ, используя SQL СУБД, практически невозможно. Обычно в таких случаях используют одно из NoSQL-хранилищ, но не всё можно перенести в NoSQL: некоторые сущности требуют гарантий ACID-транзакций.

Это подвело нас к использованию NewSQL-хранилища, то есть СУБД, предоставляющей отказоустойчивость, масштабируемость и быстродействие NoSQL-систем, но при этом сохраняющей привычные для классических систем ACID-гарантии. Работающих промышленных систем этого нового класса немного, поэтому мы реализовали такую систему сами и запустили ее в промышленную эксплуатацию.

Как это работает и что получилось — читай под катом.

Автоматическое разрешение конфликтов в среде с более, чем одним ведущим узлом (в данной статье под ведущим узлом понимается узел, который принимает запросы на изменение данных) – очень интересная область исследований. Существует несколько различных подходов и алгоритмов, в зависимости от области применения, и в данной статье будет рассмотрена технология Операциональных Преобразований (Operational Transformations, OT) для разрешения конфликтов в приложениях совместного редактирования, таких как Google Docs и Etherpad.

В мае вышла новая версия Apache Ignite — 2.5. В неё внесено множество изменений, с полным списком которых можно ознакомиться в Release Notes. А в этой статье мы рассмотрим ключевые новшества, на которые стоит обратить внимание.

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

Ignite применяют в тех случаях, когда нужна горизонтальная масштабируемость и очень высокая скорость обработки данных. Последнее достигается также за счет оптимизации платформы под хранение данных непосредственно в RAM в качестве первичного хранилища, а не кеша (In-Memory Computing). Отличительными особенностями продукта являются полноценный движок запросов ANSI SQL 1999, дисковое хранилище, расширяющее RAM, большое количество встроенных интеграционных инструментов и Zero-ETL машинное обучение.

Среди компаний, которые используют Apache Ignite такие фирмы, как Veon/Beeline, Сбербанк, Huawei, Barclays, Citi, Microsoft и многие другие.

Новый вариант топологии: звезда вокруг ZooKeeper

Одно из главных изменений в версии 2.5 — новый вариант топологии. Ранее в Ignite была лишь топология «кольцо», которая использовалась для обмена событиями внутри кластера и обеспечивала эффективную и быструю масштабируемость, на масштабе до 300 узлов.

Новая топология предназначена для инсталляций из многих сотен и тысяч узлов.

Один из главных трендов развития информационных технологий в последние 20 лет – перенос сложных вычислений с локального компьютера на удаленные серверы, которые соединены с ним через компьютерные сети. Начиналось всё с концепции «сетевого компьютера», которая затем переросла в облачные вычисления.

И вот после этой логичной технологической эволюции мы снова слышим разговоры о том, что часть вычислений лучше всё-таки переносить на локальные устройства. Речь идёт о так называемых периферийных вычислениях, или Edge Computing. Что это — дальнейшее развитие технологий или разворот назад?

Привет, Хабр!

Вместе с нашими друзьями из IBM приглашаем на митап, где подробно расскажем про HyperLedger Fabric. Ждём всех: разработчиков, архитекторов, инженеров и просто тех, кто хочет разобраться, как работает Fabric.

Увы, но ответ неоднозначный – и да, и нет. Выбрать-то, конечно, легко, но запутаться еще проще. Так вот, о том, как не запутаться, и пойдет речь.

ДГУ у вас или другое оборудование — универсального решения по дистанционному мониторингу и управлению, которое подходит всем, умеет все и стоит дешево, не существует. Ограничения есть всегда. Один вариант предлагает скудный набор функций, но за копейки, другой наоборот – требует высокой цены, но за большие возможности. А между ними будут бесчисленные вариации, сочетающие в себе функциональность и цену в разных пропорциях. И кажется, что можно легко потеряться в этом море решений. Хотя…



Но на самом деле все проще, ведь вариантов решений всего 3, и в них можно разобраться.

Привет Хабр! Предлагаю вашему вниманию перевод статьи «Do you need a Blockchain»

Часть 1 (Управление цепочками поставок)

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

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

Мы различаем публичные (permissionless) Bitcoin \ Ethereum, и частные (permissioned) Hyperledger \ Corda блокчейны и противопоставляем их свойства свойствам централизованно управляемых баз данных. мы покажем структурированную методику для определения оптимальных технических подходов при решении конкретных прикладных задач. мы проанализируем три случая — Управление цепями поставок (Supply Chain Management), межбанковские и международные платежи (Interbank and International Payments), и Децентрализованные автономные организации (Decentralized Autonomous Organizations).