Интервью с Дмитрием Данковым, управляющим партнером и идейным вдохновителем Kairos Digital

Kairos Digital — отечественный вендор линейки продуктов для развертывания современных (Cloud Native) приложений, в которую входят Post-DevOps-платформа Imagenarium, СУБД «Енисей» и Triodata, совместный проект с Jatoba, который решает задачу по миграции с СУБД Oracle на российское решение.

Пресс-служба «ОЛЛИ ИТ», дистрибьютора продуктов Кайрос, поговорила с идейным вдохновителем и управляющим партнером вендора Дмитрием Данковым о том, как справляться с колеей, которая осталась на рынке после ухода Oracle и Microsoft и их СУБД широкого назначения, узнала, как заменить DevOps-ов с помощью Imagenarium, обсудила, как жить в контексте постоянного сравнения ПО с ушедшими западными системами.

— Дмитрий, расскажите, пожалуйста, об истории компании Kairos Digital.

— Kairos Digital как венчурная компания появился в 2022 году, но боевое подразделение ИТ-разработок существует уже 15 лет, все продукты Кайрос созданы в компании «Эквирон».

15 лет мы были подрядчиком различных проектов - от стартапов, в том числе американских, до госкомпаний, много работали на субподряде на государственных проектах в Казахстане, на квазигосударственных проектах. У нас огромная практика в разработке высоконагруженных распределенных систем. В рамках этой практики и родились новые продукты внутри компании «Эквирон», они помогают нам решать массу различных проблем. И «Енисей», и Imagenarium вышли из этой боевой кузницы. Сейчас в рамках Kairos Digital запускается разработка социальной сети, Кайрос выступает в качестве ее инвестора и разработчика. На базе Кайроса есть еще акселератор, «Акселерон», и вот, используя в том числе наши продукты, мы создаем масштабный проект. Публичная бета будет показана в этом году. Название пока не говорим. СУБД «Енисей» сейчас используется в национальной системе цифровой маркировки «Честный знак» – на нем будет работать один из компонентов «Честного сообщества» (это два в одном, соцсеть и маркетплейс). «Енисей» будет использоваться в маркетплейс-модуле и внутри самой нагруженной системы как распределенная система процессинга документов и как хранилище документов. Imagenarium так же используется в «Честном знаке» и в системах маркировки стран СНГ как один из сервисов. На базе Imagenarium построена и эксплуатируется система управления заказами.

— Какие вызовы для себя видит компания сейчас, в условиях ухода иностранных вендоров?

— Именно благодаря этой ситуации мы и упаковали наши продукты в рыночные решения. Imagenarium продавался давно, но как сопутствующий продукт к нашим услугам. «Енисей» стал «Енисеем» в прошлом году благодаря проектам по импортозамещению, до этого мы с 2015 года использовали его для собственных целей как очень сильно доработанный продукт с функционалом и модулями, которых нет у оригинального CouchDB. Выход с «Енисеем» на рынок был для нас тяжелым моментом. Одно дело компании-разработчики, с которыми мы говорим на одном языке, и которые понимают, для чего эти продукты нужны, другое – рынок коробочных решений. Он вообще не готов. На этом рынке осталась колея, проложенная вендорами. Поясню. Был Oracle, был Microsoft, был их технический ресурс. По сути, вся крупная дистрибуция жила на этих трех китах. Когда мы вышли на рынок, столкнулись с тем, что ни у кого нет представления, что такое вообще документная база.

Поэтому «Енисей» был представлен рынку в качестве файлового сервера, документного хранилища, системы хранения геоданных. Это самое сложное - объяснить рынку, кто мы такие. Рынку, где ПО продается с формулировками «Что такое Postgres? Тот же Oracle, только намного хуже». В этом контексте постоянного сравнения программных продуктов друг с другом сейчас все и работают. Много лет на рынке все использовали СУБД широкого назначения, и, пользуясь мощью Oracle, лепили из него все что угодно, и теперь этому рынку тяжело объяснить, что так больше делать нельзя, что нормальные серьезные системы должны быть распределенными, что существуют специализированные СУБД.

