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

Меня зовут Андрей Жуйков, и в этой статье я хочу рассказать вам историю абсолютно практического содержания. Без теоретических рассуждений и без лозунгов про импортозамещение. Это реальный кейс о том, как мы перевели несколько наших корпоративных 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) и адаптированными под наше регулирование блокчейн-решениями. Статья объясняет, как эти два слоя взаимодействуют на практике, где уже применяются и какие вызовы остаются на пути массового внедрения.

Лет десять назад объектное хранилище было экзотикой. Крупные компании обходились NFS‑шарами и надеждой, что RAID не развалится в самый неподходящий момент. Средний бизнес в целом не понимал, зачем это нужно. Но сегодня все изменилось. S3 API стал таким же стандартом, как REST или JSON. Мы в Диасофте построили «Фабрику данных» (Digital Q.DataFactory) в архитектуре Data Lakehouse на основе S3 Архипелаг, которая объединяет гибкость Data Lake с надежностью хранилища данных. В этой статье расскажем, как построили слой хранения.

Контейнеры давно стали стандартом современной разработки. Согласно отчету Docker State of Application Development 2025, они используются примерно в 92% IT-организаций и фактически стали универсальным способом упаковки и запуска приложений независимо от платформы и окружения. Это тот случай, когда инфраструктура перестает мешать и начинает экономить время.

Именно поэтому Digital Q.DataBase доступна, в том числе, в виде Docker-образа. Это позволяет за несколько минут попробовать Oracle- и MS SQL-совместимую СУБД на Windows, Linux и macOS, ограничившись несколькими командами, без сложной установки и длительного онбординга. Полноценная рабочая среда готова к использованию сразу после старта контейнера.

По сути, после того как вы скачали архив и подготовили директорию, для запуска Digital Q.DataBase достаточно четырех команд.

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

В предыдущей статье мы рассказали, как установить Digital Q.DataBase на Astra Linux 1.8 и начать работу с этой российской СУБД, которая поддерживает нативную работу с диалектами MS SQL, PostgreSQL и Oracle. Сегодня мы поговорим о том, как перенести уже существующие данные в Digital Q.DataBase из других систем управления базами данных. 

Для решения поставленной задачи мы разработали инструмент – Мастер переноса БД. Он позволяет выгрузить структуру, данные и хранимую логику из уже развернутой БД на одной из трех СУБД (Oraсle, MS SQL и PostgreSQL) и загрузить их в Digital Q.DataBase без переписывания кода приложений в отличие от любых миграторов-конверторов.

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

Мы много работаем с компаниями, которым необходимо использовать отечественное ПО для баз данных. В таких проектах часто уже есть инфраструктура на MS SQL Server, PostgreSQL или Oracle Database. Основной конфликт — требования регуляторов и высокая стоимость миграции логики приложений на другую СУБД.

Мы создали продукт, который нативно понимает диалекты и позволяет работать с существующими базами без переписывания кода. В статье расскажем, как развернуть Digital Q.DataBase для начала работы с базами без долгой и затратной миграции.