Apache Kafka можно бесплатно скачать, развернуть и подключить к приложениям. При небольшом проекте этого может быть достаточно: создали несколько топиков, настроили потребителей — и обмен сообщениями работает.

Но по мере роста инфраструктуры Kafka перестает быть просто брокером. От нее начинают зависеть функциональность микросервисов, интеграции, тестовые стенды, CI/CD‑процессы и рабочие системы. Вместе с нагрузкой растет и список вопросов: как обновлять кластеры, отслеживать очереди, устранять уязвимости и восстанавливать работу после отказа.

Меня зовут Илья Виссарионов, я директор департамента «Аппаратно‑системная платформа» компании «Диасофт», и в этой статье расскажу, как мы используем Kafka в DevOps‑инфраструктуре «Диасофта», какие проблемы обнаружили при эксплуатации под высокой нагрузкой и почему в итоге стали рассматривать брокер сообщений не как отдельный open‑source‑компонент, а как полноценную инфраструктурную платформу.

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

Меня зовут Жуйков Андрей, занимаюсь развитием и продвижением СУБД Digital Q.DataBase.

Сегодня для многих организаций импортозамещения СУБД - уже практическая задача, которую необходимо решать без остановки бизнес-процессов и без многомесячной переработки прикладных систем. Одним из ключевых требований при выборе новой платформы становится возможность сохранить существующую прикладную логику и минимизировать объем изменений в коде приложений.

В этой статье я покажу, как установить Digital Q.DataBase 18.2 на РЕД ОС 8.0.3, познакомлю с новой архитектурой СУБД и продемонстрирую подключение к каждому из поддерживаемых диалектов.

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

Я Сергей Рощупкин, занимаюсь развитием платформы управления серверами приложений Digital Q.AppServer в «Диасофт». В статье разберу реальный кейс миграции с Oracle WebLogic в крупном банке, покажу, как устроена платформа и где в ней работают ИИ‑агенты, а в конце — практические советы инженерам, которые мы сформулировали по итогам проектов.

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

Я Михаил Кулаков, в «Диасофт» занимаюсь развитием импортонезависимой платформы распределенных реестров Digital Q.Blockchain.

Про закон «О цифровых валютах и цифровых правах» написано уже достаточно, и подробных разборов по статьям хватает. Ограничусь рамкой: закон вступает в силу 1 сентября 2026 года, требования к предотвращению операций без добровольного согласия клиента – годом позже, и на финансовом рынке появляется новый профессиональный участник. Цифровой депозитарий ведет учет цифровых валют и цифровых прав по цифровым счетам и предоставляет доступ к адресам-идентификаторам, а работать в этом статусе можно только после включения в соответствующий реестр Банка России.

Значительно меньше внимания уделяется другому вопросу – тому, как этот участник устроен внутри. Между тем именно здесь сосредоточена основная часть проектных рисков ближайшего года, и именно об этом я хотел бы поговорить предметно.

Переход крупных корпоративных систем на отечественные СУБД остается одной из наиболее актуальных задач последних лет. Однако основная сложность подобных проектов заключается не столько в переносе данных, сколько в сохранении работоспособности существующих приложений, написанных под Microsoft SQL Server и Oracle Database.

Именно поэтому развитие Digital Q.DataBase сосредоточено сразу на нескольких направлениях: расширении совместимости с зарубежными СУБД, автоматизации миграции и создании инструментов, позволяющих минимизировать объем ручной доработки приложений.

Версия 18.2 стала одним из наиболее масштабных обновлений платформы. В релиз вошли изменения архитектуры продукта, значительное развитие совместимости с Microsoft SQL Server и Oracle Database, новые возможности мастера миграции, первая версия службы построения отчётов, совместимой с SQL Server Reporting Services, а также десятки других улучшений.

Подробнее об изменениях - в этой статье.

