Кажется, предыдущая статья буквально взорвала мой блог. Честно говоря, ни одна статья ещё не вызывала такую бурную реакцию. Это не может меня не радовать, а я хочу поблагодарить всех, кто принял и примет участие в обсуждении!
Я обратил внимание на то, что в комментариях многие подняли тему неуместности применения некоторых технологий и подходов. И по счастливому стечению обстоятельств на 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), дождитесь, пока технология и её понимание созреют, прежде чем, очертя голову, бросаться в реализацию прекрасного нового мира.
Вам не нужна вся эта инфраструктура: 2 комментария
Спасибо, получила массу ценной информации. Но есть практический вопрос, как навести порядок в текущем проекте, например я пришла на проект руководителем а там бардак по стеку. Как вариант конечно переписать. Конечно переписывание дело хлопотное — когда программист смотрит на программу другого программиста ему всегда кажется — а че там я бы переписал все лучше.
С другой стороны есть уже работающий прототип и как минимум не придется переписывать по сто раз как это бывает когда все с нуля. Да и переписывать можно впаралель. а потом просто перегнать данные. С другой стороны за ними надо проверять ещё кучу всего. Вообще толку пока с наших программистов не было, почему сразу не могли написать все чтобы не переделывать. Или они по каким-то причинам не могут работать под руководством женщины-руководителя? С женщинами кстати мне работать лучше — они как то ответственнее и порядочнее. Единственный случай, когда тяжело — если сильный гормональный дисбаланс в возрасте, и женщина не корректирует его мед.препаратами. У мужчин такой кризис тоже есть — но он в подростковом возрасте, мало кто возьмёт подростка на работу, и вам точно будет тяжело с ним работать
Это синдром «not invented here» — каждый разработчик думает, что сделал бы лучше. К сожалению, мало когда это соответсвует действительности. Тем не менее, рефакторинг — важная часть работы команды.
Вот тут много ключевых моментов
Вот тут уже ближе к правде.
Команда разработки — это инструмент. И толк он будет приносить тогда, когда его применяют правильно. Я не буду судить о Вашей команде, так как совершенно не знаю о том, как построена разработка.
«Толк» должен быть обоснован чем-то ощутимым. Только, пожалуйста, не бросайтесь вводить KPI и контроль времени. Подумайте о процессах постановки и выполнения задач, о понимании бизнесом ценностей строящегося ПО.
У профессионала не должно быть пола. И пол не должен становиться причиной или аргументацией. Руководитель — это профессия, а не половая принадлежность. И если человек не может завоевать авторитет команды, то ему надо работать над своими скилами, а
не полагаться на то, что пол А недооценён полом Б.
Пока я вижу то, что Вам явно не достаёт процессов разработки в команде. Что бы я порекомендовал: