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

Я обратил внимание на то, что в комментариях многие подняли тему неуместности применения некоторых технологий и подходов. И по счастливому стечению обстоятельств на Medium.com я наткнулся на статью, которая во многом отражает и моё понимание проблемы оверинжиниринга в проектах средней руки. А потому я с удовольствием спешу поделиться переводом этой небольшой неоднозначной статьи и своими комментариями.

Как Вы запускаете свои web-продукты?

В кластере Kubernetes? Балансировщики нагрузки между географически распределенными облаками? Полностью автоматизированное, сине-зелёный деплой, основанный на метриках, получаемых в реальном времени из пайплайна самого деплоя?

Это всё очень здорово. И если Вы проводите много времени на Хабре или читая свежие статьи от DevOps-волшебников из фирм FAANG, Вы убеждены, что все предлагаемые там вещи абсолютно необходимы для вашего сайта. Но всё это сущий кошмар. Установка всего этого — огромная трата времени. И если Вы не хотите устанавливать и настраивать всё это самостоятельно, то это ещё и ужасно дорого. И даже тогда это все ещё кошмар, а Вы только что заплатили за то, чтобы им обладать.

Есть ли хорошие новости?

Вам всё это не нужно *.
(* вообще-то кое-что нужно … но точно гораздо меньше, чем Вы думаете)

В Twitter Питера Левелса (Pieter Levels) — многократного победителя в номинации «Охота за продуктами года», основателя увеличивающегося списка сайтов, приносящих тысячи долларов дохода в месяц, и в основном бога сообщества инди-создателей — спросили, какую инфраструктуру он использовал для размещения всех своих безумно успешных инди-проектов.

Каков был ответ? Просто … один виртуальный сервер на Linux.

Я не говорю о том, что отлично знаю, какая инфраструктура крутится у Питера на самом деле. Но я почему-то уверен, что там нет сложных скалируемых групп, нет парка дорогих облачных серверов или сложных кластеров Kubernetes.

Ваша цель при запуске продукта — построение продукта, который будет решать проблемы Ваших пользователей. Не строить крутейшие пайплайны развёртывания, или мультизональные геораспредлённые облачные защищённые от ядерной зимы высокодоступные сервера. Я как-то встретился с идеей о том, что каждая минута, потраченная на инфраструктуру — это минута, не потраченная на доставку пользователям новых возможностей. Очевидно, это не стопроцентная истина; Вы не можете доставлять функционал пользователю, если у Вас нет сервера или какого-либо способа перенести свои функции на Ваш сервер (и, желательно, хотя бы ненадолго оставить их там). Но это неплохая идея сама по себе. Вам нужна самая простая и минимально трудоемкая инфраструктура, которая поможет Вам достичь цели.

Когда я строил свой сайд-проект Curated Design Boutique, я потратил часы, устанавливая простые и бесплатные средства непрерывной интеграции и доставки и настраивая пайплайны в них. По коммиту в Git Semaphore CI собирает Docker-образ, загружает образ в реестр контейнеров, затем отправляет его и перезапускает контейнер на моём сервере. Это реально круто. Я чувствовал себя волшебником, когда всё это заработало … и всё это бесплатно! Вообще-то, я хотел написать о том, как сделать такую же сборку самостоятельно, пока не осознал, как много времени я потратил на то, чтобы это получить и какую ценность я доставил этим пользователям (в конце концов: как много денег я получил на свой банковский счёт) — полный ноль. Разумеется, автоматическая сборка и выгрузка в реестр — это великолепно! Это спасает меня от часто повторяющихся ошибок. Но действительно трудоемкой и ненадёжной частью системы было автоматическое развертывание. Запуск сценария `docker-compose` на моем сервере вручную ничего не стоит (и я обращаю на это внимание, поэтому мне не нужна дополнительная инфраструктура автоматического мониторинга, которая будет говорить мне, когда я все испортил).

Вашим пользователям неважно, как Ваш код попадает на сервер. 99.9% времени им также неважен Ваш крутой высокодоступный набор систем. Понятно, если Вы находитесь на уровне FAANG или являетесь авторитетным источником, где 0,1% простоя приводят к огромным потерям денег на Вашем счёте, всё это прекрасно. У Вас есть средства, чтобы сделать всё «правильно». Ваша крутая полностью автоматизированная CD система экономит Вам тысячи, а то и миллионы долларов в год. Но масштаб простого разработчика (“Эй, посмотрите какую крутую штуку я построил… пожалуйста, ну, пожалуйста, посмотрите на неё”) — масштаб огромного количества сайтов в сети Интернет — эта 0.1% пренебрежительно мала.

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

Короче говоря, воплощая следующую идею Unicorn-проекта в код, помните — Вам не нужна вся та инфраструктура, которую вы запланировали.

Комментарии к статье

При невдумчивом чтении статья может сформировать очень категоричный взгляд на вещи, вплоть до выкатки кода методом копирования файлов по FTP вручную («ну а чё, работает же!»). Автор довольно мало внимания уделил вопросу правильного определения достаточности выбираемых решений на том или ином проекте. Хотя, и статья не про это, а про старый добрый YAGNI.

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

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

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

Ни в коем случае не надо отрицать всё новое, модное и крутое. Но нужно относиться к нему с осторожностью. И если Вы работаете в компании средней руки (давайте на чистоту — таких гораздо больше, чем тех же FAANG), дождитесь, пока технология и её понимание созреют, прежде чем, очертя голову, бросаться в реализацию прекрасного нового мира.