Хорошие монолиты. Простая архитектура лучше всего

Критика монолитов стала в индустрии обычным делом. Многие считают каким-то очевидным фактом, что распределённые (микро-)сервисы всегда лучше монолитных приложений, написанных от начала до конца как цельный неделимый независимый кусок.

Если вспомнить, то идея модульных микросервисов всплыла около десяти лет назад на подъёме идеологий гибкой разработки (Agile) и DevOps. Эти мощные концепции сильно повлияли на индустрию.

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

Для начала, чтобы не путать понятия:

Монорепозиторий — стратегия разработки, когда весь код хранится в одном репозитории. Это стандартная практика для Google ^[1], Twitter, Microsoft и многих других компаний ^[2].

Монолит ^[3] (монолитное приложение) — одноуровневое, самодостаточное и независимое приложение, которое не ставит модульность компонентов в основу разработки.

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

• Монолиты — всегда монорепозитории.
• Монорепозитории — не всегда монолиты ^[4]. Внутри монорепо могут жить и развиваться множество независимых модулей, которые по определённым причинам не выносят в отдельные репозитории (например, большим корпорациям так удобнее), вроде такого:

  .
  ├── README.md
  ├── lerna.json
  ├── package.json
  ├── packages
  │   ├── cli
  │   ├── component-button
  │   ├── eslint-config
  │   ├── generic-box-sizing-reset
  │   ├── object-aspect-ratio
  │   ├── object-container
  │   ├── object-grid
  │   ├── ...
  │   └── utility-width
  └── test
      ├── ...
      └── test.sh

Достоинства монорепозиториев ^[5]:

• Единый источник истины. Изменения кода атомарны, нет необходимости синхронизировать схемы в нескольких репозиториях.
• Видимая стоимость изменений. Внесение изменений в код требует совместимости со всем остальным кодом.
• Совместное и повторное использование кода. Значительно проще находить нужный код повторно использовать существующие компоненты. Это также включает версионирование и согласование зависимостей в рамках всей организации.
• Буст сотрудничества. Исчезает бюрократия с разрешениями и согласованием нескольких репозиториев. Просто изменяем код и получаем отзывы!

Конечно, есть и негативные моменты. Например, мой код может сломаться от изменений, которые внёс кто-то другой.

В «правильном» монорепозитории рекомендуют ^[5] изменить процедуру CI для герметичной сборки ^[6], улучшить качество тестов и следить за конфликтами слияний, может даже сформировать группу разработчиков для этой работы. Такой монорепозиторий не скатится в монолит.

▍ Простой монолит — это хорошо

Сторонники монолитов неоднократно подчёркивают, что их выбор обусловлен простотой. То есть простая архитектура приложения, простая разработка по классике — это идеальный вариант. Особенно в начале стартапа. Монолит — это простая архитектура, которая решает проблемы простым способом ^[7]. О преимуществах монолита говорит ^[8] Дэн Лу (Dan Luu), технический директор команды из 70-ти инженеров, разработавших платёжное приложение Wave:

Среди больших, но эффективных монолитов называют StackOverflow ^[9] (входит в топ-100 сайтов интернета), Slack (почти PHP-монолит ^[10]), Booking, GitHub, Shopify, Stripe (монолит, распределённый в подах k8) и многие другие ^[11]. Это успешные продукты с точки зрения бизнеса — стоимостью более миллиарда долларов. С точки зрения эффективности или производительности могут быть вопросы, но это уже субъективные вещи. Всё-таки стоимость бизнеса — некий объективный численный показатель, который должен коррелировать с пониманием успешной софтверной разработки.

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

То есть простой монолит — вполне достаточный продукт в большинстве ситуаций. В то же время на конференциях и в СМИ этот простой и скучный тезис редко становится темой обсуждения. Ведущие инженеры и специалисты любят разбирать распределённые архитектуры из микросервисов, балансировку нагрузки по кластерам и другие сложные вещи. Чем сложнее архитектура — тем круче доклад. Банальные простые вещи не очень подходят для презентации, хотя это 99% задач в реальном мире.

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

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

▍ Микросервисы в реальной жизни

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

Представим, что Netflix использует микросервисную архитектуру. Как будет выглядеть эта воображаемая инфраструктура в самом упрощённом виде? Примерно так ^[12]:

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

▍ Сложные системы быстрее падают

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

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

В физике чем сложнее система — тем выше диссипация (рассеяние) энергии, то есть выше скорость деградации этой системы. Отсюда можно сделать вывод, что сложные системы быстрее падают ^[13].

Это так называемый утёс Сенеки ^[14], когда за долгим и медленным ростом следует резкий обвал. Чем более сложной и продвинутой была система, чем дольше продолжался рост, тем быстрее происходит деградация.

Утёс Сенеки обычно упоминают в контексте падения цивилизаций или социальных институтов ^[15]. Но мы видим его во многих других явлениях — бизнес, инвестиции, брак, здоровье, репутация, экономическое развитие и др. К сожалению, падение почти никогда не происходит настолько же плавно, как предыдущий рост. Зачастую всё рушится как карточный домик. Это касается и сложных программных систем ^[16].

«EKS отменяется в конце месяца для Omega Star, но Omega Star по-прежнему не поддерживает таймстампы ISO...» Из вирусного видео «Микросервисы» ^[17]

Есть ещё другое следствие. Чем сложнее система — тем больше энергии требуется на поддержание её состояния. То есть в контексте программных систем это означает стоимость поддержки и обслуживания. Более простые системы легче обслуживать. В идеале простой монолит на Node/Express ^[18] без критичных зависимостей годами спокойно работает — и не требует особого обслуживания.

То же самое можно сказать и о простом наборе микросервисов, который заменяет сложный монолит. Главное здесь — в каком направлении мы двигаемся, увеличиваем сложность или упрощаем систему?

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

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

Есть ещё такой принцип — выбирать скучную технологию ^[19], а не красивую/интересную. Если она вызывает эмоциональный отклик, это опасный знак. Всех тянет на красивые блестящие штучки, но скучная технология — это синоним предсказуемости. Её недостатки хорошо известны, никаких сюрпризов не ожидается.

▍ Монолиты — наш друг

Инженеры любят сложность, это нормально. Сложные вещи захватывают наше воображение. Ведь решать головоломки — это самое интересное, что может быть в мире, не правда ли? Но всё это красиво в теории. Но в продакшне зачастую именно монолиты — наш друг ^[12]. Суровая правда жизни.