Мы в Диасофт несколько лет назад начали строить Digital Q.DevOps — внутренний конвейер сборки, тестирования, доставки и развёртывания, — и сейчас через него проходит больше 2000 развёртываний в сутки. На прошлой неделе собрали внутренний митап с разработчиками, тестировщиками и DevOps-инженерами, чтобы честно разобрать, что в продукте получилось, что до сих пор болит, и куда мы движемся.

Привет, Хабр. Меня зовут Виктор Овчинников, я руковожу разработкой интеграционной платформы Digital Q.Integration в компании Диасофт.

Про то, как интеграционный слой убивает ИИ-проекты, я уже писал здесь и здесь. Про историю появления платформы — тридцать лет проектной боли и зоопарк западных ESB написал Дмитрий Гаврин в отдельной статье. Рекомендую прочитать, если не читали.

Сегодня разберу технику. Что именно сидит под капотом платформы, какие инструменты мы выбрали и почему, где это работает хорошо, а где ломается.

Почему не классический ESB

Коротко, потому что Дмитрий уже написал развёрнуто.

Классическая ESB — это монолитное ядро. Масштабирование только вертикальное. И при падении падает всё. Но самое болезненное для эксплуатации это то, что со временем шина становится местом, куда стекается вся прикладная логика. Через несколько лет она знает о бизнесе компании больше, чем любая из систем, которые к ней подключены. Разобраться в этом — отдельная задача. Это то нас и подтолкнуло к собственному подходу.

Мы сформулировали для себя так: возьмём лучшее из point-to-point и из ESB. Независимые сервисы — без централизованной бизнес-логики. Общий транспорт, общий мониторинг, общий инструментарий — как в ESB.

Концепция называется «умные сервисы и надёжные каналы».

Архитектура: каждая система — отдельный микросервис

Предлагаю посмотреть, как это работает. Для каждой интегрируемой системы создаётся независимый микросервис-коннектор. Он содержит ровно ту логику, которая нужна для взаимодействия с этой системой — и ничего лишнего. Адаптеры общаются через транспортный уровень, который отвечает за доставку и надежность.

Что важнее при выборе СУБД: выручка разработчика или реальные возможности продукта?

На российском рынке долгое время ответ фактически сводился к рейтингам продаж. Но ситуация постепенно меняется. Исследование ЛАНИТ стало одной из первых попыток сравнить отечественные СУБД не по финансовым показателям, а по техническим характеристикам — от совместимости и миграции до безопасности и администрирования.

Однако при внимательном изучении результатов возникли вопросы ....

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

Меня зовут Жуйков Андрей, в Диасофт я занимаюсь развитием и продвижением СУБД Digital Q.DataBase.

Импортозамещение СУБД перешло из разряда регуляторных требований в практическую плоскость: компаниям нужно менять платформы без остановки бизнеса. Типичная проблема — огромная экосистема вокруг MS SQL, PostgreSQL или Oracle с тысячами процедур, отчетов и интеграций. Ручной перенос такого объема (например, 900 тысяч строк кода) занимает месяцы и несет риски, при этом даже автоматизация не исключает доработок.

Даже с автоматизированными средствами конвертации большинство проектов миграции СУБД требует доработок и тестирования, поэтому ключевым требованием становится сохранение существующей логики приложений. Digital Q.DataBase решает эту задачу через воспроизведение функциональности популярных СУБД и поддержку их диалектов SQL, что позволяет переносить системы быстрее без масштабной переработки прикладного слоя.

В новой версии Digital Q.DataBase существенно переработана архитектура продукта. Вместо единого монолитного решения СУБД получила независимые модули, воспроизводящие функциональность PostgreSQL, Microsoft SQL Server и Oracle Database. Это упрощает установку, сопровождение и обновление системы, а также позволяет использовать только те компоненты, которые действительно необходимы в конкретном проекте.

В этой статье покажу, как установить Digital Q.DataBase 18.2 на Astra Linux 1.8, познакомлю с новой архитектурой продукта и продемонстрирую подключение к каждому из поддерживаемых диалектов.

