Переводы

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

Rating: 5.0/5. From 3 votes.
Please wait...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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