Религиозные противостояния GNU против Microsoft и Open Source против проприетарного ПО шли несколько десятков лет. Казалось, что интерес к этому конфликту сошел на нет: Linux так и не убил Windows, а Билл Гейтс не завладел миром. 30 лет назад оптимисты предсказывали, что проприетарное ПО умрет и весь софт станет открытым — всего этого так и не произошло.

Казалось, что тема Open Source раскрыта уже со всех сторон, и каждый занял свою позицию. А большинство не занимали никаких принципиальных позиций — использовали и проприетарные решения, и Open Source в одном ИТ-ландшафте, не испытывая внутренних религиозных конфликтов. Но 2022 год для ИТ отрасли России проходит под девизом «DIY or DIE» и в этой парадигме тема Open Source стала снова актуальной и дискуссионной. Пытаясь снизить и исключить риски санкций, остановки технической поддержки, отключения лицензий и валютных ограничений, компании активно смотрят в сторону отечественных ИТ-продуктов и Open Source решений – оценивают степень зрелости решений, скорость внедрения и совокупную стоимость владения.

Мы в DataOffice Ростелекома используем ПО с открытым исходным кодом для решения задач по работе с данными с 2017 года – задолго до того, как это стало мейнстримом.  С тех пор мы набили много шишек, решили большое количество проблем и накопили большую экспертизу в вопросах работы с Open Source. В этой статье мы поделимся своим опытом.

И любимыми гифками из Футурамы.

Два слова про Open Source

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

Любая Open Source-экосистема – это набор из сотен различных компонентов и фреймворков, которые работают друг с другом на честном слове, щепотке магии и львиной доли таланта разработчиков. Все проекты в репозиториях ведутся разными командами, которые могут и не знать о существовании друг друга.

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

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

Собрать свой Hadoop просто (на самом деле нет — мы сами это делали сотни раз, и это боль).

Задача #1: Найти человека

Найти человека сложно (почти невозможно), стоить он будет как композитное крыло от нового отечественного самолета МС-21. Пойдите и вбейте «Hadoop» в поиск на hh.ru: найдется несколько человек, резюме будут пятилетней давности, а новые ребята, выходя на рынок, разлетаются как горячие пирожки.

И вот у вас уже горит проект, нужно стартовать разработку, но где команда? Поиск трех человек может занять до полугода. Примерно столько же уйдет на то, чтобы сделать из «сырого джуна» джуна с опытом. И очень важно, чтобы этот джун с опытом не вывесил резюме, ведь мы очень дорожим своими специалистами.

Задача #2: Разобраться в чужом коде

Про Gradle, Maven, Ant, NPM, Yarn (не тот, что про ресурсы) и... wget! Проекты, которые мы собираем и дорабатываем создавались сотнями человек на протяжении 10+ лет. Какие-то технологии становились популярнее, какие-то долго и медленно умирали и продолжают это делать. Но рефакторинг таких проектов не всегда оправдан. Здесь действует принцип «работает – не трогай!» во всей красе.

Например, собирается у вас 27-й подпроект из 45, и этот проект web. Ему нужно собрать свой фронт на JavaScript, а для это нужны node.js, npm и yarn. Починили, но дальше при сборке где-то внутри процесса вызывается bash-скрипт, который пытается с помощью wget скачать откуда-то файл, которого нет. Занавес.

Задача #3: Исправить ошибки или куда исчезла version 1.0.0?

Склонировали проект, с хорошим настроением и с верой в успех запускаем mvn clean install и… ничего не происходит. Точнее говоря мы получаем ошибку, что нет такой библиотеки. Ну ладно, с кем не бывает, почистим все зависимости, очистим кэши. Пробуем еще раз – снова неудача. Окей, гугл!

Сила интернета говорит, что такой версии библиотеки нет и не было НИКОГДА. Смотрим в pom.xml: версия берется из переменной, а переменная заполняется в другом файле, и откуда наши друзья взяли такую версию неизвестно, и здесь blame на github уходит в давние времена начала проекта. Ну что ж, идем в mvncentral, радуемся, что вообще есть библиотека с таким названием. Берем последнюю версию и, о чудо, все собралось!

Задача #4: Подружить между собой библиотеки из одного фреймворка

Hadoop — свободно распространяемый набор утилит, например, Hive, Spark и другие. Удивительно, но эти библиотеки не всегда дружат между собой.

Вот кейс: мы собираем сложную систему, в которой Spark может работать с мета-данными Hive, а Hive может запускать свои вычисления на Spark. Оба зависят друг от друга. При этом никто не дает гарантий, что нужная версия Hive заработает с нужной версией Spark. Данная связка — один из ярких примеров, а таких комбинаций, где рано или поздно придется разрывать порочный круг, множество.

