В этой статье отвечаем на главные вопросы, касающиеся импортозамещения западного ПО. Можно ли верить матрицам, которые составляют отечественные производители? Насколько заявленные аналоги отвечают потребностям рынка? Смогут ли «облака» стать универсальным решением проблемы с оборудованием и с какими сложностями сталкиваются заказчики в проектах миграции? Об этом и не только Cnews поговорил с директором по стратегическому развитию Arenadata Сергеем Золотарёвым.
Arenadata начала заниматься созданием отечественных СУБД, которые могут конкурировать с западными аналогами, задолго до того, как импортозамещение стало необходимостью. На сегодняшний день у Arenadata есть портфель зрелых, проверенных на практике продуктов и отработанная методика миграции с западного ПО, которой компания открыто делится с рынком.
— Как сегодня происходит процесс импортозамещения ИТ-продуктов в российских компаниях? Какие тренды Вы бы здесь выделили?
Сергей: Первое, что я бы отметил, — это противоречивость в отношении к тому, что произошло. Одни заказчики в экстренном порядке пытаются что-то делать, а другие, напротив, очень расслаблены и ничего не планируют. Они словно не верят, что всё это всерьёз и надолго. Кто-то, например, не устанавливает обновления, чтобы случайно не занести вредоносный код, пытаясь таким образом «законсервировать» систему. На мой взгляд, это нормальный шаг, если он часть стратегии «стабилизация текущей инсталляции — изучение вариантов — миграция». Однако создаётся впечатление, что некоторые компании так не мыслят и пытаются просто переждать «тяжёлые времена».
Второй тренд, достаточно позитивный, состоит в том, что существенно увеличился круг заказчиков, у которых изменилось отношение к российским продуктам в положительную сторону. Отрадно, что про импортозамещение стали не просто говорить, но и реально им заниматься.
Третий тренд — новая роль облачных решений, повышенное внимание к ним. Если раньше они рассматривались как более удобная и экономичная замена bare metal, то теперь —, как принципиальная альтернатива «железу», с импортозамещением которого сейчас всё особенно сложно.
— Насколько облачные платформы могут заменить «железо» без потери качества и производительности?
Сергей: В каких-то проектах — вполне могут, где-то — пока нет. Есть свои нюансы. Облачные платформы очень гибкие и дают заказчикам возможность быстро получить необходимые вычислительные ресурсы. Это особенно актуально для организаций, которые обращаются к анализу данных эпизодически. В целом, как показывает опыт cloud-провайдеров, «облака» могут снижать показатели Time to Market и ТСО за счёт экономии на ресурсах. Для кого-то в текущих условиях облачные продукты могут стать единственной возможностью получить необходимые вычислительные ресурсы по разумной цене и в адекватные сроки.
Обратная сторона состоит в том, что не всем организациям это подходит — как с точки зрения решаемых задач, так и с точки зрения требований по безопасности. Ну и ещё нужно понимать, что не все провайдеры пока могут предоставлять услуги на одинаковом уровне.
— Вы сказали, что отношение к российским продуктам меняется. Это происходило постепенно или связано с последними событиями?
Сергей: Массовый уход западных компаний, конечно, сильно подстегнул интерес ко всему российскому, однако ради исторической справедливости надо отметить, что тренд на «потепление» в отношении к отечественным программным продуктам наметился ещё 3–4 года назад.
ИТ-решения, которые выходили на рынок не с целью импортозамещения, а в условиях конкуренции с мировыми вендорами, доказали свою жизнеспособность и стали пользоваться заслуженным доверием. Реализовано уже достаточно много проектов с участием российских продуктов. Первые заказчики отечественного ПО сейчас много рассказывают об этих внедрениях на отраслевых конференциях. Благодаря выбору, сделанному несколько лет назад, сейчас они оказались в выигрыше и теперь охотно делятся своим опытом.
— С какими проблемами сталкиваются заказчики при миграции с западного ПО? Как обеспечить переход с наименьшими потерями?
Сергей: Одной из первоочередных задач для заказчиков обычно является сохранение прикладных наработок, созданных в рамках эксплуатации старых решений. Эти наработки нужно адаптировать так, чтобы можно было их использовать после миграции. Конкретно речь идёт об изменении кода СУБД, кода ETL- и ELT-процессов, а также кода приложений. По нашему опыту, решение этой задачи занимает самую значимую часть времени.
Второй важный момент — выбор сценария миграции. В нашем случае их, как правило, два: полная миграция на новую систему или частичная разгрузка существующих инженерных систем. Первый вариант миграции осуществляется, когда бизнес-приложение полностью переносится из одной системы в другую. В подавляющем большинстве случаев миграция такого типа выполняется для OLAP-задач. Второй вариант, с частичной разгрузкой системы, позволяет разделить транзакционные и аналитические контуры и, например, вывести на новую СУБД всё, что относится к аналитике, а на прежних ресурсах оставить всё, что предназначено для работы с OLTP-нагрузкой.
Конечно, отдельная проблема — вопрос с оборудованием. В нашей практике мы встречали разные подходы к решению этого вопроса, включая какие-то варианты оптимизации имеющихся ресурсов с целью их переиспользования.
Для того чтобы обеспечить переход с наименьшими потерями, на старте важно правильно составить ресурсный план, определиться с возможными трудозатратами, проанализировать, есть ли необходимые компетенции у команды. Что касается расчёта трудозатрат: по нашему опыту, перенос кода занимает обычно до 80% от общего времени проекта. Кроме этой работы, нужно заложить время на вендорский или архитектурный контроль, настройку информационной безопасности, адаптацию регламентной документации, обучение персонала и пусконаладочные работы. Мы достаточно подробно описали это в своих рекомендациях по миграции с западных СУБД.
— Сейчас многие производители составляют матрицы замещения иностранных продуктов. Насколько это корректно и можно ли говорить о стопроцентном замещении?
Сергей: Чаще всего речь идёт именно о частичном замещении какого-то значимого функционала. И это нормально, поскольку в большинстве случаев нет смысла разрабатывать стопроцентный аналог решению, выпущенному несколько лет назад. Технологии развиваются, и какие-то продукты нужно делать уже по-другому. В контексте разработки программного обеспечения, мне кажется, вообще уместнее говорить об импортоопережении, чтобы создавать не аналоги, а новые конкурентоспособные продукты. В том числе на это сейчас направлены меры государственной поддержки — помочь отечественным производителям доработать свои продукты до такого состояния.
Тем не менее практически полные аналоги тоже есть, и в нашем стеке в том числе. В своей практике при миграции с Oracle, Vertica, Cloudera или Teradata мы предлагаем решение в зависимости от преимущественного профиля нагрузки. В каких-то случаях можно систему заместить полностью, в каких-то — только частично, встречаются кейсы, по которым на текущий момент нет очевидного технического решения.
— Насколько в такой ситуации важна «зрелость» продукта?
Сергей: Когда альтернативы нет, неважна. Но если она есть, думаю, заказчикам было бы обидно платить за «изобретение велосипеда». Сейчас вся сложность состоит в том, чтобы подходящее решение найти.
И здесь, кроме оценки функционала, я могу порекомендовать обратить внимание ещё на предпосылки и время создания продукта, опыт эксплуатации в похожих проектах и на наличие партнёров со специализацией в вашей отрасли.
О предпосылках создания я упомянул потому, что невозможно сделать что-то высокотехнологичное по щелчку пальцев. Хорошо, если решение изначально рождено в условиях развитой конкуренции. В этом случае оно явно сделано не впопыхах и с ориентиром на высокие стандарты.
Когда продукт сложный и связан с новыми технологиями, важно, чтобы была выстроена система передачи знаний о нём. Ведь самое зрелое решение не является «универсальным лекарством» само по себе. Оно будет эффективно работать в сочетании с экспертизой профильных специалистов, которых кто-то должен подготовить и желательно в максимально короткий срок.
— А что насчёт технологий Open Source, насколько они могут быть альтернативой западному ПО?
Сергей: Технологии Open Source — это ингредиенты, как мука, сахар, молоко и яйца. Сможешь ли ты приготовить из этого торт, зависит от того, есть ли у тебя правильный рецепт и подходящий навык. Отвечая на ваш вопрос: да, могут, но прежде, чем начать с ними работать, нужно адекватно оценить свои ресурсы.
СПО привлекает тем, что даёт возможность сравнительно быстро и дёшево попробовать новую технологию, но работа с ним требует очень глубокой экспертизы и сейчас особенно. Придётся очень многое изучить. Команды с определённой специализацией в какой-то технологии формируются годами.
Свежий пример из нашей практики. У нас большой опыт работы со свободным программным обеспечением, поскольку Arenadata одной из первых в России выбрала модель на базе его коммерциализации. Один из наших центральных продуктов — массивно-параллельная СУБД Arenadata DB — построен на базе проекта Greenplum, а тот, в свою очередь, базируется на PostgreSQL. Мы много занимаемся его развитием и по количеству коммитов даже стали вторым контрибьютором в мире.
И несмотря на то, что мы уже несколько лет вносим в проект множество доработок, в том числе на уровне ядра PostgreSQL, взяться за работу над собственным коммерческим продуктом на базе PostgreSQL решили только в прошлом году. Тогда, когда стало понятно, что у нас сформировалась отдельная команда с глубокой экспертизой и пониманием этого продукта.
— В чём заключается вклад вендора коммерческого продукта в доработку исходного Open Source проекта?
Сергей: Если кратко, хорошие корпоративные продукты (во всяком случае мы ориентированы на это) — это зрелые и полностью готовые к работе решения со своим функционалом, который не является полным аналогом открытого проекта. Конечно, в базе у них возможности конкретной технологии, но далеко не только они. «Готовые к работе» означает, что в них включены стабильные проверенные версии, все компоненты совместимы между собой, протестированы и проверены на наличие вредоносных «закладок», что сейчас особенно важно. Вендор коммерческого продукта гарантирует то, чего не может гарантировать сообщество — адекватную задаче работоспособность и безопасность кода.
Привнесённый вендором функционал в нашем случае включает оптимизацию каких-то функций, исправление ошибок и, разумеется, разработку нового функционала, который временно или никогда не будет доступен в исходном проекте. Например, мы разрабатываем масштабируемые коннекторы для совместимости решений друг с другом, обеспечиваем интеграцию продукта с нашей системой мониторинга, модулем для управления политиками безопасности, универсальным оркестратором, который гарантирует упрощённую установку продукта, миграцию на новые версии, загрузку обновлений и не только.
Кроме того, вендор коммерческой версии занимается поддержкой и развитием своих продуктов. У нас, например, есть понятный Roadmap для каждого продукта, на который могут влиять заказчики.
Тестирование нашего ПО, а также планирование и реализацию проектов с его участием можно проводить с привлечением наших специалистов. Это очень экономит время на поиск необходимых ресурсов при работе с малознакомыми технологиями. Кроме того, у нас есть курсы, где можно достаточно быстро освоить наиболее важные аспекты работы с нашими продуктами.
Ну и последний нюанс (не по важности, конечно): удобно, когда новые продукты обеспечены понятной документацией, есть полноценная техническая поддержка, возможность протестировать продукт до приобретения лицензии и пул проверенных системных интеграторов, которые умеют эти продукты хорошо внедрять.
— Что касается сферы информационной безопасности: в связи с последними событиями что-то изменилось в вашей работе или в планах развитие продуктов?
Сергей: Да, разумеется. В работе с исходным кодом Open Source проектов мы начали тщательнее проверять код на уязвимости, проводить дополнительные тестирования.
В целом мы уже пару лет целенаправленно развиваем стек продуктов, направленных на работу с информационной безопасностью. В частности, добавили Kerberos-авторизацию для наших продуктов, сделали свой компонент для обеспечения централизованного управления политиками безопасности кластера. В контексте изменения Roadmap мы начали переговоры с некоторыми российскими производителями ПО для обеспечения информационной безопасности о создании общих решений.
— Коснулась ли проблема импортозамещения вас как компании, которой самой пришлось что-то замещать?
Сергей: Конечно. У нас был целый стек для разработки из числа популярных западных сервисов, от которого пришлось отказаться. И мы себе даже не мыслили, что можем работать на чём-то другом, если честно. В частности, я говорю о GitHub, Jira, Slack, Confluence и не только. В течение трёх месяцев мы «переехали» на свободно распространяемое ПО или российские решения. В числе новых инструментов используем Yandex 360, GitLab, Mattermost, SimpleOne и BookStack. Кстати, своим опытом переезда мы поделились в своём блоге на «Хабре». Сначала казалось, что это будет коллапс, мы потеряем темп разработки, эффективность, но на выходе получилось достаточно быстро мигрировать весь процесс и адаптироваться к новому инструментарию.
— Как Вы оцениваете меры государственной поддержки ИТ-отрасли, которые дополнительно были приняты в этом году? Достаточно ли этого ИТ-производителям или нужны ещё какие-то изменения?
Сергей: С одной стороны гранты, налоговые и социальные льготы — это огромная помощь. И с точки зрения оптимизации затрат, и с точки зрения привлечения хороших специалистов. Очень радует, что финансовая поддержка выделяется в первую очередь не на гипотетические проекты, а адресно, производителям, у которых есть реальные продукты для решения конкретной проблемы заказчика.
С другой стороны, есть то, что настораживает. Многие крупные организации, в том числе с государственным участием, на волне импортозамещения и в погоне за льготами пытаются сейчас «поиграть» в ИТ-производителей. Они выводят на рынок решения, которые были или скопированы у других российских вендоров, или изначально созданы для внутреннего использования. Фактически эти компании берут готовые бизнес- и продуктовые идеи и пытаются делать свой аналог за деньги государства. Я считаю, что это очень нездоровая ситуация.
Во-первых, потому что сомнителен сам результат такой работы. Адаптировать внутренний продукт и изначально делать конкурентоспособный продукт — это далеко не одно и то же. В каждом деле есть своя специфика. Мне кажется нецелесообразным выделять финансирование на такие проекты.
Во-вторых, такой порядок вещей нарушает принципы честной рыночной конкуренции. Получается, что молодые перспективные компании одновременно и поддерживают, и создают барьеры для них. Гранты — это хорошо, но как потом конкурировать с крупной структурой с неограниченным бюджетом и неограниченными трудовыми ресурсами?
Поддержка на государственном уровне продуктов, жизнеспособность которых определил сам рынок, позволит им в сжатые сроки превратиться в полнофункциональное конкурентоспособное ПО.
Специалисты Arenadata и сертифицированные партнёры компании имеют релевантный опыт миграции с иностранного ПО. Оставить заявку на бесплатную консультацию по вопросам миграции с западных СУБД можно заполнив форму обратной связи здесь.