Как избежать вендорлока с помощью Open Source: взгляд разработчика

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

Каждая команда, отвечающая за инфраструктуру, принимает решения, которые трудно отменить. В большинстве случаев они срабатывают. Иногда — нет.

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

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

Что такое вендорлок и как он может навредить вашему бизнесу

Риски вендорлока на самом деле не связаны с зависимостью от поставщиков, поскольку каждая производственная система зависит от поставщиков. Главная проблема — это зависимости, от которых становится слишком дорого или непрактично отказаться.

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

Большие последствия небольших, невидимых и непродуманных решений

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

К сожалению, некоторые команды знакомы с этими невидимыми зависимостями. Управляемая база данных может использовать проприетарные расширения, которые затем начинает использовать код приложения. Среда Kubernetes может быть привязана к IAM, сети, хранилищу и балансировщику нагрузки одного облака. Конвейеры наблюдаемости и логирования могут быть ориентированы на форматы одного поставщика. Ни один из этих вариантов сам по себе не является безрассудным, но вместе они могут создавать значительные проблемы.

Препятствия на пути к изменениям и их скрытые издержки

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

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

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

Open Source предлагает другой путь

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

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

Что такое Open Source

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

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

Open Source также меняет правила игры

Для разработчиков обратимость касается не только API и форматов данных. Она также касается того, может ли одна компания изменить условия, лежащие в основе базовой технологии. Ядро Linux — полезный пример. В документации ядра Linux отмечается, что передача авторских прав не требуется, поэтому объединенный код сохраняет свое первоначальное право собственности, и теперь у ядра тысячи владельцев. Это делает одностороннее перелицензирование ядра фактически нереальным.

Kubernetes имеет другую юридическую структуру, но практическая защита аналогична. Проект лицензирован в соответствии с Apache 2.0 и управляется Cloud Native Computing Foundation. Лицензия предоставляет пользователям бессрочные права на существующий код, поэтому ни один поставщик не может задним числом отнять эти права на открытый исходный код у проекта в том виде, в котором он уже существует. Это важно, потому что платформа будет оставаться доступной, даже если конкретный поставщик изменит свою стратегию.

Разветвление Terraform на OpenTofu показывает, почему это не просто теоретическое различие. В 2023 г. HashiCorp изменила лицензию Terraform с Mozilla Public License 2.0 на Business Source License 1.1. Сообщество отреагировало, создав форк последнего открытого исходного кода в OpenTofu, теперь это проект Linux Foundation, который остается под лицензией MPL 2.0. Урок для разработчиков заключается не в том, что каждый Open Source-проект застрахован от изменений в лицензировании. Он заключается в том, что открытое лицензирование и нейтральное управление могут сохранить жизнеспособный вариант выхода, когда поставщик меняет направление.

Open Source, подкрепленный корпоративной дисциплиной

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

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

Цифровой суверенитет: Х-фактор, делающий Open Source еще более важным

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

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

Если ваша команда поддерживает регулируемые отрасли или развертывает системы в локальных или изолированных средах, вы, возможно, особенно знакомы с растущим давлением в отношении суверенитета.

Суверенитет устанавливает дедлайн для работы, которая и так уже стоила того, чтобы ее выполнить

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

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

Такое изменение формулировки важно, потому что оно превращает суверенитет из наложения политики в свойство архитектуры. Важный вопрос заключается не просто в том, «во сколько дополнительной работы обойдется суверенитет». Вопрос звучит так: «Какие элементы нашего технологического стека уже не проходят проверки на переносимость, совместимость интерфейсов и возможность верификации, которые мы считаем важными?»

Как укрепить суверенитет с помощью Open Source

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

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

Постоянная работа над обеспечением цифрового суверенитета

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

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

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

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

Open Source позволяет взять под контроль вашу экосистему ПО

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

Принцип обратимости дает конкретную основу для такого анализа, поскольку его можно разделить на возможности, которые команда способна определить, оценить и проверить:

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

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

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

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

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

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