Забытая игра «Pokemon GO» отдыхает по сравнению с развлечением, когда ты пытаешься собрать все библиотеки в одну корзину, которые иногда убегают и исчезают. А мы собрали спот и прикармливаем своих «покемонов» регулярно, чтобы они не разбегались. И да, самых вредных уже мы удалили или заменили.

Задача #5: Собрал – протестируй

Если вы знакомы с миром Java и Maven, уверен вы не раз пользовались параметром DskipTests чтобы ускорить сборку, отключив проверку тестов. А иногда — просто проскочить один поломавшийся тест. Очевидно, что для использования в бою сборки так делать нельзя, поэтому сначала придется починить все тесты (иногда на это может уйти далеко не 15 минут). За тестами также придется следить, если пытаешься применить патч или внести свои изменения в код, чтобы быть уверенным в том, что ничего не сломал.

А еще, кто сказал «написано раз — работает везде»??? Это известный слоган из мира Java, но можно про него забыть. Почему? Нет стопроцентной совместимости. Если вам нужно будет запустить нечто, что раньше работало на Ubuntu под CentOS, можно смело готовиться провести множество бессонных ночей, подпиливая одно к другому.

Итак, первую часть статьи можно было бы смело назвать «Ночные кошмары тимлида». И после ее прочтения может возникнуть ощущение, что Open Source – только для гиков. Зачем такие сложности, если можно купить коммерческий дистрибутив, нажать «Next, Next, Next» и все заработает?

Во-первых, после 24 февраля найти коммерческий дистрибутив не так-то просто – иностранные решения не продаются, а российские ИТ-решения покрывают не весь перечень задач корпораций. А во-вторых, у Open Source есть ряд преимуществ, которые выглядят очень соблазнительно. Хотя есть и ряд рисков.

Open Source вместо коммерческих решений: за и против

В этой части статьи разбираемся в плюсах и недостатках.

Преимущества

Новейшие технологии

Разработка Open Source ПО привлекает сотни тысяч талантливых разработчиков со всего мира, дает им возможность самореализации и профессионального развития.

Сообщества разработчиков исповедуют открытость, инновации, творческий поиск, свободу эксперимента и объединяют увлеченных людей разных возрастов, национальностей и социального статуса. Многие их участники имеют постоянную работу, уделяя Open Source свое свободное время, но есть также формы заработка на поддержке или консалтинге.

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

Доступ к исходному коду

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

Чтение исходного кода дает полное понимание внутреннего устройства и алгоритмов работы программ (естественно, при достаточном уровне профессионализма читателя). Это же позволяет пользователю вносить в исходный код свои изменения, создавать свои модификации программы, а также заимствовать идеи и алгоритмы. Все это вместе способно существенно ускорить развитие и создание новых продуктов.

Отсутствие зависимости от одного поставщика

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

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

Такая ситуация способствует формированию полностью закрытых ИТ-ландшафтов, существенно ограничивая конкуренцию и потенциал развития.

Недостатки

Затраты: бесплатный сыр или CAPEX vs OPEX

Несмотря на то, что при использовании Open Source ПО нет необходимости платить за лицензию правообладателю, его использование требует от ИТ-подразделения внутренней экспертизы в виде квалифицированных сотрудников.

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

Риски с поддержкой

Стандартная модель потребления проприетарных программных продуктов состоит из покупки лицензии — бессрочной (perpetual) или срочной — и отдельных регулярных платежей за техническую поддержку. Причем производитель предоставляет свободный доступ к большому объему документации по эксплуатации для своего продукта, а в рамках технической поддержки решает возникающие проблемы в соответствии с SLA.

При использовании Open Source ПО отсутствует сторона, имеющая юридические обязательства обеспечения его работоспособности, и в случае возникновения сбоев и ошибок в работе ПО, заказчик остается с ними «один на один». Ущерб от таких ситуаций будет зависеть от критичности систем и стоимости времени простоя.

Здесь некоторые читатели скажут, что Open Source ПО поддерживается сообществом, т.е. распределенной группой разработчиков, которые принимают от пользователей сообщения об ошибках, пытаются установить их причину и исправить. Да, этот, построенный на принципе «доброй воли» механизм, показывает достаточно эффективную работу, но не дает никаких юридических гарантий потребителю. И этот риск можно полноценно компенсировать только наймом команды высококвалифицированных разработчиков, которые смогут работать с исходным кодом продукта, что практически нереализуемо.      

