N месяцев назад мне ставили в упрек то, что якобы аналоги сервисов AWS есть у кучи других провайдеров. Ну есть же да? Сколько альтернативных реализаций S3, да? Как бы не так. Который месяц ковыря S3, я прихожу к однозначному выводу: интерфейсы AWS определены через реализацию, то есть, нет никаких общих абстрактных протоколов, разработанных для конкретных задач. Вместо этого протекает деталь реализации здесь, протекает костыль тут, здесь устаревший параметр, которым уже давно никто не пользуется, а здесь новый параметры, которым ЕЩЁ никто не пользуется, и по итогу портирование минимально сложной системы на базе S3 с одной площадки на другую требует целой команды макак с напильниками.
Раньше я не решался высказать эту мысль, потому что у меня небыло железных пруфов, но сейчас они есть, по крайней мере по отношению к S3. Даже достаточно продвинутые реализации S3 API в Yandex.Cloud или Ceph имеют огромное число несовместимостей с AWS.
Как бы это не могло звучать странно, тем не менее, эту картину я вижу далеко не первый раз. Это не тупая ошибка, а точный расчет — так развивали свои решения как минимум Oracle, SAP, Microsoft, а именно — холили и лелеяли каждый маленький костыль, для поддержки которого приходилось выделять отдельного программиста, ровно для одной цели — чтобы никто не мог реверс-инженернуть твою софтину и написать альтернативу, таким образом уведя клиентов. IBM сделало независимый от реализации стандарт PC? Intel сказал огромное спасибо и монопольно основался в нише.
К тому же, с маркетинговой точки зрения чем больше пунктов с фичанеймами в брошюрках — тем лучше смотрится продукт. Почесать левой рукой левое ухо — замечательная фича. Клиент приходит с запросом «мне нужно почесать левое ухо правой рукой» — «извините, поддержка такой фичи у нас не планируется».
И только не нужно мне говорить, что вот же есть где-то Джон и Фрэнком, которым позарез нужен ваш костыль 1997 года выпуска, без которого они не могут жить. Могут. Разработчик мог сэкономить на поддержке этого костыля, потеряв лояльность пары клиентов — это допустимая жертва. Однако, фактор vendor-lock-а за счет бесконечной поверхности интерфейса В УСЛОВИЯХ ИЗБЫТКА ФИНАНСИРОВАНИЯ слишком привлекателен. Я хочу подчеркнуть фактор избытка финансирования, потому что при недостатке финансирования клиенты Джон с Фрэнком будут мгновенно посланы, руководство ни одной минуты не будет размышлять про какую-то совместимость, доверие клиентов, и прочие пустые слова, лишь поддержка будет отвечать дежурное «мы работатаем над этим, оставайтесь пожалуйста на связи». Всё, о чем будет думать руководство — это как сократить издержки. чтобы выйти на прибыль.
Мне удивляет только тот факт, что подобные соображения никто не пишет на каждом заборе. Ведь это просто священные заповеди коммерческой разработки, но даже я до недавних пор не рисковал оглашать их публично. Страшно то, что эти заповеди «с молоком матери» впитали многие разработчики, и следуют им, даже не понимая, что эти заповеди существуют. «Я должен поддерживать совместимость ради совместимости. Моя совместимость должна быть совместимой. Даже если я обосрался в минорном релизе, который скачало 10 человек — я буду эту ошибку тащить следующие 10 лет разработки, потому что могу».
Кстати, если вдруг у кого-то есть блоги-книжки-статьи, аналогичные этому сообщению — буду благодарен за ссылку. Заранее хочу иключить из списка благодарности заполеннные водой книжки манагеров, ничего не соображающих в коммерческой разработке — это большая часть массы макулатуры мне совершенно не интересна.
