Монолит и микросервисы

Всё чаще от руководителей проектов требуют разбираться в архитектуре вообще и в микросервисной архитектуре в частности (платить зарплату архитектора никто не планирует, не обольщайтесь). Попадаются технические проекты по распиливаю монолита. В общем, тема актуальная.

Перед тем, как читать эту статью, прочтите, пожалуйста, пост про кубер и докер.

Начнём с монолита, как более древнего архитектурного подхода.

Монолит

Помните, как в универе, на «Высокоуровневых методах разработки и проектирования» нам рассказывали, как сделать модульное приложение? Разбиваем приложение на модули, потом делаем тело программы, которая будет эти модули последовательно вызывать и оперировать с данными, которые поставляют эти модули.

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

Как выглядит архитектура современного монолитного приложения? Примерно так:

То есть, присутствует разделение на слои, но все эти слои представляют собой одну сплошную сущность, общающуюся с БД.

Плюсы монолита

• Его технически проще разработать.
• Быстрее старт разработки. Обилие готовых решений, которые не очень трудно адаптировать под конкретные требования. Прочтите, пожалуйста, статью о фреймворках.
• В ходе работы у него нет затрат на «логистику» и перемещение данных между компонентами. Выше производительность.
• Все компоненты продукта общаются с единой базой данных, не нужно придумывать механизмы обмена данными.
• Нет «сквозных» проблем и багов, ничего не вылезает «на стыках».
• В целом, проще тестировать.

Минусы монолита

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

Каким приложениям подойдёт монолитная архитектура

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

Микросервисы

Следующий этап развития архитектуры. Весь программный комплекс разбивается на независимые компоненты (микросервисы), каждый из которых реализует самостоятельную функцию. Зачастую у каждого микросервиса своя база данных. Микросервисы могут обмениваться данными между собой.

Подход относительно свежий, появился в 2010-х годах, одновременно с развитием гибких подходов к разработке и методологии девопс.

Типичная микросервисная архитектура выглядит так:

Плюсы микросервисов

• Широкие возможности для масштабирования разработки. В предельном случае, вы можете нанять отдельную команду на каждый микросервис и пилить их одновременно, команды не будут конфликтовать вообще, лишь бы был грамотный архитектор, декларирующий методы обмена инфой между микросервисами.
• Намного проще осуществлять масштабирование продукта под возрастающую нагрузку.
• Упрощённое развёртывание. Если у вас обновится библиотека, используемая одним микросервисом, придётся переразвернуть один микросервис, а не всё приложение целиком.
• Если контролировать объём микросервисов и не давать им расползаться, по мере роста функциональности продукта, сложность разработки не будет возрастать.
• Отказоустойчивость. Классический пример — главная страница Яндекса. Если упадёт микросервис погоды, страница не рухнет целиком, просто не будет отображаться виджет погоды.
• Независимость от технологий и фреймворков. Мы сможете подбирать язык, библиотеки и фреймворк, оптимальные под задачу. В предельном случае, вам никто не мешает реализовать микросервис на ассемблере, если это полезно для продукта и у вас есть специалист. У вас может быть каждый микросервис на своём языке программирования и всё равно, всё это будет вместе нормально работать.

Минусы микросервисов

• Сложность разработки первой версии продукта. В отличие от монолита, у вас уйдёт много времени на проектирование архитектуры и методов взаимодействия микросервисов.
• Затраты на логистику между микросервисами. Они должны будут обмениваться данными, следовательно, есть требования к качеству каналов обмена, зависимость от работы этих каналов.
• Сложность тестирования возрастает многократно. Тут без автотестов никак.

Каким приложениям подойдёт микросервисная архитектура

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

Когда есть смысл перейти с монолита на микросервисы

Если кратко — когда плюсы микросервисов начинают ощутимо перевешивать. Личный опыт. В одной крупной медицинской компании мы столкнулись с тем, что существующая веб-платформа на Битриксе превратилась в страшное легаси. Любая доработка, даже самая невинная стала занимать много недель. С одной стороны, тут дело в самом Битриксе, с другой — в отсутствии архитектора, который бы контролировал разрастающийся продукт.

В общем, приняли решение писать с нуля новую платформу на Symfony и Реакте, используя именно микросервисную архитектуру.

В целом, показания для распила монолита такие:

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

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

Давайте ещё раз сравним подходы с точки зрения разных аспектов разработки:

Аспект	Монолит	Микросервисы
Разработка и развёртывание.	Одна кодовая база. Простота разработки первой версии и развёртывания итогового продукта.	Децентрализованная разработка, каждый микросервис может пилиться изолированной командой. Сложное развёртывание стартового решения.
Масштабируемость и производительность.	Приложение масштабируется только целиком, возможно избыточное использование ресурсов.	Приложение можно масштабировать как угодно, при необходимости добавляя мощности отдельным микросервисам.
Обслуживание и расширяемость.	Единая кодовая база. Легче разобраться, легче обслуживать.	В независимые микросервисы проще добавлять новую функциональность, расширяя существующие микросервисы или создавая новые.
Технологическое разнообразие и автономность.	Привязка к единому стеку технологий.	Каждый микросервис может быть написан на том языке, который лучше подходит под задачу.
Отказоустойчивость.	Единая точка отказа, приложение падает целиком.	Можно так спроектировать архитектуру, что при падении одного или нескольких микросервисов, приложение будет продолжать устойчиво работать.
Взаимодействие.	Приложение вызывает функции из единого пространства и оперирует единой средой данных.	Нужна логистика между микросервисами.

В целом, это всё, что пиэму нужно знать о микросервисной и монолитной архитектуре. А ещё, есть такой зверёк как бессерверная архитектура. О ней поговорим в следующих постах. Какая лучше? Зависит от задач. Используйте инфу из этой статьи и слушайте своего архитектора.