Стратегия корпоративного Open Source стала более искушенной. Тем не менее, ИТ-руководители все еще могут столкнуться с рядом заблуждений, когда они обсуждают стратегию и планируют использование открытого ПО на своих предприятиях, пишет на портале Enterprisers Project Гордон Хафф, технологический евангелист компании Red Hat.

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

Ниже мы рассмотрим пять аспектов применения Open Source, которые важно понимать ИТ-руководителям — и уметь обсуждать их в своих организациях.

Заблуждение 1. Вы можете переложить ответственность за безопасность на других людей

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

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

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

Существует также вопрос цепочек поставок ПО — открытого (и другого) кода, который компании используют в своих внутренних приложениях или поставляемых продуктах, включая все зависимости, связанные с этим кодом. В своем исследовании «2020 Open Source Security and Risk Analysis Report» компания Synopsys провела аудит 1235 приложений и обнаружила, что 99% из них включают компоненты с открытым исходным кодом. Она также обнаружила, что 82% кодовых баз содержат компоненты, устаревшие более чем на четыре года.

Несмотря на растущее внимание, которое стали уделять цепочкам поставок ПО, в отчете Red Hat «Global Tech Outlook 2022» говорится, что только у 10% респондентов управление рисками третьих сторон или цепочек поставок является главным приоритетом финансирования в области безопасности, что является самым низким показателем среди всех категорий. (Опрос проводился до появления уязвимости log4j. Надеемся, что последняя повысит осведомленность и срочность в отношении цепочек поставок ПО.)

Заблуждение 2. Стоимость — самый важный фактор при подходе «сделай сам»

Может показаться естественным скачать из Интернета биты, поддерживаемые сообществом, вместо того, чтобы покупать интегрированный продукт. Это особенно актуально, если проекты сообщества относительно просты и самодостаточны или если у вас есть причины для развития независимого опыта или выполнения обширной кастомизации. (Хотя в последнем случае возможной альтернативой является работа с поставщиком для внесения необходимых изменений в исходный проект.) Однако, если ПО не является отличительной особенностью вашего бизнеса, нанять нужных высококвалифицированных инженеров будет нелегко и недешево. Существует также бремя постоянной поддержки, если загруженный вами проект превращается в форк апстрим-проекта сообщества. А если вы этого не хотите, то вам придется учесть время, затрачиваемое на работу в апстрим-проектах для добавления необходимых функций.

Также существует много сложностей в таких категориях, как корпоративные контейнерные Open Source-платформы в нативном облачном пространстве. Скачали Kubernetes? Это только начало. Как насчет мониторинга, распределенной трассировки, CI/CD, сканирования безопасности, бессерверных и всех остальных функций, которые вам нужны в полноценной платформе? Конечно, вы, возможно, сможете интегрировать множество проектов самостоятельно, но если ваш бизнес не создает контейнерные платформы на базе Kubernetes, хотите ли вы этого на самом деле? Именно здесь на помощь приходят корпоративные платформы Kubernetes.

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

Заблуждение 3. Основная привлекательность корпоративного Open Source заключается в его низкой стоимости

Более низкая стоимость — это один из приоритетов Open Source для ИТ-лидеров, который с течением времени изменился больше всего. Давайте проясним: корпоративное открытое ПО часто действительно обеспечивает лучшую стоимость, чем проприетарные альтернативы. Но в таких исследованиях, как Red Hat «The State of Enterprise Open Source», прослеживается заметная тенденция к тому, что ИТ-руководители перестали уделять внимание снижению совокупной стоимости владения как главному преимуществу, отдавая предпочтение таким характеристикам, как доступ к последним инновациям, повышенная безопасность и лучшее качество.

Речь по-прежнему идет о стоимости (бюджет всегда имеет значение). Но все важнее становится то, что корпоративный Open Source — это лучшее ПО и место, где создаются совершенно новые категории ПО, такие как облачные решения и искусственный интеллект/машинное обучение. Корпоративный открытый исходный код больше не рассматривается как «достаточно хорошая» замена для проприетарных UNIX-серверов или серверов приложений.

Заблуждение 4: ПО категории Open Source является источником фрагментации

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

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

Кроме того, несмотря на поверхностную фрагментацию ландшафта Open Source, он часто служит эталонной реализацией стандартов, что помогает избежать мелких несовместимостей, которые были обычным явлением в прошлом. В последние годы все больше внимания уделяется стандартизации некоторых базовых уровней — как это видно на примере Open Container Initiative (OCI) — и все больше проявляется тенденция к объединению вокруг наиболее сильного сообщества, как это видно на примере Kubernetes.