Boring tech: почему я выбираю скучные надёжные технологии

За шестнадцать с лишним лет в IT я насмотрелся на циклы хайпа достаточно, чтобы выработать спокойное отношение к новинкам. Каждый год появляется фреймворк, база данных или подход, которые «всё меняют». Часть из них действительно остаётся, большинство тихо уходит, оставив после себя проекты, которые теперь некому поддерживать. Поэтому, когда меня спрашивают, на чём лучше строить продукт, я чаще всего предлагаю что-то нарочито немодное. В индустрии это называют boring technology — «скучные» технологии. И за этой скукой стоит вполне рациональный расчёт, а не консерватизм ради консерватизма.

Что такое «скучные» технологии

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

Ключевая идея здесь — про известность граней. У зрелого инструмента давно описаны все типичные ошибки, узкие места и способы их обойти. Если я упираюсь в проблему с PostgreSQL, я почти гарантированно найду её обсуждение, разобранное вдоль и поперёк, с готовыми решениями и оговорками. С трёхмесячной библиотекой такого нет: каждую ошибку придётся разбирать первым, в одиночку, по исходному коду и обрывкам обсуждений.

Важно: «скучное» не значит «устаревшее». Многие из этих инструментов активно развиваются, просто делают это эволюционно, не ломая обратную совместимость на каждом крупном обновлении. Зрелость — это не возраст, а накопленный опыт эксплуатации в реальных, нагруженных, не идеальных условиях. Именно этот опыт и есть то, за что я готов платить предсказуемостью вместо новизны.

Почему скучное надёжнее модного

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

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

Третье — найм и преемственность. Любой проект однажды переходит к другим рукам: команда растёт, кто-то уходит, заказчик хочет подключить своих людей. Если продукт собран на распространённых инструментах, найти разработчика — вопрос недели. Если же он построен на экзотике, которую знают полтора человека в стране, владелец оказывается в заложниках у узкого круга специалистов. Я видел компании, которые годами не могли развивать собственный продукт именно по этой причине, и это куда дороже любой модной оптимизации.

Четвёртое — меньше сюрпризов в эксплуатации. Большая часть стоимости продукта — это не написание, а годы поддержки. Скучные инструменты дают спокойные ночи: меньше внезапных падений, понятный мониторинг, предсказуемые обновления. Когда я выстраиваю IT-инфраструктуру, я сознательно отдаю предпочтение тому, что переживёт смену команды и не потребует героизма от дежурного инженера в три часа ночи.

Когда новое всё-таки оправдано

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

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

Важна и цена ошибки. На некритичном внутреннем сервисе можно позволить себе эксперимент: если что-то пойдёт не так, последствия ограничены, а команда получит ценный опыт. На платёжном узле или на ядре продукта, от которого зависит выручка, я экспериментировать не стану — там цена сбоя несоизмерима с выгодой от моды. Хороший приём — изолировать новизну: попробовать инструмент на одном ограниченном участке, а не переписывать на нём всё сразу. Так можно получить плюсы новой технологии, не ставя на кон весь продукт.

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

Как я выбираю стек клиенту

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

Дальше я смотрю на каждый кандидат через простую рамку: насколько он зрел, насколько живо сообщество, легко ли нанять под него людей, как он обновляется, есть ли у него понятные сценарии отказа. Я сознательно ставлю «скучность» в плюс, а не в минус. Если два инструмента решают задачу одинаково хорошо, но один проверен десятью годами эксплуатации, а второй — модный новичок, я почти всегда выберу первый и объясню почему.

Объяснение клиенту — отдельная важная часть. Я не сыплю аббревиатурами и не давлю авторитетом. Я перевожу выбор на язык рисков и денег: вот этот вариант дешевле в поддержке и проще в найме, вот тот даёт выигрыш в скорости, но привязывает вас к узкому кругу специалистов. Решение всегда остаётся за владельцем бизнеса, моя задача — сделать его осознанным. Именно в таком формате я и работаю как внешний технический директор: подробнее об этом — на странице CTO как услуга.

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

Частые вопросы

Скучные технологии — это про экономию на качестве? Наоборот. Это про вложение в надёжность и предсказуемость. Экономия как раз чаще выходит боком на экзотике, которую дорого поддерживать и не на кого оставить.

А если конкуренты используют что-то более модное? Пользователю безразлично, на чём собран продукт, — ему важно, что он работает быстро и без сбоев. Модный стек сам по себе не даёт ни одного преимущества на рынке, зато может добавить рисков.

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

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

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

Коротко о главном

«Скучные» технологии — это не про отказ от развития, а про уважение к чужим деньгам, времени и нервам. Зрелые инструменты дают предсказуемость, поддержку, лёгкий найм и спокойную эксплуатацию — всё то, что определяет реальную стоимость продукта на дистанции. Новое я беру тогда, когда у него есть конкретная причина и управляемый риск, а не потому, что так делают все. Моя работа — отличить одно от другого и объяснить выбор владельцу человеческим языком. Если вам нужен такой трезвый взгляд на фундамент вашего продукта, я готов помочь разобраться без снобизма и без погони за модой.