Инфраструктура для работы с данными и собственные open source разработки в стране — одни из наиболее актуальных тем для российских организаций и ИТ-специалистов.
Сегодня затрагиваю сразу обе в формате интервью: поделиться личным опытом согласился Александр Ермаков, сооснователь и CTO Arenadata. Также мы обсудили тренд на коммерциализацию open source решений, проблемы с лицензиями в мире и российский опыт, взаимодействие с сообществом и многое другое.
@dmitrykabanov: На Хабре я встречал информацию о том, что команда Arenadata сложилась в рамках 2014-2017 годов, а ядро составили пять человек. Так ли это? Как вы подошли к запуску? Потребовались ли сторонние средства?
@aermakov: У нас было несколько ключевых этапов по ходу формирования команды и становления компании. Начали, конечно же, с идеи. Она появилась в конце 2014 года и заключалась в разработке платформы на основе open source стека, которая могла бы дать заказчикам возможность решать различные задачи обработки данных с минимальными затратами на поддержку и эксплуатацию. Технологий на рынке на тот момент было предостаточно, однако истории с готовыми «коробочными» решениями для использования в enterprise-формате были редкостью.
На старте нас было двое — Сергей Золотарев (сооснователь и директор по стратегическому развитию Arenadata — прим.) и я. Мы достаточно рано начали сотрудничать с энтузиастами в нише open source. Это были участники Apache Software Foundation, а также те, кто занимались различными проектами в Linux Foundation. Мы сформировали костяк команды к 2017-му. И, да, на тот момент в него вошли пять человек, включая меня и Сергея. Кстати, эти люди все еще остаются частью команды.
До 2017-го мы фактически работали в формате стартапа с фокусом на некоммерческих проектах, технологической разработке, участвовали в создании open source проектов. Постепенно у нас появились люди, которые были больше ориентированы на становление компании. Мы поняли, что необходима серьезная инфраструктура, которая будет обеспечивать весь производственный цикл: от разработки до документации.
Чтобы развиваться в формате компании, нам также было требовалось плечо с точки зрения инвестиций и поддержки идеи в целом. В итоге мы присоединились к одному из крупнейших российских интеграторов, и на первых порах фактически были его инвест-проектом. В таком формате работали над формированием бизнес-модели, выстраивали процессы, разработку и инфраструктуру. Однако уже тогда отстраивались в духе полноценной и самодостаточной компании.
Как выглядела конкурентная среда? Занимался ли кто-то чем-то подобным в России? Какие преимущества вашей бизнес-модели на этапе запуска вы могли бы выделить?
На старте на российском рынке у нас не было большого числа конкурентов. Стоит отметить Postgres Professional — у них был похожий подход к работе: глубокая интеграция в open source сообщество и коммерциализация за счет enterprise-функциональности и поддержки. Также были технологические гиганты вроде Яндекса. Последний вкладывал (и вкладывает) существенные ресурсы в технологии и сервисы по обработке данных.
Тогда облака у нас были слабо развиты, и мы хотели сделать полноценную платформу, которую можно было бы использовать on premise. Наше предложение представляло собой нечто среднее между классическими тяжеловесными enterprise-решениями для обработки данных и легкими управляемыми сервисами, которые распространялись в облаках. При этом мы оказывали полноценную поддержку, давали возможность гибкой конфигурации и развертывания, а также предоставляли инструменты управления по аналогии с теми, что предлагали облачные платформы.
Этот подход помог нам (и все еще помогает) конкурировать с другими вендорами за счет отличающейся бизнес-модели. Мы придерживались его еще на старте, плюс — ориентировались не только на российский рынок, а смотрели шире, и уже тогда у нас были зарубежные заказчики.
Кстати, здесь можно сказать и об истории первого продукта — дистрибутива Hadoop, который появился у нас еще в ходе работы в некоммерческом формате. В то время у нас уже были достаточно плотные связи с несколькими людьми из Apache Software Foundation и Linux Foundation, которые предложили присоединиться к новому некоммерческому проекту. Он получил название Open Data Platform Initiative (ODPi) и был создан для того, чтобы помочь крупным компаниям работать с широким спектром дистрибутивов от различных поставщиков. Для этого мы — совместно с ребятами из Apache, IBM и Hortonworks — разработали единую спецификацию сборки дистрибутива Hadoop.
На ее базе мы сразу же сделали ванильную сборку Hadoop, которая стала одной из первых ODPi Runtime Compliant. Уже после этого аналогичный статус получили Hortonworks, IBM и Pivotal. За счет того, что мы были в числе первых в этой истории, и продукт получился достаточно зрелым, а также пошло технологическое взаимодействие Hortonworks и Pivotal в рамках единой инициативы, мы стали заметными на международном рынке. Когда перешли к коммерциализации разработок, буквально в рамках года мы сразу же начали работу с заказчиками, которые начали использовать наш первый продукт — дистрибутив Arenadata Hadoop. Он все еще востребован, и мы существенным образом модернизировали его.
И, да, стоит сказать, что в качестве инфраструктуры для ODPi был выбран проект Apache Bigtop, в который также мы активно контрибьютили. На его базе была реализована вся необходимая машинерия для сборки, патчинга и тестирования. Кстати, сейчас его используют некоторые крупные российские компании, пытающиеся создавать свои дистрибутивы Hadoop, хотя мы уже далеко ушли от него и используем свои инфраструктуру и машинерию.
Мы не планировали ограничиваться одной технологией, поэтому вошли в еще один open source проект — Greenplum. Его история — как альтернативы технологии Teradata — также достаточно интересна. Greenplum создавался как ответ Teradata, но только как software-defined решение, когда можно было взять практически любое оборудование и развернуть MPP shared-nothing базу данных (массивно-параллельную обработку без разделения ресурсов). На тот момент в мире эта концепция была одной из наиболее популярных для создания аналитических хранилищ данных.
Greenplum прошел путь проприетарной разработки внутри американской корпорации EMC. Также его развивали в Pivotal, когда компания выделилась как spin off из корпорации EMC, а позже его открыли в качестве open source проекта. В этот момент мы вошли в проект в роли полноправного члена, получили статус контрибьютера, сделали интересные для сообщества Greenplum вещи, а позже — начали предлагать его как второй продукт в своей платформе (Arenadata DB).
Чуть позже у нас появились другие технологии в нашем стеке. Например, в формате отдельного продукта — Arenadata Streaming — были выделены проекты Kafka и NiFi, которые изначально поставлялись в качестве компонентов дистрибутива. Сейчас они используются как совместно с другими продуктами, так и отдельно в качестве полноценных решений. Так, мы постепенно наращивали продуктовый портфель, экспертизу в выбранных технологиях, возможности решать различные задачи с точки зрения их использования и совершенствования платформы.
Кстати, по аналогичной схеме — от контрибьютерской активности, опыта разработки и поддержки на уровня кода и ядра технологии до добавления в состав собственного решения и платформы — мы развиваем ClickHouse.
Могли бы вы, пожалуйста, чуть подробнее рассказать как о коммерциализации, так и о взаимодействии с open source сообществом?
Как и многие другие вендоры, в том числе западные, мы предоставляем профессиональные сервисы для наших продуктов, которые разрабатываем и совершенствуем. Например, речь идет о технической поддержке, консалтинговых проектах. Хотя у нас есть возможность выделения собственных специалистов, мы также участвуем в партнерских проектах в роли своеобразного архитектурного надзора.
Если говорить про продуктовую разработку, нам потребовалось большое количество времени, чтобы выстроить необходимое процессы. С 2017-го по 2021-й мы находились в постоянном структурировании и внедрении различных процессов, формирования команды и культуры. Это касалось как внутренних моментов и инфраструктуры, связанных с управлением roadmap’ами и задачами, так и работы с open source.
Дело в том, что существенную часть того, что мы делаем, мы отдаем в upstream, и это требует серьезных инвестиций с точки зрения подходов к разработке, определенных навыков людей, которые занимаются этими проектами. Для того, чтобы изменения принимали в сообществе, нужно играть по определенным правилам: как с точки зрения описания изменений, так и реализации решения, подхода к обсуждению изменений, также в ряде случаев — тестирования того функционала, который идет для open source.
Есть ли определённая разница в потребностях российских и зарубежных заказчиков, которую вы могли бы отметить, допустим, на основе консалтинговой деятельности? Влияют ли такие различия на бизнес-модель?
Глобальных изменений бизнес-модели нет, однако стоит отметить один заметный нюанс. С уходом зарубежных вендоров с российского рынка начали появляться дополнительные требования и особенности, которые накалывают свой отпечаток на бизнес-модель, подходы к разработке и сами продукты компании. Ранее enterprise-клиенты работали с экосистемами продуктов западных вендоров, которые достаточно хорошо дружили друг с другом. Также и мы ориентировались на взаимодействие с широким спектром технологических решений, например, с условными BI-системами, решениями для загрузки и обработки данных, операционными системами и так далее.
Конечно же, сейчас — с учетом ограничений и перехода на иные продукты — у многих заказчиков возникают вопросы, как же сделать так, чтобы после миграции на отечественные решения их инфраструктура работала не менее эффективно. Такие особенности влияют на договорные вопросы, связанные с использованием тех или иных технологий, технические отношения между вендорами и консалтинговые проекты.
Требования регуляторов также оказывают влияние, причем я бы не сказал, что в плохом ключе. Когда мы говорим об использовании технологии в критически значимой инфраструктуре, конечно же, она должна проходить необходимые проверки. В нашей стране это — сертификация ФСТЭК. Одна из наших ключевых задач — решить вопросы, связанные с сертификацией по всем технологиям, с которыми мы работаем. Это влечет изменение подхода к реализации и набора компетенций по части многих прикладных вещей, хотя и не core-разработки продуктов.
Могли бы вы прокомментировать последние события вокруг HashiCorp и перевод существенной части продуктов компании из open source в source available? Ставите ли вы эту ситуацию в один ряд с кейсом Elastic?
Здесь ситуация следующая. Рынок продолжает работать так, как он работал с точки зрения open source. Однако есть определенный тренд у компаний, которые драйвят и монетизируют ключевые технологии, вроде Elastic, HashiCorp, Confluent, а также MongoDB, которая была одной из первых в волне со сменой лицензий.
История на самом деле простая: сторонние компании, которые прикладывали минимум усилий с точки зрения развития технологий получили достаточно широкие возможности заработка за счет использования доступных open source версий. При этом далеко не все из таких пользователей — зачастую крупных cloud-провайдеров — оказались способны наладить собственную контрибьютерскую активность и по возможности отдавать доработки в open source. Кто-то не смог сделать это, исходя из юридических ограничений, другие — в силу отсутствия правильного подхода к такой разработке. Хотя некоторые компании-разработчики, о которых мы говорили выше, еще до смены лицензии применяли copyleft-подход, все-таки предполагающий контрибьютерство.
Теперь они меняют условия лицензирования, и на рынке появляется не просто «слабый» и «сильный» copyleft, а уже так называемые «экстремальные» copyleft-лицензии вроде SSPL, которые подразумевают открытие всего, что касается производного проекта, в том числе компонентов управления, API и фронтэнда.
Конечно, для крупных компаний такой подход является недопустимым, поэтому идет некоторое столкновение миров и интересов — облачных платформ и разработчиков open source решений. В итоге ключевые ограничения на использование в таких случаях относятся к managed-service-реализациям.
Кстати, у нас есть собственные партнерские реализации с крупными cloud-провайдерами в стране, и для подобных кейсов мы не предоставляем функционал компонентов, лицензии на которые не позволяют это делать в формате управляемых сервисов. К слову, в основном мы ориентированы на работу с permissive-лицензиями вроде ASF 2.0, что дает нам необходимую гибкость с точки зрения того, что мы отдаем или не отдаем в open source, а также того, как мы можем коммерциализировать собственные разработки.
Для нас этот момент важен в особенности сейчас, когда все чаще появляются компании, которые делают собственные сборки на основе переупаковки исходника с минимальной доработкой со своей стороны. Хотя в некоторых случаях новые игроки в нише действительно помогают развивать open source. Например, мы вместе с рядом таких компаний входим в число контрибьютеров Greenplum. В этом случае мы являемся первыми в мире независимыми контрибьютерами по объему внесенных изменений — обходим крупные международные корпорации вроде китайской Alibaba. Также, если говорить о ClickHouse, сейчас мы наращиваем присутствие в проекте и вносим достаточно серьезные изменения в open source.
Отслеживаете ли вы подобные изменения лицензий? Актуальны ли такие изменения и вопросы в какой-либо степени для ваших разработок? Как я понимаю, у вас есть два вида лицензий (community и enterprise). Могли бы вы рассказать, как вы подошли к формированию их условий? Отталкивались ли от какого-либо примера или готовили текст самостоятельно с нуля?
В целом мы преимущественно работаем с ASF-проектами, поэтому в том числе можем менять тип лицензии сами — на стороне Arenadata — и делать это таким образом, чтобы наши лицензии (community и enterprise) отражали требования и специфику работы с продуктами компании. Кстати, в целом ASF в некоторой степени допускает возможность использования слабых copyleft-лицензий. Однако уже с обычным copyleft’ом могут быть проблемы, если вы выводите что-то в open source. Такие моменты мы отслеживаем с точки зрения требований ASF. Также нас интересуют аспекты, связанные с безопасностью тех или иных компонентов, которые мы задействуем.
Если говорить подробнее о наших лицензиях, мы подходили к их подготовке самостоятельно, но с привлечением профессионалов, которые занимались лицензированием исходного кода и программных продуктов. Задача здесь была в том, чтобы обезопасить свою интеллектуальную собственность и наработки компании.
Если говорить простыми словами, то enterprise-версию можно использовать при наличии договорных отношений между нами и заказчиком, а community-версия не имеет такого ограничения. Также есть определенные ограничения по модификациями и повторному использованию в тех или иных целях, например, примитивная переупаковка нашего кода в свой продукт будет нарушением условий лицензии. В целом community версия позволяет получить представление о наших продуктах. Однако после изучения решений посредством таких лицензий, наши заказчики переходят на enterprise-лицензии.
В вашем лицензионном соглашении есть условие о том, что оно предусматривает установку и запуск решения на операционных системах CentOS и RedHat, а также оборудовании с архитектурой процессоров x86-64. При этом другие юзкейсы требуют вашего письменного согласования (п.4.2.8). Могли бы вы пояснить, какие предпосылки привели к вводу такого условия?
Это — информационный акцент, который необходим с точки зрения нашей уверенности в возможности технологической поддержки решений. На момент составления лицензии указанные операционные системы составляли почти 100% от всей install base, поэтому этот пункт присутствует именно в таком виде. Однако в скором времени мы будем менять его. Причин несколько.
Во-первых, в России появился ряд операционных систем со своей спецификой. Во-вторых, CentOS прекращает существование в формате свободно распространяемой production-ready-системы в июне этого года, поэтому мы ведем работу по переходу на Debian-ориентированные системы. У нас уже есть поддержка Astra Linux, AltLinux, поэтому этот пункт лицензии постепенно теряет актуальность с точки зрения операционных систем. Однако по архитектуре — все в силе, и альтернатив в production-средах нет.
Могли бы вы простыми словами чуть подробнее объяснить, как организация-пользователь может понять разницу между двумя типами лицензий у вас? Есть ли определенные рекомендации по инфраструктуре, составу команды инженеров на стороне пользователя, а также необходимых компетенций?
Удобнее всего отталкиваться от необходимого функционала. Например, если кому-то нужны определенные механизмы безопасности, углубленного мониторинга и так далее, то это — про enterprise-версию. Также сюда стоит добавить потребность в поддержке с заданным уровнем качества, потому что community не предполагает полноценной многоуровневой поддержки с нашей стороны, хотя мы, конечно же, отдаем в community все исправления для enterprise-версии. Нужный функционал и поддержка — два ключевых фактора, которые влияют на выбор пользователями той или иной версии.
К инфраструктуре есть требования (пример), все они отмечены в открытой документации, что по нашему мнению является важным моментом для компании, ориентированной на open source. В том числе у нас описаны enterprise-фичи, поэтому возможно посмотреть, как именно все это работает и архитектурно выглядит. Также указаны пререквизиты по инфраструктуре и окружению. Относительно навыков и компетенций — у нас есть базовые рекомендации по обслуживанию систем на стороне заказчика и учебный центр с курсами для различных технических ролей. Мы рекомендуем проходить обучение до выхода на эксплуатацию таких систем. Но если говорить простыми словами, пользователям потребуются люди не только с пониманием того, как работать с подобными технологиями, но и люди по части инфраструктуры для грамотной развертки таких систем.
Как сейчас у вас идет сотрудничество с международными структурами? Продолжаете ли вы взаимодействие, есть ли заметные изменения?
История с Linux Foundation и ODPi продлилась около пары лет и завершилась еще до начала известных событий. Мы пошли в несколько иную сторону с точки зрения видения дальнейшего развития. В остальном — с точки зрения сообщества — не сказал бы, что ситуация изменилась. Мы продолжаем участвовать в проектах, где присутствовали. Например, с ClickHouse все движется семимильными шагами. Скорее все усложняется на нашей стороне за счет внутренних факторов, которые мы должны учитывать. Среди них — вероятность ограничения доступа к GitHub и тому подобные моменты.
Поэтому основная часть кода сейчас разрабатывается у нас внутри. Также мы очень серьезно относимся к работе с зависимостями, чтобы обеспечить гарантированный и безопасный цикл сборки. Дело в том, что известны многочисленные случаи, когда преднамеренно вносились закладки и уязвимости в различные решения с прицелом на их использование для российского сегмента. Такие моменты мы отслеживаем и реализуем ряд вещей, которые должны обезопасить и нас, и заказчиков. Также эти аспекты необходимо закрывать с точки зрения сертификации, исправлять самые различные уязвимости, в том числе небезопасный код, смотреть на политики управления доступами и так далее. Подобными вопросами мы занимаемся практически со старта, а также выделили у себя отдельное направление по безопасной разработке.
Если говорить о сотрудничестве с облачными провайдерами, я видел новость по MCS и не так давно по КРОК? Как вы пришли к такому формату? Могли бы вы также поделиться планами по развитию платформы?
Сейчас меняются инфраструктурные подходы к работе, также влияет интенсивность транзакционной нагрузки тех или иных систем. В целом мы пошли по пути адаптации технологий к облачной инфраструктуре, хотя изначально они были разработаны не под облако. Сейчас у нас есть партнерские отношения с большинством российских облачных провайдеров. Причем есть реализации, которые являются полноценными управляемыми сервисами, а есть реализации в формате PaaS-сервисов. В целом это — облачная дистрибуция наших продуктов в private-cloud-среде с определенными нюансами, потому что не каждая облачная среда может воспроизвести нужные условия.
Также мы следим за лицензированием — следуем всем правилам и международным требованиям по части авторских прав и лицензий. В этом плане в облаке доступны только те решения и компоненты, которые изначально распространяются по permissive-лицензиям. Если говорить о развитии, то это — дальнейший переход от bare metal в облако с существенной ставкой на производительность и безопасность технологий. Мы видим примеры на западном рынке, когда за несколько лет ключевые позиции заняли игроки вроде Databricks и другие. У нас подобные явления могут произойти в ближайшее время. Мы будем не только адаптировать существующие, но и развивать новые технологии, которые будут как дополнять, так и заменять уже имеющиеся у нас разработки.
Как вы считаете, в чем преимущество Hadoop HDFS в отличии от Spark on K8S с S3-like хранилищем? Был ли у вас опыт использования других инструментов в том числе Trino, PrestoDB, Delta Lake?
Здесь есть ряд вопросов по безопасности и задачам, которые просто не реализованы в такой архитектуре. У нас есть определенные наработки относительно того, как это можно закрыть. Также есть вопросы к производительности: здесь bare metal будет эффективнее динамического масштабирования в Kubernetes-кластере, плюс — могут быть использованы различные кешевые уровни для хранения данных. Если говорить про Trino, то он является эволюционным шагом от PrestoDB с точки зрения формирования самой команды, но в целом это — немного иной продукт. Trino — это распределённый SQL с функцией computing’а, но с точки зрения кейса использования Hadoop или Greenplum он решает несколько иную задачу — построения федеративного хранилища, у нас же есть задача построения высокопроизводительного конвейера, который работает по определенной логике с точки зрения трансформации и жизненного цикла данных. К PrestoDB также есть вопросы с точки зрения производительности.
Планируете ли вы какие-либо тематические митапы или вебинары, к которым могла бы присоединиться аудитория Хабра? Есть ли подобные планы?
Да, у нас есть в планах такие активности, но если у сообщества есть определенные предложения или вопросы, будем рады оттолкнуться от них.
