🛠 В нескольких словах о "solution space"

В самый разгар очередной из "чёрных пятниц"(для платформ, занимающихся продажами через Интернет, это самый важный день в году) меня угораздило встрять в спор с рафинированным занудой. Вряд ли здесь потребуется много деталей(через пять лет половина описанных здесь сущностей или безнадёжно устареет, или вовсе вымрет), обозначу три основных момента:

В целом, это был эталонный спор в духе "вы делаете это неправильно, я знаю как надо" и на этом можно было бы остановиться, не разматывая клубок писанины дальше, однако мой оппонент не желал прекращать беседу. В течение разговора я упомянул, что Docker лучше поддерживается самыми разнообразными продуктами, от CI/CD до оркестрации, на что в ответ я получил поток возражений "а вот podman ничем не хуже и даже лучше Docker, и тоже везде поддерживается". Несколько итераций спустя, видя, что ничего не меняется, я честно сдался и уступил. Или просто прикинулся валенком, не важно. Может, действительно podman лучше Docker, может и поддержка сторонними продуктами начинает развиваться, и так далее, суть не в этом.

Суть в том, что в голове начала зреть мысль: слово "поддержка" я употребил неспроста. В данном случае поддержка — это не только регулярные релизы, горячая линия в виде открытого багтрекера и какая-никакая документация; это также и наличие пространства готовых решений, или, как говорит заголовок, "solution space".

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

Да, при поиске готовых решений в Интернете иногда возникает поганое ощущение, будто списал домашку у отличника, но потом вспоминается опыт реальной жизни и всё становится на свои места. В школе, где бытовые издержки были в основном прикрыты родителями(деньги заработать, поесть приготовить, шмотки постирать), списывать было как-то стыдно. В университете же, где вопрос вставал прямо "списывать или голодать"(или продолжать сидеть на шее у родителей), я выбирал первое даже не задумываясь. Примерно то же самое происходит и в реальной жизни вне стен учебных заведений: в условиях, когда борьба за аптайм сервиса не является первоочередным приоритетом, можно позволить себе поиграться с какой-либо технологией и даже попытаться её адаптировать, но когда патроны заканчиваются, а бизнес нужно работоспособное решение вотпрямщас, становится совсем не до инноваций и уж тем более не до bleeding edge. В таких ситуациях долго думать может быть опасно, любое промедление грозит катастрофой. В ход идут любые средства: рефлексы, мышечная память(смех смехом, но я вряд ли смогу сосчитать, сколько раз я набирал на клавиатуре SHOW SLAVE STATUS\G абсолютно не приходя в сознание), а также пространство решений, или "solution space".

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

Fri, 23 Nov 2018 13:50:27 +0100

RSS // Telegram // Статистика