Переводы

Вам не нужна вся эта инфраструктура

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

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

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

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

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

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

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

YAGNI

В 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 комментария

  1. Спасибо, получила массу ценной информации. Но есть практический вопрос, как навести порядок в текущем проекте, например я пришла на проект руководителем а там бардак по стеку. Как вариант конечно переписать. Конечно переписывание дело хлопотное — когда программист смотрит на программу другого программиста ему всегда кажется — а че там я бы переписал все лучше.
    С другой стороны есть уже работающий прототип и как минимум не придется переписывать по сто раз как это бывает когда все с нуля. Да и переписывать можно впаралель. а потом просто перегнать данные. С другой стороны за ними надо проверять ещё кучу всего. Вообще толку пока с наших программистов не было, почему сразу не могли написать все чтобы не переделывать. Или они по каким-то причинам не могут работать под руководством женщины-руководителя? С женщинами кстати мне работать лучше — они как то ответственнее и порядочнее. Единственный случай, когда тяжело — если сильный гормональный дисбаланс в возрасте, и женщина не корректирует его мед.препаратами. У мужчин такой кризис тоже есть — но он в подростковом возрасте, мало кто возьмёт подростка на работу, и вам точно будет тяжело с ним работать

    1. Спасибо, получила массу ценной информации. Но есть практический вопрос, как навести порядок в текущем проекте, например я пришла на проект руководителем а там бардак по стеку. Как вариант конечно переписать. Конечно переписывание дело хлопотное — когда программист смотрит на программу другого программиста ему всегда кажется — а че там я бы переписал все лучше.

      Это синдром «not invented here» — каждый разработчик думает, что сделал бы лучше. К сожалению, мало когда это соответсвует действительности. Тем не менее, рефакторинг — важная часть работы команды.

      С другой стороны есть уже работающий прототип и как минимум не придется переписывать по сто раз как это бывает когда все с нуля. Да и переписывать можно впаралель. а потом просто перегнать данные.

      Вот тут много ключевых моментов

      1. Работающая вещь уже приносит прибыль, поэтому надо подумать о том, насколько переписывание будет выгодно для компании
      2. Переписывать в параллель — не такая уж и простая задача. Часто в легаси проектах существует множество сильных связностей, которые тянут части для рефакторинга по длинной цепочке.
      3. Перегнать данные — туда же.

      С другой стороны за ними надо проверять ещё кучу всего.

      Вот тут уже ближе к правде.

      Вообще толку пока с наших программистов не было, почему сразу не могли написать все чтобы не переделывать.

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

      Или они по каким-то причинам не могут работать под руководством женщины-руководителя? С женщинами кстати мне работать лучше — они как то ответственнее и порядочнее. Единственный случай, когда тяжело — если сильный гормональный дисбаланс в возрасте, и женщина не корректирует его мед.препаратами. У мужчин такой кризис тоже есть — но он в подростковом возрасте, мало кто возьмёт подростка на работу, и вам точно будет тяжело с ним работать

      У профессионала не должно быть пола. И пол не должен становиться причиной или аргументацией. Руководитель — это профессия, а не половая принадлежность. И если человек не может завоевать авторитет команды, то ему надо работать над своими скилами, а

        не полагаться на то, что пол А недооценён полом Б.

        Пока я вижу то, что Вам явно не достаёт процессов разработки в команде. Что бы я порекомендовал:

      1. Начните с покрытия функционала тестами. Так при дальнейшем рефакторинге Вы сможете увидеть, что что-то идёт не так (тесты просто будут «краснеть»)
      2. Задумайтесь о том, как работает команда. Как им приходят задачи? С какой целью они делаются? Какая вообще стратегия у компании и как она проецируется на команду?
      3. Не бойтесь нанимать внешних консультантов для постоения процессов и аудита. Это отличная инвестиция в будущее. К тому же часто не такая уж и дорогая.
      4. Рефакторинг должен входить в планирование наряду с простыми задачами. По сути — это технический долг. Вы должны понимать, сколько занимает та или иная переделка, как она будет тестироваться и запускаться, как определить, что она уже сделана. И рефакторинг должен быть обоснован — надо чётко понимать, что даст переход на новый фреймворк/бд/архитектуру/вписать свой вариант.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *