Распечатать

Замещение импорта в сфере инфраструктурного ПО: риски, проблемы и алгоритмы решений

Connect WIT 2017 №5-6

27 июня 2017

27 июня 2017

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

Юрий Кузьменко, руководитель отдела исследований и разработки «Энвижн Груп», отвечает на вопросы заочного круглого стола.

- Некоторые эксперты сегодня критикуют Реестр отечественного ПО, указывая, в частности, на тот факт, что большинство продуктов, внесенных в список, можно использовать только на Windows и с базами данных SQL и Oracle. Насколько обоснована такая критика?

И да, и нет. С одной стороны, в России широко распространена система Windows. Именно эта система используется как основная на большинстве государственных и коммерческих предприятий. По этой причине большая часть ПО разрабатывалась под эту систему. С другой стороны, в Реестре также представлено и кроссплатформенное ПО, что в последнее время является трендом.

По поводу баз данных можно сказать, что часть ПО использует ORM и, как следствие, может работать с базами данных, отличными от Oracle и MS SQL. В Реестре, кстати, представлена Postgres Pro, российская ветка популярной базы данных PostgreSQL, которая составляет достойную конкуренцию реляционным СУБД от Oracle и Microsoft. Также необходимо отметить, что в последнее время все большую популярность приобретают базы данных NoSQL, которые преимущественно являются проектами open sourсе.

- Какие сложности возникают при портировании наиболее популярных в России бизнес-приложений на отечественные/открытые ОС и СУБД?

При портировании на открытые ОС бизнес-приложений, написанных на Java, таких сложностей не возникает. Это касается и приложений, написанных на скриптовых языках (JavaScript, Python и т. д.). Причем большинство приложений, написанных на этих языках, уже портированы на Linux-системы.

Что касается приложений, написанных на C#, то в последнее время одной из приоритетных задач разработчиков платформы .Net компании Microsoft является именно кроссплатформенность. К сожалению, не все так быстро, как хотелось бы. На данный момент .Net Core является кроссплатформенной системой с открытым исходным кодом. Существуют соответствующие рекомендации от вендора по миграции на .Net Core, пользуясь которыми наши Net-разработчики уже перевели часть приложений на .Net Core, и теперь эти приложения могут работать на Linux-системах. Правда, нельзя сказать, что это был простой и гладкий процесс.

Основной проблемой при портировании приложений, написанных на C++, является использование библиотек, которые работают исключительно под Windows. В некоторых случаях возникает необходимость писать отдельное приложение для другой платформы, переходить на другую среду разработки, например Qt, или смотреть в сторону Java, если быстродействие не является настолько критичным.

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

Помимо технических существуют вопросы, связанные с формированием новой экспертизы, переподготовкой специалистов. Процесс обучения и адаптации занимает месяцы.

- Может ли Россия использовать опыт отдельных европейских стран? Например, во Франции существует система жестких запретов на использование государственными органами зарубежных ОС и СУБД. В Германии и Италии государство субсидирует миграцию муниципальных органов власти на открытое ПО (OS Linux).

В России можно было бы запретить использование государственными органами зарубежных ОС, если бы имелись собственные разработки уровня ведущих мировых аналогов (у нас уже есть неудачный опыт попытки пересадить государственных служащих на отечественные автомобили).

Системы с открытым исходным кодом, на мой взгляд, выглядят предпочтительнее, но уровень экспертизы на сегодняшний день оставляет желать лучшего. Большинство российских средних и высших учебных заведений продолжает использовать и продвигать систему Windows. Крупные российские компании не торопятся спонсировать open source-проекты или как-либо в них участвовать и, что еще хуже, не поощряют, а порой запрещают своим сотрудникам участвовать в таких проектах. Ведущие зарубежные компании, напротив, приветствуют участие своих сотрудников в open source-проектах и сами пытаются поддержать эти проекты, чтобы повысить контроль и уменьшить собственные риски.

В любом случае процесс перехода на open source-системы должен быть плавным, постепенным. Нельзя всех в приказном порядке перевести на open source с завтрашнего дня. Сначала нужно нарастить экспертизу и вовлечь российский бизнес в open source-проекты.

Если говорить о создании государственного ПО в целом, то разработку новых проектов нужно начинать на open source, если его уровень соответствует уровню коммерческих систем. Нужно понимать, что open source-проект сам по себе не является панацеей, важна собственная экспертиза. Как показывает опыт, любой open source-проект так или иначе может быть поглощен крупной компанией или просто перестать существовать, например, open source-проект Titan (графовая база данных) перестал развиваться, а дальнейшее продолжение получил в коммерческой версии DataStax.

- В какой форме осуществляется или будет осуществляться поддержка работы открытых ОС и СУБД? Кто несет или будет нести ответственность за проблемы совместимости? Кто отвечает или будет отвечать за безопасность ОС и СУБД?

Вне зависимости от того, открытая система или коммерческая, разрабатывается и поддерживается она специалистами-разработчиками. Вопрос скорее в наличии таких специалистов. Если смотреть на проблему глобально, то государству необходимо поддержать подготовку/переподготовку кадров. Вопрос на самом деле шире. Он касается не только ОС и СУБД, но и среды разработки, фреймворков, библиотек и т. д.

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

Если говорить про безопасность, то у государства есть службы, отвечающие за безопасность, они и будут отвечать за безопасность ОС и СУБД. Соответствующие кадры у них имеются, а при необходимости они будут привлекать подрядчиков, занимающих ведущие позиции в отрасли.

- Существуют две противоположные точки зрения на финансирование разработок ПО. Сторонники одной считают, что лучший вариант процесса импортозамещения следующий: промышленные корпорации получают средства из бюджета, объединяются в пулы и заказывают разработчикам ПО с жестким контролем за выполнением. Сторонники другой предлагают целенаправленно (на уровне государственных проектов) финансировать проекты разработки отечественного ПО, выбранные в силу их важности для решения проблемы импортозамещения. Какая позиция вам ближе и почему? Какая позиция (не обязательно из указанных выше) представляется наиболее реалистичной?

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

Заказы необходимо объединять в пулы, чтобы 100 компаний-разработчиков не разрабатывали одно и то же для 100 заказчиков. Должно быть создано одно или несколько типовых решений с самым высоким качеством, а не по самой низкой цене и растиражировано на всю сотню компаний-заказчиков.