Экономические риски и информационная безопасность

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

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

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

Опыт Ростелекома

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

Особенность крупных проектов в том, что пока решение не внедрено – невозможно оценить его ТЭО и нет запросов от бизнеса. А пока нет ТЭО и нет запросов от бизнеса – нет бюджета. Нет бюджета – нет возможности набрать большую команду для работы с Open Source. А решения текущих бизнес-задач нужны быстро.

Прообраз централизованного хранилища данных в Ростелекоме появился в 2011 году: нужно было оперативно оценить бизнес-показатели после объединения региональных компаний. Тогда решили, что самописное решение отлично подойдет для этих целей. Система отчетности заработала, а вместе с ним заработало сарафанное радио. Пользователей отчетности становилось все больше, функциональных требований — тоже.

С ростом интереса к системе самописное решение развивать было все сложнее, дольше и дороже. В какой-то момент решили, что нужно переходить на «взрослые решения», и внедрили Oracle. Но со временем мы столкнулись с теми же проблемами: задач от бизнеса становилось все больше, а развивать решение – сложнее, дольше и дороже. А масштабирование системы упиралось, кроме всего прочего, в закупку дополнительных лицензий. С 2017 года мы используем Open Source. На старте у нас не было ресурсов и экспертизы для самостоятельной сборки дистрибутивов, поэтому мы использовали коммерческие версии продуктов, а через два года мы накопили экспертизу и перешли на собственные сборки решений для BigData.

Open Source для бизнеса. Что мы рекомендуем.

Выше мы сравнили коммерческое и Open Source ПО. Кому-то может показаться, что корпоративному заказчику нужно либо выбрать один из двух подходов, либо использовать единственно доступный для него.

Даже для крупной компании уровень инвестиций в ИТ, требуемый для организации полноценного и безопасного использования Open Source ПО, может быть слишком высоким. А для компаний, которые производят продукцию, создают сервисы, предлагают услуги и не являются ИТ-гигантами, такие затраты просто не оправданы.

• Как в такой ситуации одновременно использовать преимущества обоих подходов?

• Как использовать инновации из мира Open Source, но делать это безопасно и не «раздувать» штат своего ИТ-подразделения?

• Как не остаться «один на один» с проблемами в вопросах технической поддержки?

Можно продолжать использовать иностранное ПО, игнорируя риски. В этом подходе есть очевидные плюсы – не нужно повторно инвестировать в то, что пока работает. Минусы тоже очевидны – не понятно сколько это «пока» продлится. Можно внедрять российское ПО, но не во всех сферах есть готовые решения. Во многие направления, например, СУБД, российские ИТ-компании не инвестировали, потому что рынок был прочно занят иностранными гигантами.

Но есть и более интересная перспектива. Некоторые крупные корпорации, которые вкладывали в развитие собственной Open Source-экспертизы, выводят на рынок собственные сборки продуктов и начинают предлагать услуги технической поддержки. Например, мы уже несколько лет предлагаем на рынке «Платформу управления данными». Для многих компаний это может быть экономически выгодным решением, которое совмещает высокую технологичность Open Source, надежность поставщика и гарантированную техническую поддержку на территории России. Предполагаем, что в ближайшее время на рынке будет появляться больше таких решений и от других компаний.

В заключение

Ричард Столлман:

Евангелист свободного программного обеспечения и основатель проекта GNU

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

Фундаментальный принцип Open Source ПО – свобода доступа, свобода использования. И этот фундаментальный принцип сегодня подвергается серьезным испытаниям. Популярные репозитории, на которых размещается исходный код – Github и Gitlab – находятся в правовом поле США.

Масштабных изменений пока не последовало, а российский сегмент Интернета пока не изолировали, мы все еще имеем доступ к Open Source репозиториям. Но аккаунты некоторых пользователей из России уже заблокировали. А в код на публичных репозиториях внедряли некоторые адресные закладки. Это увеличивает риски использования «импортных» Open Source-продуктов для бизнес-критичных решений и промышленных процессов.

Что можно предпринять в этих условиях?

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

Сейчас эти инструменты могли бы работать в режиме локальных «зеркал» с возможностью последующего «ответвления» в случае необходимости. Помимо решения задач независимости и контроля над содержимым, эти репозитории могли бы распространять готовые пакеты для отечественных дистрибутивов Linux, в том числе с поддержкой существующих и будущих отечественных процессоров, таких как Эльбрус и Байкал. 

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

В заключение приглашаем к диалогу: напишите в комментариях, как вы снижаете зависимость от иностранного ПО? И что думаете про идею создания «импортонезависимого» Open Source-репозитория?