Я много лет обсуждал с клиентами технологии и их поставщиков, и многие употребляют термин "lock-in", означающий барьер для смены поставщика или привязку к поставщику. Вопросы звучали так: "Не станем ли зависимы от поставщика из-за этого продукта?" или "Решение X для нас предпочтительнее, потому что не поставит нас в зависимость от поставщика". Я много думал над этим вопросом и делился своими мыслями с клиентами, но на написание этого поста меня спровоцировало обсуждение поста @nigelpoulton под названием VSAN and HW arrays, где упоминался lock-in.
Я заявил, что этой параноидальной страшилки IT-индустрии никогда не было и быть не могло.
Что скрывается за термином Lock-in?
Когда я прошу клиентов, которых беспокоит lock-in (или зависимость от поставщика) объяснить, чего именно они опасаются, они всегда отвечают что-то вроде "Не хотелось бы потом попасть в зависимость".
Хорошо, это уже кое-что. Обычно после нескольких вопросов ситуация сводится к тому, что изменения могут быть невыполнимы из-за высоких затрат — времени или денег.
Это звучит разумно, но главные проблемы в основном бывают связаны с тем, как IT-шники смотрят на lock-in:
- Максимализм: вы либо попали в плен lock-in, либо нет.
- Реальная цена зависимости от технологии исчисляется некорректно.
- Огромное количество времени и денег тратятся на избежание зависимости, но их не считают.
Усилия — вот реальная мера
Усилия — это то, без чего невозможно движение, чем больше сложностей, тем больше усилий нужно приложить, чтобы двигаться дальше; думаю, этот термин подходит лучше, чем окутанный жутью lock-in. На самом деле мы подсчитываем (и, надеюсь, заранее), сколько денег и времени (которое тоже стоит денег) будет затрачено на какие-либо изменения. Чем выше затраты, тем больше усилий. Чем больше усилий, тем больше должно быть пользы от производимых изменений. Любое решение в IT подразумевает затраты и приложение усилий.
Не существует невыполнимого объема усилий.
Рассмотрим пример компании с наиболее очевидной lock-in привязкой к технологии — платформе Netflix на AWS. Может ли Netflix уйти от AWS? Безусловно. Будет ли это стоить таких затрат? Ни в коем случае. Как только преимущества использования другой платформы начнут перевешивать затраты на переход, они уйдут от AWS.
В этом весь смысл комментариев Найджела о том, что VMware VSAN "намертво привязывает к гипервизору". Сколько усилий требует смена технологий? Определенно, это требует некоторых усилий, но неужели их объем так велик, чтобы говорить о “lock-in”? Едва ли.
Open Source тоже требует усилий и затрат
Я часто слышу о тех, кто выбирает open-source проекты, чтобы избежать зловещего “lock-in”. Разумеется, такие проекты требуют меньших финансовых ресурсов, но при этом требуют значительного количества времени (которое, как известно, стоит денег). Выбрали CloudStack, но хотите перейти на OpenStack? Сколько усилий потребует этот процесс?
Измеряйте усилия и подсчитывайте расходы
Наиболее продвинутые работники IT (инфраструктура, разработчики, отдел закупок, даже руководство) должны принимать решения именно в таком ключе.
Пишете ли вы для специфического API, выбираете платформу для хранения данных или подписываете контракт, нужно задать себе вопрос:
Сколько усилий и затрат уйдет на изменения рабочей среды, и будут ли они того стоить?
Есть множество примеров компаний (таких как Netflix), которые принимают решения несмотря на то, что эти решения попадают под понятие lock-in, и это вовсе не плохие решения. EMC перешли на SalesForce.com несколько лет назад и (как и большинство клиентов) тщательно настроили его под себя. Многие, возможно, решат, что EMC теперь привязаны к Salesforce, но готов поспорить, если спросить руководство EMC Sales, изменили бы они свое решение, если бы могли, они ответят, что приняли бы его снова.
Так существует ли Lock-in?
Думаю, стоит отступить от точки зрения, что его не существует вовсе, но тогда стоит и изменить определение lock-in на следующее: это ситуация, в которой усилия и затраты на изменения сильно превосходят предполагаемую выгоду. Если рассматривать все с такой точки зрения, вы перестанете видеть зловещий lock-in в каждом темном углу.
Комментарии (22)
Dr_Wut
11.02.2019 09:06+3Проблема lock-in (а вообще-то это называется vender-lock) совсем не в смене, а в том, что никто не может дать гарантию что вендер будет:
— вообще развивать/поддерживать данный продукт
— будет развивать в нужную сторону
— не выпилит нужный вам функционал (захочет за него отдельных денег)
— будет возможность остаться на некоторое время на устраивающей версии продукта до смены
SirEdvin
11.02.2019 10:00Дополню комментарий выше, еще одна из проблем vendor-lock это то, что ваш бизнес попадает в полную зависимость от поставщика услуг. И не стоит приводить в пример netflix, они, если я не ошибаюсь, все как раз делают грамотно, в основном арендуя сервера.
А если, вы, например, сделаете ваш бизнес поверх aws lambdas, то в какой-то не очень приятный момент может оказатся, что амазон повысил цены и ваш бизнес перестал быть рентабельным. А что бы переписать все у вас денег уже нет.
Самые разрушительные варианты — это когда компания, которая предоставляет услуги просто закрывается и вы сразу за ней.
begemoth3663
11.02.2019 19:11… в какой-то не очень приятный момент может оказатся, что амазон повысил цены и ваш бизнес перестал быть рентабельным.
а когда последний раз aws повышал цены?
мой непосредственный опыт показывает, что он только понижает: t3/c5/m5 дешевле своих предшественников t2/c4/m4...SirEdvin
11.02.2019 19:14Окей, замените aws на любого провайдера, который когда-либо повышал цены. Суть посыла от этого не изменится.
Если вы доверяете aws свой бизнес — пожалуйста, но вам стоит понимать, насколько сильное влияние на вас получит амазон. И я не говорю, что кто-то плохой в амазоне может попробовать вам навредить, обычно просто что-то неприятное происходит.
На хабре раньше где-то раз в код всплывала тема, как пофигизм и неповоротливость регистраторов доменов рушили людям бизнес, да можно далеко не ходить за примерами, вон google и valve так делают для игр.
rsashka
11.02.2019 10:04«Нужно считать», так можно сказать про что угодно, но такой вывод не имеет прямого отношения к lock-in (как было замечено ранее, более правильное название — vendor-lock).
А проблема с vendor-lock заключается в том, что считать требуется каждый раз при изменении условий использования решения, а не только при первичном выборе проприетарной технологии (а условия использования могут измениться в любой момент).
Ведь подсаживая клиента на свою технологию, в дальнейшем его можно доить простым способом. Нужно делать так, что бы стоимость использования vendor-lock решения было ниже стоимости смены решения целиком, что обеспечить не так уж и сложно.
И при таком подходе саму технологию можно будет вообще бесплатно раздавать.
paranoya_prod
11.02.2019 11:38Мы живёт в век вендор-лока. ПО зависит от ОС, от железа. Железо зависит от ПО, от ОС, от железа. ОС, зависит от железа. При каких-то конфигурациях вендор-лок незаметен и его можно игнорировать, а где-то нельзя даже купить чехол не от вендора. :)
rsashka
11.02.2019 11:50Несогласен.
Вендор-лок, это один из способов конкуренции, основанный на монопольном владении ресурсом (технологией, спецификацией, криптографическим ключом).
Если используются используются общие, а еще лучше открытые стандарты и спецификации, попытка подсадить пользователя на вендор-лок решение обычно становится экономически не выгодной.paranoya_prod
11.02.2019 12:12Каким ресурсом (технология, спецификация) монопольно владеет Эпл?
Эпл владеет продуктом (Айфон) и вендролочит на сервис, на дополнительные аксессуары к нему, на ПО (айтюнс), на места продажи.
Потребителю плевать на технологию и спецификацию, но не плевать на продукт.
Поэтому вендор-лок выглядит так, как выше написал.rsashka
11.02.2019 12:47Ну так, а сервис залочен на криптографический ключ.
А внешний вид, место продаж и т.д. это не вендор-лок, а средства индивидуализации которые относятся к результатам интеллектуальной деятельности, на которые установлено исключительное право интеллектуальной собственности.
adictive_max
11.02.2019 11:51Думаю, стоит отступить от точки зрения, что его не существует вовсе, но тогда стоит и изменить определение lock-in на следующее: это ситуация, в которой усилия и затраты на изменения сильно превосходят предполагаемую выгоду.
По-моему, автор как-то сильно не с той стороны зашёл. То, что он описал, когда предполагаемая выгода и затраты на переход определяются свойствами самого сервиса — это называется удобство. А lock-in — это возможность для поставщика искусственно манипулировать этими параметрами. Закрытые форматы, приватные API, сильно зависимые друг от друга сервисы, обязательное необязательное железо. Всё для того, чтобы никто не смог сделать лучше, а переход обошёлся как можно дороже.
0lom5zhdovdv
11.02.2019 12:27Приведенный пример с Нетфликс и AWS не очень удачен. Вы просто плохо проинформированы о том, как их сервис работает и насколько они зависимы от AWS…
xRay
11.02.2019 12:30Примеры:
1. Есть большой продукт написанный на языке который сейчас не популярен. Писали его лет 10. Новых специалистов по языку программирования нет и да и вообще специалистов по нему мало. А переписать с нуля это дорого и время.
2. Вы купили к примеру СХД. Через некоторое время в сетевом хранилище сдохла батарейка и кеш зиписи (или чтения) просел. Батарейку вы можете купить только у производителя вашей СХД. Ситуацию можно усугубить тем что, прошло 6 лет с момента закупки СХД.
p.s. Вы написали свое приложения под Silverlight и тут бац Microsoft прибил Silverlightmayorovp
11.02.2019 17:47Ну, сервелату-то досталось не столько от Microsoft, сколько от производителей браузеров. За компанию с java-апплетами и прочими NPAPI-плагинами…
igruh
11.02.2019 14:46Так существует ли Lock-in?
Существует! И называется по-русски синхронный усилитель (детектор). Интересно, я один из-за этого слова в названии сразу ткнул в статью, не читая предисловие?rsashka
11.02.2019 14:57Уже писали в комментариях выше, что более корректное название vendor lock или vendor lock-in.
lingvo
11.02.2019 17:16+1В статье описывается частный случай Obsolescence или Устаревания по причине зависимости от одного поставщика продукта или ПО.
Стратегия, которая позволяет избежать устаревания по разным причинам в том числе и Vendor Lock-in, называется Obsolescence Management и достаточно неплохо описана в МЭК 62402.
Вы пришли к правильному выводу, что все можно оценить в Усилиях. В реальности в дополнение к этому используется еще оценка рисков — наступления определенных событий — например исчезновение поставщика или окончание поддержки с соответствующими факторами влияния на ваш продукт и вероятность наступления.
Тепер по стратегии — есть т.н. реактивания и проактивная стратегии. Реактивная — это когда вы ничего не делаете, пока не наступит момент устаревания. Из вашего примера — если вдруг Amazon отключит AWS. Тогда у вас будет не так уж много времени, чтобы перейти на другую систему и это потребует определенных усилий. Есть несколько вариантов выхода из ситуаций, опять же описанных в МЭК 62402.
Но самое интересное заключается в проактивной стратегии — ее грамотное развертывание позволяет многократно уменьшить эффект от устаревания или вообще убрать вероятность его возникновения. Open-source — это всего лишь один из вариантов, предложенный в МЭК 62402. Другие способы включают в себя:
- open technology — вы берете софт у которого открытые и стандартизированные интерфейсы. Тогда вы сможете легко перелезть на другой софт у которого Form-Fit-and-Function совпадает со старым софтом.
- Design Conciderations — еще на этапе выбора софта вы смотрите на конкурентов и выбираете тот софт, аналогичный которому выпускает несколько фирм. Так вы уменьшаете риск, что продукт уйдет с рынка из-за низкого спроса.
- Open-source — уже говорили. Как правило к нему надо добавлять contract support.
- Multiple Features Use — грубо говоря если фича X есть в продукте А и B из трех, то ее используем. Если же Фича Y есть только в продукте B, а в A или C ее нет — не используем.
- Periodic Upgrades — перелазить на новую версию до того, как старая сделает использование продукта невозможным.
Ну и еще пара трюков, смысл которых один — сделать Vendor Lock-In безопасным и безрисковым для бизнеса.
gshamshurin
12.02.2019 11:01Возьмём рынок механических САПР. Из вменяемого купить навсегда сейчас можно Solidworks (который под видом телеметрии в общем случае непонятно что, непонятно как, кому и куда отправляет), Компас (который очень дискуссионный/неоднозначный сам по себе продукт) и… всё. Адиос, амигос, оформляйте подписки.
Представьте себе завод на 1000+ человек сотрудников, у которого вся продукция, всё legacy сделано в Инвенторе. Подписываемся и платим, платим и подписываемся. Lock-in.
open technology — вы берете софт у которого открытые и стандартизированные интерфейсы. Тогда вы сможете легко перелезть на другой софт у которого Form-Fit-and-Function совпадает со старым софтом.
Несмотря на то, что часть данных может быть представлена в открытом формате, полностью корректного переноса проекта их одного в другой САПР не видел. Проигали.
Design Conciderations — еще на этапе выбора софта вы смотрите на конкурентов и выбираете тот софт, аналогичный которому выпускает несколько фирм. Так вы уменьшаете риск, что продукт уйдет с рынка из-за низкого спроса.
Вы уже разработали линейку двигателей в одном софте, перенести из которого — см.выше. Проиграли.
Open-source — уже говорили. Как правило к нему надо добавлять contract support.
Годится на поделки либо любителям писать на brainfuck.
Multiple Features Use — грубо говоря если фича X есть в продукте А и B из трех, то ее используем. Если же Фича Y есть только в продукте B, а в A или C ее нет — не используем.
Наборы фич ± одинаковые, но это не помогает т.к. они реализованы в разных форматах.
Periodic Upgrades — перелазить на новую версию до того, как старая сделает использование продукта невозможным.
Вопрос не в разработке нового, вопрос в поддержке старого.
В тему призываются kompas_3d и DassaultSystemes. Они используют и постоянные и временные лицензии, может что расскажут
pewpew
Подмена понятий.
Это как техника от Apple. Вроде физически ваши, но ремонтировать их у сторонней фирме или самостоятельно уже нельзя. Но вы не переживайте, всё просчитано. Вам же выгоднее.
Нет.
jreznot Автор
Я бы сказал тенденция усиливается во всех отраслях. Если вы купили тракторы «Беларусь», запчасти к ним, обучили людей, начали работать, то вы уже от этих тракторов особо никуда не денетесь.
saege5b
Нет.
Но если в беларуси используется стандартная вертушка 12 см, коих для компов навалом за копейки, но в тракторе карлосон со специально «хитрой» площадкой за цены от х100 — то, да, вендорлок.
Это может быть разъём, стандартный, но к нему прилагается или специальный внешний облик, или распиновка, или вообще своя ОС с жутко секретным протоколом общения с хостом.
Самое поганое, что производитель может внести изменения в защищёный компонент, а с него слезть не получится. А эти изменения не всегда полезны: у Епсона на некоторых полупромышленных принтерах стартовая доза и штатная краски, слегка отличаются по химии. Т.е. новый принтер испытываешь на стартовой дозе — всё замечательно, а на штатной — вылезают козявки разные.
У другого производителя, в платах управления натыкивают транзисторы качеством так себе, вроде бы класические корпуса, но есть ньюансы. Поэтому вместо 300-400 р. За штуку, будет 1000. А их там полтора десятка. И сертифицированный центр меняет исключительно все — руководствуясь исключительно заботой о потребителе.
lingvo
Ну почему усиливается? Она всегда и была, даже 20 лет назад. Вопрос в том, что сейчас с этим научились вполне неплохо бороться.
Например раньше где-нибудь в 30-ые годы можно было то же самое сказать об автомобилях — если купил Форд, то только Форд ремонтировать и умеешь и от него никуда не денешься. А сейчас — сегодня ездишь на Форде, завтра на Тойоте. И никаких проблем, так как Form Fit and Function в автомобилях совпадают до мелочей.
Применяя obsolescence management c точки зрения тракторов "Беларусь" vendor lock-in можно обойти разными способами. Наиболее популярный сегодня — что-то там as a service. Т.е. вы покупаете не просто трактор, а трактор вместе с обслуживанием на 10 лет. Т.е. запчасти уже не ваша проблема. Вам нужно только обучать людей управлять трактором, а ремонт опять же уже не ваша проблема. И через 10 лет, когда заканчивается договор с одним производителем, проводите тендер и выбираете следующего. И если следующим будет Caterpillar какой-нибудь — вам будет пофиг.