Есть два способа: либо изначально сделать правильную архитектуру, либо завести Oracle и превратить в некое монструозное хранилище, а он благодаря своей мощи все вынесет. Сейчас это самая тяжелая часть – найти место на рынке для специализированных продуктов, и с этими продуктами зайти в правильные проекты.

— Раз уж нам не уйти от контекста постоянного сравнения, который Вы упомянули, корректно ли говорить, что «Енисей» заменяет ушедших MongoDB и Oracle NoSQL?

Ну как заменяет. С Mongo мы не очень похожи. Да, она хранит формат JSON, как и «Енисей», но когда-то мы отказались от мысли взять ее к себе в стек, потому что в этой системе слишком много усложнений и, к сожалению, если кто-то ее использует, то процентов на 10. Да, это база, хранящая документы и позиционирующаяся как документоориентированная СУБД, но в ней очень много от СУБД реляционной, то есть Mongo пытается прикинуться реляционным решением, каковым не является, и из-за этого внутри становится очень сложной; на больших данных она крайне сложна в эксплуатации. «Енисей» идеально заходит там, где MongoDB не использовали со всеми ее сложностями. От нас она очень сильно отличается и производительностью, и сложностью эксплуатации, и тем, что на ней нельзя сделать распределенные системы. И на больших данных она ведет себя не то, чтобы плохо, но требует высококвалифицированного персонала для обслуживания. MongoDB - очень капризная штука при увеличении нагрузки и объемах хранимых данных. Мы не такие. У «Енисея» есть функция хранения и обработки документов и нет SQL. Зато есть много других фич, например, REST API в качестве интерфейса и web-интерфейс. Есть представления (views), которые можно писать на JavaScript, Erlag, CoffeeScript и Elixir. Также с документами можно работать через HTTP-протокол, то есть разработчикам не нужно изучать специализированный язык и уровень входа в проект нулевой, любой разработчик справится. Все просто и эффективно.

«Енисей» хорош там, где нужно работать с JSON: хранить, процессить, предоставлять инструменты для обработки, а MongoDB в этом случае - просто из пушки по воробьям.

Oracle NoSQL мы заменяем отлично. Например, сейчас у нас идут переговоры о замене Oracle Berkeley DB в медицинских информационных системах, потому что мы отлично храним бинарные данные, в том числе в качестве аттачмента к JSON. В целом мы можем очень эффективно заменять Oracle NoSQL во многих кейсах.

— Контекст сравнения все еще не опускает. Можно ли считать Imagenarium полноценной заменой Docker Compose, Docker Swarm?

Docker Swarm оркестратор, не совсем замена. Мы используем его для развертывания в некоторых кейсах внутри Imagenarium. То есть он есть у нас в ядре, но эксплуатируется не на полную катушку. С Docker Compose нас вообще нельзя сравнивать. Мы похожи, потому что тоже автоматизируем деплоймент, но в Docker Compose нет ни кластеризации, ни отказоустойчивости, ни настройки сетей. Есть определенные схожие моменты, но Imagenarium - самостоятельный продукт, он предназначен для управления контурами решений, управления ЖЦ проектов от разработки до деплоймента в промышленной среде и эксплуатации. Косвенно можно сравнить Imagenarium с платформой на базе Kubernetes, потому что мы решаем похожие задачи: деплоймент, отказоустойчивость, контроль целостности кластера, оркестрация. Но все это не в рамках управления Enterprise-ресурсами предприятия, а в рамках контура продукта. Нас можно сравнить с Kubernetes, который ограничен контуром какого-то программного продукта, обслуживаемого Imagenarium. Так понятней.

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

— Что такое «Енисей», Imagenarium и Triodata? Самыми простыми словами?