Привет, Хабр!  Меня зовут Александр Сахаров, я Член Правления и директор по работе с технологическими партнерами компании «Диасофт».

Недавно провели Летний день для клиентов и партнеров – на нем мы представили наше видение ИИ трансформации процесса разработки ПО и провели демонстрацию новой AI Driven версии нашей Экосистемы Digital Q.

Ключевая мысль: уже этим летом любая команда разработки может скачать с сайта Экосистему Digital Q и начать выпускать ПО высочайшего качества со скоростью в 10 раз быстрее, чем сегодня.

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

Проблема в том, что этим набором серверов нужно управлять ежедневно. Администратору уже недостаточно просто понимать, что приложение запущено: нужно контролировать состояние серверов, следить за приложениями и метриками, развертывать новые версии и быстро выполнять типовые операции без лишней ручной работы. Когда ИТ-контуров становится больше, разница между «в целом работает» и «удобно эксплуатируется» начинает ощущаться особенно остро.

Digital Q.AppServer как раз закрывает эту задачу: платформа дает единый интерфейс для работы с серверами приложений Digital Q.TomEE и Digital Q.WildFly и собирает в одном месте основные операции сопровождения. В центре внимания здесь – уже не сам по себе выбор между серверами, а то, что ими можно управлять как частью одного эксплуатационного процесса, а не как набором разрозненных систем.

Привет, Хабр! Меня зовут Александр Сахаров, я директор по работе с партнерами компании "Диасофт".

За двадцать с лишним лет в индустрии никто из нас не видел идеального ТЗ. Ни разу. При этом каждый новый проект начинается с уверенного «у нас всё прописано». Компании теряют сотни миллионов на выборе стека, который считают «деталью». А low-code продолжают высмеивать, не заметив, что инструмент за десять лет стал другим.

Есть три мифа, за которые индустрия стабильно платит: «у нас всё написано в ТЗ», «архитектура и стек — детали, разработчики разберутся», и «low-code — для тех, кому лень писать настоящий код». Я собрал практиков из заказной разработки, чтобы разобрать каждый из них. Получился один из редких разговоров, где люди активно спорят, защищая свою точку зрения.

Полная запись на Youtube. Обсуждение — в Telegram-канале Департамент разработки.

Привет, Хабр. Меня зовут Виктор Овчинников, я руковожу разработкой интеграционной платформы Digital Q.Integration в компании Диасофт. 

Больше двадцати лет моя команда занимается обменом данными между корпоративными системами, и про то, как именно этот слой убивает ИИ-проекты, я уже подробно разбирал в предыдущей статье на Хабре. 

Интеграция - это только одно из пяти узких мест, на которых ломается реальное ИИ-внедрение. Дальше идут атаки на агентов, регуляторика, разрыв стоимости разработки и сценарий, которого нет в голове у заказчика. Со мной в этом разборе еще трое: ИИ-архитектор Андрей Носов, Team Lead пентестер Сергей Зыбнев и директор по информационной безопасности компании Вебмониторэкс Лев Палей. 

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

Это Андрей Ловлин, руководитель команды «Фабрика данных. Платформа» компании Диасофт. В предыдущей статье мы рассказывали про S3 Архипелаг – слой хранения для нашей «Фабрики данных» (Digital Q.DataFactory). Сегодня речь пойдет о другой задаче: построение конвейера интеллектуального распознавания документов, загружаемых в нашу «Фабрику данных».

PDF-файлы, сканы, фотографии договоров – все это накапливается в организациях годами. Для построения RAG-систем и работы с LLM эти данные необходимо извлечь из неструктурированных документов и преобразовать в структурированный формат. Задача, на первый взгляд, тривиальная. На практике – не совсем.

Привет, Хабр! Меня зовут Александр Сахаров, я отвечаю за партнерства в «Диасофт». Хочу разобрать с вами один сюжет, который рынок сейчас подает максимально противоречиво, - платформенную разработку.

