Як уникнути vendor lock-in з відкритим кодом: погляд розробника

Те, наскільки сильно компанія залежить від технологічних постачальників, давно вийшло з суто архітектурних дискусій у площину бюджетів і вимог відповідності. В аналізі, опублікованому на The New Stack за підтримки SUSE, автори доводять, що vendor lock-in рідко починається з одного хибного рішення, він накопичується з багатьох цілком розумних.

Скільки насправді коштує lock-in

Проблема не в тому, що компанія користується чужими продуктами, адже кожна продуктивна система залежить від постачальників. Проблема в залежності, яку надто дорого або практично неможливо розібрати: у платформній команді вона накопичується в API, контрактах, планах розвитку, схемах ідентифікації та моделях даних.

Найризикованіше те, що ніхто не перевіряв. Керована база даних обростає пропрієтарними розширеннями, на які починає покладатися код застосунку, а середовище Kubernetes прив'язується до IAM, мереж і балансувальників однієї хмари. Разом вони підвищують ціну виходу, яка згодом проявляється як поспішні міграції, збої сервісів і перенавчання персоналу.

Відкриті ліцензії та ті, хто може змінити правила

Відкритий код добре проходить цей тест, бо його створюють так, щоб системи можна було перевіряти, переносити й замінювати, хоча, наголошують автори, гарантії немає: жорстку залежність можна збудувати і на відкритому фундаменті. Ліцензія змінює інше, а саме те, хто має право переписувати умови. Ядро 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.

Цифровий суверенітет і розрив у 52%

Цифровий суверенітет, тобто рівень контролю організації над інфраструктурою, даними й технологічним вибором, робить ці самі питання терміновими. Дослідження SUSE, наведене в статті, показує: майже всі підприємства вважають суверенітет пріоритетом, але лише 52% реально роблять кроки в цьому напрямку.

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

Чотири здібності для перевірки

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

Висновок простий: справжня ціна платформи включає ціну виходу з неї, і цю ціну варто розуміти до, а не після рішення.