— Triodata мы выстрадали из опыта создания больших систем в мире, где нет Oracle. Многие страны уже давно отказались от использования Oracle в государственных проектах. Если у вас нет таких дорогостоящих навороченных продуктов, как Oracle, а ваша система хранит большие объемы данных, требует быстрого времени отклика и обладает хорошим качеством масштабирования, у вас просто нет выхода. Postgres хороший продукт, но что-то очень интересное на нем можно построить только при наличии высококлассных специалистов, при этом вероятность мала, и лучше не соваться. Если бы с Postgres все было просто, никто бы не занимался той головной болью, которой занимаемся мы, и никто бы не покупал Oracle, у которого стоимость поддержки несколько миллионов в год на серьезных инсталляциях. На серьезных системах мигрировать на Postgres нельзя, и, если есть сомневающиеся, время покажет. Я думаю, уже в следующем году будет череда фэйлов. Мы так не делаем и стараемся в этом мире работать таким образом: ты приходишь, делаешь заказчику хорошую архитектуру и больше он тебя не тревожит. Потому что возвращаться каждый раз и ставить костыли в чужой системе — это дорого. Наш подход гарантирует, что любая высоконагруженная система, правильной архитектурой распределенная на три наших продукта (откуда и название Triodata, там еще и поисковый индекс), будет хранить петабайты данных, сохранять низкое время отклика, высокую производительность, будет легко масштабироваться, не будет доставлять эксплуатационных проблем заказчику. Это наша идеология. Она также используется и в «Честном знаке», но там в силу специфики данных в самых высоконагруженных узлах стоит не «Енисей», а Apache Cassandra, потому что больше подходит технически. Хотя принцип тот же, у нас есть NoSQL база, индексатор и реляционный движок, даже несколько движков в нужных местах. Это жизнеспособная и качественная связка, ее мы и продаем, плюс свою экспертизу. Мы уже сделали не один проект по миграциям. Обыкновенные поставщики Postgres миграцию не проведут: там очень много подводных камней, много шишек, и все они очень болезненные. Причем факапы случаются в самом финале. Есть и такие кейсы, которые вообще миграции не подлежат, например, когда все приложение - это Oracle. Мы много лет зарабатывали деньги на разработке ПО, поэтому используем инструменты, не доставляющие головной боли ни нам, ни нашим клиентам. Задача не в продаже лицензий, а в поставке тех технологий, с которыми люди к тебе потом не вернутся. Для нас сверхкритичен правильный подход, иначе бы мы не выжили. Поэтому мы и отшлифовали исходный CouchDB таким образом, чтобы убрать оттуда все то, что мешало нам оказывать правильный сервис.

Imagenarium та вещь, которая снимала с нас расходы. У нас не было DevOps-ов ни на одном проекте, DevOps-ов у нас в компании вообще не существует. Наши компоненты тоже эксплуатируются без услуг DevOps-ов, потому что это, по сути, лишнее звено, если есть Imagenarium.

— Надеюсь, DevOps-ы не обидятся, что с Imagenarium можно обойтись без них.

— Что поделать, это реальность. Imagenarium появился, чтобы обеспечить наших разработчиков инструментом самостоятельного деплоймента и локальной отладки и не зависеть от команды заказчика. Нет ни одного продукта в мире, который позволил бы взять сложную систему с 50 микро-сервисами, с кучей баз, развернуть ее на ноутбуке и позволить разработчику отлаживать свой код на ней. Imagenarium в этом смысле уникальная штука, но рынок ее пока не понимает. Лучше всего Imagenarium сейчас продается от разработчика к разработчику.

— Требуются ли интеграторам специальные технические компетенции и экспертиза, чтобы внедрять Imagenarium и «Енисей»?

— В этом-то весь прикол. Никакой экспертизы не требуется. С «Енисеем» может работать любой разработчик, потому что это обычный RESTful API протокол. Для освоения Imagenarium нужно два-три дня. Даже просто в разработке Imagenarium принесет увеличение эффективности команды минимум на 30 процентов. Увеличится отдача от коллектива разработчиков и тестировщиков, себестоимость эксплуатации устремится к нулю.