Повод любопытный. Прямо сейчас идут два встречных сигнала. «Ведомости» в апреле написали, что интерес крупного бизнеса к low-code за год упал почти вдвое: с 66% компаний в 2025 году до 34% в 2026-м. А свежие обзоры по integrated development environment говорят ровно обратное: внутренние платформы разработки внедряют все активнее. Так в какую сторону мы на самом деле движемся - и чего при этом боимся?

Привет, Хабр. Меня зовут Виктор Овчинников, я руковожу разработкой интеграционной платформы Digital Q.Integration в компании Диасофт. 

Больше двадцати лет моя команда занимается обменом данными между корпоративными системами. Все эти годы интеграция оставалась скучной технической прослойкой, которую в бюджетах по привычке записывали в строку «поддержка». В 2026 году ситуация изменилась, и не потому, что шины вдруг стали красивее или модными, а потому, что ИИ‑проекты начали массово застревать именно в интеграционном слое. В этой статье разберу, почему так происходит, какие архитектурные подходы ломаются первыми на ИИ‑нагрузке и что мы в Диасофт выбрали в качестве рабочего варианта. Будет кейс крупного банка, три грани, на которых интеграция включает или выключает всю ИИ‑стратегию, и честный ответ, когда интеграционная платформа вам не нужна.

Главный тормоз корпоративных ИИ‑проектов в 2026 году это не выбор модели, не мощности GPU и не цена за токены. Это банальный обмен данными между корпоративными системами. В апрельском исследовании Integrate.io 95% ИТ‑директоров назвали проблемы интеграции главным барьером внедрения ИИ. Отчет Anthropic State of AI Agents 2026 фиксирует ту же картину с другого угла: среди инженеров, которые уже строят агентные системы на продакшене, 46% называют интеграцию с существующими корпоративными системами главным техническим вызовом — она обошла и вопросы безопасности, и надежность самих моделей.

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

На связи Александр Сахаров, директор по работе с партнерами, член правления компании Диасофт. В этой статье разберу, как работают low-code платформы, почему компании все чаще выбирают этот подход, и как он помогает сократить расходы на разработку.

Бизнес сегодня работает в режиме постоянных изменений: рынок требует новых решений быстрее, чем ИТ-команды успевают их разрабатывать. Классический путь от технического задания до готового продукта занимает месяцы, а требования за это время уже устаревают. Именно здесь на сцену выходит low-code — подход, который позволяет создавать рабочие приложения в разы быстрее, не нанимая армию разработчиков и не переписывая код с нуля каждый раз, когда что-то меняется.

На связи Илья Шуйков, руководитель продукта «Фабрика данных» компании Диасофт.

В прошлой статье мы рассказали, зачем понадобилось строить свое объектное хранилище, и как устроен S3 Архипелаг изнутри. Теперь — практика: берем дистрибутив и разворачиваем рабочее хранилище.

Разрозненные ИТ-системы остаются одной из причин, почему бизнес-процессы буксуют: CRM не получает данные из ERP, внешние сервисы падают из-за несогласованных форматов, а интеграции превращаются в долгий ручной труд. Чем больше систем, сервисов и данных использует компания, тем важнее иметь управляемый интеграционный слой, который помогает бизнесу развиваться без хаоса в обмене данными. Связать системы в единую управляемую архитектуру помогают интеграционные платформы — например, Digital Q.Integration.

Собрали главные новости платформы за последнее время.

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

Дано: банковская система с 1098+ API только find(get) и документацией на API размером 11 тысяч HTML-файлов. Как «подружить» такую АБС с ИИ? В этой статье расскажу, как это получилось, и почему первая попытка провалилась.

Я построил двухмодульную систему: 1) парсер, который превращает этот HTML-хаос в структурированные JSON-метаданные с графом зависимостей, и 2) MCP-сервер, который динамически собирает контракты инструментов и позволяет ИИ вызывать хранимые процедуры в БД. Проект является community-версией, ссылка на GitHub – в конце статьи.