Принимайте архитектурные решения на основе достоинств, а не эмоций

Сознательно или подсознательно, у всех нас есть любимчики в жизни. Что касается меня, я люблю Nike и буду покупать только их, когда речь идет о спортивной обуви.

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

Я хочу, чтобы индустрия отказалась от этой привычки, и в этой статье я объясню, почему и как.

Реальный пример выбора фаворитов

Это может показаться очевидным, но я хочу подчеркнуть суть: принятие решений, основанных исключительно на ваших симпатиях и антипатиях, приведет к худшему решению.

Когда я иду в магазин за парой Nike, это эмоциональная покупка. Я покупаю их, потому что люблю их, а покупка новой пары приносит мне радость. Я выбираю пару, которая бросается в глаза и хорошо сидит, и вперед.

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

Соломинка, которая сломала спину верблюду

Недавно статья от команды Prime Video взорвала интернет и, в частности, Twitter. Сама статья интересна, поскольку показывает, как команда развивала свою архитектуру по мере того, как росло их понимание предметной области, и увеличивалась пропускная способность, с которой работал их сервис.

Из статьи несколько выводов:

  • Serverless — отличная архитектура для быстрого создания и прототипирования сервиса.
  • Однако в масштабе его запуск становится все более дорогим, особенно если вы сильно полагаетесь на Step Functions и S3.
  • Таким образом, переход на ECS снизил затраты на 90 % и упростил их архитектуру за счет удаления хранилища данных в S3 в пользу хранилища в оперативной памяти.

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

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

Почему? Потому что у всех есть любимчики. Об этом свидетельствовал тот факт, что люди поспешили заявить, что монолиты — лучший выбор, а микросервисы — это плохо, хотя при чтении самой статьи было ясно, что сервис больше похож на микросервис.

Это редко правильно или неправильно в архитектуре программного обеспечения

Несколько лет назад я посетил семинар Нила Форда. В рамках этого семинара, посвященного архитектуре программного обеспечения, на одном из слайдов была цитата, которая запомнилась мне:

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

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

Все сводится к проблемному пространству и конкретному контексту в данный момент времени с точки зрения того, какое решение является лучшим. В случае с Prime Video они хотели быстро выйти на рынок и доказать, что их решение решает проблему, поэтому они выбрали бессерверное решение из-за его высокой производительности и быстрой скорости разработки.

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

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

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

Как принимать лучшие архитектурные решения

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

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

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

Во-вторых, расширьте свои знания и убедитесь, что вы понимаете некоторые из основных стилей архитектуры программного обеспечения, которые преобладают в отрасли. Я нашел Основы архитектуры программного обеспечения отличным ресурсом для повышения уровня своих знаний об архитектуре программного обеспечения. Для бессерверных приложений я рекомендую Основы AWS: создание бессерверных приложений на Coursera.

Наконец, вам нужна испытанная структура, которая поможет принимать архитектурные решения. По большей части в индустрии в наши дни есть довольно стандартный способ сделать это: Отчеты об архитектурных решениях (ADR).

Он предоставит шаблон для описания контекста и области проблем, в которой вы работаете, затем список вариантов с плюсами и минусами и, наконец, раздел, в котором изложено, почему вы приняли решение, которое вы сделали. Когда другие просматривают ADR, это дает вам наилучшие шансы убедиться, что вы принимаете наилучшее решение.

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

Моя книга Создание программного обеспечения с помощью современных методов построения диаграмм уже вышла!

Вы можете научиться создавать диаграммы, чтобы передавать информацию более прямо и ясно, чем слова, и использовать их для создания лучшего программного обеспечения. Используя только текстовую разметку на базе Mermaid, создавайте содержательные и привлекательные диаграммы для документирования своего домена, визуализируйте потоки пользователей, раскрывайте архитектуру системы на любом желаемом уровне и многое другое!