Короткий ответ
#Единственный полезный принцип
- Привязка
- Стоимость ухода от выбранного поставщика, платформы или подхода, измеряемая во времени, деньгах и риске, — включая цену той работы, которая не делается, пока идёт переезд.
- Если проще Во сколько обойдётся передумать потом.
Любой технологический выбор создаёт какую-то привязку. Вопрос никогда не в том, «есть ли привязка», а в том, «больше ли стоимость выхода из неё, чем стоимость её предотвращения?» — и для большинства технических решений ответ «нет», потому что предотвращать привязку значит строить ненужные вам абстракции на случай, если однажды захочется чего-то другого.
Полезная проверка: смогла бы компетентная команда переехать с этого за квартал, если бы это того стоило? Если да — это издержка. Если нет или если ответ «мы вообще не смогли бы это сдвинуть» — это риск, а риски стоят денег.
#Шесть видов привязки
| Вид | Пример | Цена выхода |
|---|---|---|
| Владение | Домен, облачный аккаунт или данные оформлены на кого-то другого | Потенциально безграничная. Выйти может не получиться вовсе |
| Знание | Систему понимает только подрядчик | Месяцы переоткрытия новой командой, оплаченные дважды |
| Проприетарный компонент | Собственный фреймворк подрядчика внутри вашего продукта | От недель до кварталов, и он переживает договор |
| Платформа | Всё построено на управляемых сервисах одного облака | Квартал-другой, и обычно оно того не стоит |
| Формат данных | Бизнес-данные в проприетарном хранилище без выгрузки | Разброс огромный. Проверьте до того, как понадобится |
| Рынок навыков | Необычный язык или фреймворк, который знают немногие | Постоянный налог на найм, а не разовая издержка |
#Две, за избавление от которых стоит платить
Привязка по владению — единственная в списке, после которой можно остаться неспособным работать, а не просто с задержкой. И она же дешевле всех чинится: перевести аккаунты на компанию — это полдня, и технически менять при этом ничего не надо. Кому принадлежит продакшен-инфраструктура — это и есть всё исправление целиком.
Привязка по знанию решает, насколько долгой и болезненной будет смена подрядчика. И её же никто не измеряет, потому что она выглядит как хорошие отношения ровно до того момента, как превращается в счёт. Исправление — сделать так, чтобы понимание существовало там, чем владеет компания: выведенное из системы, со ссылками, обновляемое, когда меняется что-то существенное.
Почему именно эти две, а не остальные
Обе дёшевы в предотвращении и дороги в обладании, а это необычное сочетание. Платформенная привязка устроена наоборот — дорого предотвращать, умеренно дорого иметь, — и вся аргументация держится на этой асимметрии.
#Те, которые стоит принять
- Платформа. Строить на управляемых сервисах одного облака обычно правильный размен: вы получаете больше продукта и раньше, в обмен на стоимость миграции, которую, скорее всего, никогда не заплатите. Писать слой абстракции над тремя облаками «на всякий случай» — известный способ потратить год.
- Фреймворк и язык. В разумных пределах. Выбрать то, у чего большой рынок, стоит в самом начале, и пересматривать это потом почти никогда не нужно.
- Внешние сервисы. Платёжный провайдер, почтовый сервис и трекер ошибок заменяются за дни. Их привязка реальна и невелика.
Одна оговорка: принять платформенную привязку — это решение, а решения надо записывать. «Мы выбрали это сознательно, и вот во что обошёлся бы переезд» — это совсем другая позиция, чем «никто не помнит, почему это так».
#Как оценить конкретное решение
Четыре вопроса по порядку. Они занимают десять минут, и их хватает почти для любого реального случая.
-
Смогли бы мы вытащить свои данные сегодня?
Не в принципе — сегодня, в формате, который можно загрузить куда-то ещё. Если ответ неясен, выясните это до решения, а не после.
-
Если этот поставщик исчезнет, сможем ли мы работать?
Не «будет ли больно». Сможет ли продукт продолжать работать, пока мы ищем альтернативу?
-
Сколько понадобилось бы компетентной команде на переезд?
Грубое число с обоснованием. Если два человека с вашей стороны расходятся втрое, значит, не знает никто, — и это находка.
-
Что мы покупаем этой привязкой?
Скорость, стоимость, возможности, меньшую команду. Если ответ «ничего особенного, просто так сложилось», то это как раз тот случай, который стоит пересмотреть.
#Что идёт не так
Строить абстракции ради ухода от платформенной привязки, из которой вы никогда не выйдете.
Вместо этого Примите её сознательно, запишите решение и цену переезда, а усилия потратьте на продукт.
Переживать из-за облака, пока домен оформлен на подрядчика.
Вместо этого Сначала владение. Это единственная категория, после которой можно остаться неспособным работать.
Считать привязку по знанию вопросом отношений.
Вместо этого Это вопрос хранения. Понимание либо существует там, чем владеет компания, либо нет, и от того, насколько вам нравится подрядчик, это не зависит.
Узнавать формат выгрузки в тот день, когда она понадобилась.
Вместо этого Выгрузите данные один раз, сейчас, и попробуйте загрузить их куда-то ещё. Упражнение на день, и иногда оно меняет решение о поставщике.
Выбирать необычную технологию ради небольшого преимущества.
Вместо этого Налог на найм постоянен и накапливается. Платить его стоит только там, где преимущество действительно структурное.
#Чего это не покрывает
Чего это не делает
- Сравнение конкретных поставщиков. Во что обойдётся уход с конкретного облака или платформы, зависит от того, что вы на них построили.
- Лицензионные и договорные ограничения на переезд. Это вопрос к юристу, и он может перебить любое техническое соображение отсюда.
- Стратегию вокруг открытого кода: связанный, но другой разговор.
- Оптимизацию расходов. Эта страница про свободу выбора, а не про счёт.