Импортозамещение сервера приложений – это не только перенос 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.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, познакомлю с новой архитектурой продукта и продемонстрирую подключение к каждому из поддерживаемых диалектов.

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

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

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

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

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

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

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

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

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

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

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

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

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

Обычно разговор об аналитике в HR начинается с благих пожеланий: «Давайте оцифруем компетенции», «Построим дашборд удовлетворенности». Заканчивается это часто стандартно: выгрузкой Excel‑таблиц из ЗУПа, ручным копированием резюме из Outlook в папку «Кандидаты — зима — 2025(финальная версия)2» и бесконечными правками.

В этой статье мы посмотрим на HR‑данные как на продукт: со своей архитектурой, контрактами и ответственными за результат. Поговорим о том, как построить пайплайн, который в реальном времени показывает не абстрактную статистику, а реальную динамику бизнес‑процессов.

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

Я Денис Тимощук, руководитель направления «Управление командами и задачами» в Диасофт. В этой статье я расскажу, как нам удалось снизить время на выполнение типовых работ в 2 раза за первый год и превратить нормирование из бюрократической обузы в инструмент масштабирования эффективности.

Помните, как вы внедряли Jira, Asana или Trello? Казалось, что это и есть цифровая зрелость: задачи поставлены, коммуникация прозрачна, все удобно.

Но есть один момент, который компании осознают по мере роста: эта связка хорошо работает ровно до тех пор, пока ваша компания не перешагивает порог в 100-150 сотрудников.

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

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

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

Это Михаил Кулаков. Я ведущий инженер-аналитик в Диасофт, занимаюсь развитием платформы распределенных реестров Digital Q.BlockChain.

Помните, как в начале 2000-х каждый банк строил свою собственную систему онлайн-банкинга? Одни использовали Java, другие – .NET, третьи – что-то свое. Клиенты мучились: чтобы перевести деньги из одного банка в другой, приходилось распечатывать платежки и ехать в отделение. Сегодня рынок ЦФА в России переживает похожий этап. 19 операторов – 19 изолированных крепостей. Инвестор у «Оператора А» не может купить актив у «Оператора Б», даже если оба используют блокчейн. И проблема совсем не в технологиях.

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

Я Анна Круглова, в Диасофт занимаюсь развитием инструментов автоматизации тестирования на базе искусственного интеллекта.

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

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

Меня зовут Андрей Жуйков, и в этой статье я хочу рассказать вам историю абсолютно практического содержания. Без теоретических рассуждений и без лозунгов про импортозамещение. Это реальный кейс о том, как мы перевели несколько наших корпоративных 1С с Microsoft SQL Server на Digital Q.DataBase.

Для российских компаний выбор между серверами приложений на базе Apache Tomcat и WildFly давно перестал быть спором о «любимом стеке разработчиков». Это стратегическое решение, влияющее на устойчивость бизнес‑сервисов, стоимость владения ИТ‑ландшафтом и способность пройти путь импортозамещения без рисков для критичных систем.

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

Гораздо продуктивнее смотреть на сервер приложений на базе Apache Tomcat и сервер приложений на базе WildFly как на два разных типа решений под разные задачи – и выстраивать платформу, которая позволяет использовать оба подхода в едином управляемом контуре.

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

Однако со временем в компании была создана экосистема low-code разработки микросервисных программных продуктов Digital Q, которая позволила нашим производственным командам автоматически генерировать часть прикладного кода, что значительно ускорило разработку продуктов.

Как следствие внедрения экосистемы low-code платформ быстро росло количество продуктов и команд. В день мы делали уже более 2 000 коммитов от 100+ команд в 300+ микросервисах на 200+ проектах.

На этом этапе встал вопрос: как теперь быстро, полностью автоматически, выпускать и доставлять все это? Ответом стало решение «Диасофт» Digital Q.DevOps. Оно автоматизирует весь процесс (от сборки и выпуска продуктов до доставки на нужные стенды), включая такие важные этапы, как прохождение автотестов и проверки на уязвимости.

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