Что такое «привязка к поставщику» и как ее избежать?

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

Что такое блокировка поставщика?

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

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

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

Классическим примером привязки к поставщику в секторе программного обеспечения является компания Microsoft. Во многих отраслях все основные компоненты предоставляются крупной корпорацией: операционная система (Windows), прикладное программное обеспечение (Office), база данных (Access) и т. д. Это означает, что все важные компоненты программного обеспечения, от программ до лицензий, от ценообразования до поддержки, контролируются одним единственным поставщиком, и клиент оказывается в зависимости от него.

Как возникает зависимость от одного поставщика?

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

Технологические компоненты — это так называемые «взаимодополняющие товары». В этом случае отдельные компоненты взаимозависимы. Например, если у вас есть Xbox или PlayStation и коллекция игр, вы, скорее всего, не станете менять систему, потому что тогда вам придется снова покупать все игры, поскольку они не запускаются на другой системе.

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

Что затрудняет переход к другому поставщику?

В основе этих соображений лежит понимание того, что целое — это больше, чем сумма частей. На самом деле, целое состоит из частей:

  • компоненты
  • взаимодействие и другие явные или неявные связи между частями
  • результирующие (эмерджентные) свойства всей системы.

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

Вот конкретный пример:

Представим себе систему баз данных, которая существует в инфраструктуре провайдера. Хранящиеся в ней данные можно относительно легко перенести при переходе к другому провайдеру. Но как насчет других компонентов и связей между ними? Настройки, права доступа, распределение базы данных по нескольким серверам (шардинг) и т.д.? Знаем ли мы сложность общей системы или можем ее понять? Если да, то можно ли воспроизвести эту систему в целом на инфраструктуре нового провайдера с разумными усилиями? Во многих случаях ответ хотя бы на один из этих вопросов, скорее всего, будет «нет».

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

Как происходит блокировка поставщика в облаке?

Использование облака имеет множество преимуществ. Однако существует также угроза блокировки поставщика. Типичный пример — хранение важных данных у облачного провайдера. Если мы хотим использовать другого провайдера для обработки данных, их необходимо передать по сети, что влечет за собой расходы на передачу. В этом случае кажется привлекательным также передать задачу обработки первоначальному облачному провайдеру. В результате возникает эффект «ползучей блокировки».

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

Какие аспекты составляют среду облачных вычислений?

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

  • Программно-определяемые сети (SDN): Вместо развертывания и настройки физических маршрутизаторов и коммутаторов используются виртуальные сети и сетевые устройства.
  • Программно-определяемое хранилище (SDS): вместо физического массового хранилища в программно-определяемом центре обработки данных используются объектные хранилища, такие как «Amazon S3», и блочные хранилища, такие как «Azure Blob Storage».
  • Компьютерные и бессерверные решения: Infrastructure-as-a-Service (IaaS) и Container-as-a-Service (CaaS) виртуализируют операционные системы и приложения. С помощью «Function-as-a-Service» (FaaS), таких как «AWS Lambda» и «Microsoft Azure Functions», отдельные функции становятся доступными для вызова.

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

Аспекты облачных вычислений Характеристики (примеры)
Хостинг Веб-сервер, балансировщик нагрузки, DNS
Хранение Банки данных, объектное хранилище, блочное хранилище
Приложения API, IaaS, CaaS, FaaS
Конфигурация Конфигурационные данные, бэкенды администраторов
Поддержка Документация, техническая поддержка
Нормативно-правовое регулирование Контракты, лицензии
Совет

Облачная инфраструктура IONOS — это европейская альтернатива крупным, глобальным облачным игрокам: мощная производительность, 100% соответствие требованиям GDPR и интуитивно понятный пользовательский интерфейс.

Как экономические факторы влияют на привязку к поставщику?

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

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

Каким образом организационные факторы способствуют фиксации поставщика?

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

Каким образом технические факторы способствуют блокировке поставщика?

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

Как избежать привязки к поставщику

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

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

Стратегические меры, позволяющие избежать привязки к поставщику

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

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

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

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

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

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

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

Технические меры для предотвращения блокировки поставщиков

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

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

Ключевое слово здесь — «инфраструктура как код» (IaC). Имейте в виду: «код», а не «услуга». В то время как услуга арендуется, вы контролируете свой код. В коде определяются желаемые структуры. Они содержат отдельные компоненты, а также связи между ними. Помимо явного документирования систем в коде, которое это влечет за собой, есть и другие решающие преимущества.

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

Оцените статью
cdelat.ru
Добавить комментарий