— «Енисей», как и Imagenarium, появился для решения конкретных задач?

— «Енисей» появился потому, что нам нужна была документная база. Все современные системы работают с форматом JSON, получают его и обрабатывают. Для этого нужна документоориентированная база. Мы взяли решение, максимально комфортное в эксплуатации. С MongoDB все сложно – там свой протокол, свои схемы взаимодействия. В «Енисее», напротив, все предельно просто. Когда в работе одновременно много проектов в разных фазах и люди часто мигрируют с одного проекта на другой, важно, чтобы с СУБД умел работать любой разработчик. Наши продукты, и «Енисей», и Imagenarium, появились как раз в таких условиях, появились для того, чтобы повысить эффективность, навести порядок и снизить накладные расходы в разработке, и отлично себя оправдали.

В части геоданных «Енисей» гораздо лучше Postgres. Альтернатива Oracle сейчас только Postgres – а мы лучше, потому что JSON — это наш нативный формат.

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

— Пожалуйста, расскажите про наиболее популярные сценарии использования продуктов Кайрос из текущей практики?

— По «Енисею» все просто. Распределенное файловое хранилище, система хранения геоданных, также распределенная, хранилище документов, причем с возможностью подключения средств визуализации данных. Кроме того, сейчас мы делаем «Енисей» LDAP, распределенную систему хранения данных LDAP. Тоже очень хороший проект, цель которого – замена active directory во многих кейсах. То есть мы мигрируем данные (связанные с уходом Microsoft). Причем у нас будет единственный действительно распределенный LDAP, который позволит правильно реплицировать данные по филиалам, фильтровать данные по репликации. Imagenarium – вещь, в которую можно упаковать любое сложное решение и продавать его в нашей упаковке, и внутри Imagenarium есть встроенный маркетплейс, при помощи которого можно очень быстро устанавливать различные программные продукты, покупать на них лицензии, система цифровой дистрибуции плюс удобная упаковка. Инсталлятор-упаковщик рынок сейчас хорошо понимает. Если у вас есть сложная система или коробочный продукт под Linux, мы превращаем его установку в очень простой процесс. Почти все российские решения под Linux непростые. И в этом кейсе Imagenarium планируется к установке как эдакий Appstore российского ПО.

— А можно полноценно заменить active directory?

— Да, мы сейчас разрабатываем инструментарий. Он сможет. Там будут хорошие миграционные инструменты и распределенная инфраструктура за счет «Енисея».

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

— Людям, которые используют наши продукты, они нравятся. По заменам все пока в пресейлах. И очень хорошие перспективы с Triodata как слоем хранения данных для 1С. 1С на Postgres – это бесперспективно, и заказчики это понимают. Сейчас мы ищем партнера, чтобы прикрутить Triodata к 1С, потому что на такой функционал стоит очередь.

— Дмитрий, так как мы уже обсудили планы Кайрос Digital на будущее, дежурный вопрос в заключение задавать не будем. От лица компании ОЛЛИ ИТ, дистрибьютора с тридцатилетней историей на рынке, хотим отметить, что очень рады появлению продуктов Кайрос в нашем продуктовом портфеле. Наша задача – предлагать партнерам и заказчикам рабочий пакет отечественных решений, а не продукты импортозамещения «для галочки». Уверены, что совместными усилиями нам удастся донести до рынка, насколько мощные продукты «Енисей», Imagenarium и Triodata.

— Спасибо! Мы тоже в свою очередь надеемся на это. Также мы продолжаем работать над улучшением наших продуктов и внедрением нового функционала, поэтому нам определённо есть что предложить нашим клиентам.

Интервью: пресс-служба ЗАО «ОЛЛИ ИТ»
marketing@ollyit.ru