Ложная дихотомия монолита и микросервисов

Текущая война: монолит против микросервисов

«Во многих отношениях микросервисы — это зомби-архитектура. Еще один штамм интеллектуальной заразы, который просто отказывается умирать. Он пожирает мозги с темных времен J2EE (кто-нибудь помнит удаленные серверные бины??) через безумие WS-Deathstar и теперь в форме микросервисов и serverless.»

— Дэвид Хейнемайер Ханссон (источник)

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

Ваша позиция

На чьей вы стороне? Команда микросервисов или команда монолита? Что, если я скажу вам, что это различие — своего рода фантазия, и люди сражаются за вымысел: микросервисы против монолита — это лишь часть более масштабной истории.

Статья от AWS была воспринята как доказательство того, что компания (долгое время выступавшая за микросервисы) сделала разворот и вернулась к монолиту.

Несмотря на заголовок, призванный привлечь внимание, статья, похоже, рассказывает о переходе от функций как услуги (FaaS) к тому, что теперь можно считать архитектурой микросервисов, если не распределенным приложением с сервисами, которые больше, чем «микро» (как бы вы это ни определяли).

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

Мы все хотим сосредоточиться на самом важном: делать то, что лучше для наших клиентов. Выбор стороны в дебатах о микросервисах и монолите мешает этому. Иногда нам нужны микросервисы. Иногда нам нужен монолит. (Я пока не убежден, что мне когда-либо понадобится FaaS, но я держу ум открытым.) Чаще всего мы оказываемся где-то между этими крайностями.

Почему мы боимся микросервисов?

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

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

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

Возможно, часть страха связана с воспринимаемой сложностью. Я думаю, что это большая часть проблемы. Люди естественно боятся (или, по крайней мере, избегают) сложности. Я говорю о воспринимаемой сложности, потому что сложность присуща не только микросервисам. Каждый монолит со временем станет сложным — просто нужно дать ему время. В случае с микросервисами сложность сразу видна, и мы должны справляться с ней на ранних этапах. В своей книге «Bootstrapping Microservices» я называю это «переносом боли вперед» в процессе разработки, чтобы с ней было легче и дешевле справляться.

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

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

Почему микросервисы кажутся такими сложными?

«Вы должны быть достаточно высокими, чтобы использовать микросервисы.»

— Мартин Фаулер (источник)

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

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

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

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

Это просто проблема масштабирования?

«Если вы не можете построить монолит, что заставляет вас думать, что микросервисы — это ответ?»

— Саймон Браун (источник)

Реальная проблема с микросервисами заключается в том, что они увеличивают наши существующие проблемы?

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

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

Микросервисы масштабируются не только для производительности и команды разработчиков; они также масштабируются по сложности. Если вы изо всех сил пытаетесь построить и поддерживать монолит, переход к микросервисам не поможет вам.

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

Я считаю, что микросервисы масштабируются не только для производительности и разработки; они также масштабируются по сложности. Микросервисы имеют свои преимущества, но они не лишены затрат.

Стоимость микросервисов

«Микросервисы — это не бесплатный обед.»

— Сэм Ньюман (из книги «Building Microservices»)

Что на самом деле представляют собой микросервисы? Зачем нам разделять наше приложение на отдельные сервисы?

Есть несколько хорошо известных преимуществ:

Но преимущества — это не вся история. Есть также затраты, которые необходимо учитывать:

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

Управление сложностью

«Микросервисы позволяют непрерывно развертывать большие и сложные приложения.»

— Крис Ричардсон (источник)

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

Да, вы правильно поняли: микросервисы — это не причина сложности, а средство борьбы с ней.

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

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

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

Спектр возможностей

«Нет одного архитектурного паттерна, который подошел бы всем.»

— Доктор Вернер Фогельс (источник)

Я задал вам вопрос в начале этой статьи. Вы за команду микросервисов или за команду монолита?

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

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

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

Уменьшение отдачи от инвестиций

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

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

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

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

Есть веские причины, по которым мы не хотим двигаться до конца к идеальным микросервисам. (Для начала, кто решает, что такое идеал?) По мере продвижения вправо мы начнем видеть большие выгоды. Но по мере дальнейшего продвижения отдача от инвестиций будет уменьшаться. Чем больше мы движемся в сторону меньших сервисов, тем больше затраты будут перевешивать преимущества. В реальном мире (а он грязный и сложный) трудно, если не невозможно, достичь чьего-либо представления об идеальных микросервисах. Но это не значит, что движение в этом направлении не помогает.

Гибридная модель

Если нам не нужно двигаться до конца к микросервисам, то где остановиться? Ответ — где-то посередине, где есть набор компромиссов, которые улучшают скорость и возможности разработки, и где затраты на разработку не превышают преимуществ.

Мне нравится думать о чем-то среднем как о лучшем из обоих миров. Да, у нас может быть монолит (или несколько монолитов), окруженный созвездием микросервисов. Являюсь ли я еретиком, занимая такую прагматичную позицию? Практическая польза заключается в том, что я могу сочетать преимущества монолита с преимуществами микросервисов. Удобство и простота монолита для большей части кодовой базы и гибкость, масштабируемость и другие преимущества микросервисов, которые я могу использовать, когда это необходимо, создают идеальную среду. Я также могу постепенно извлекать отдельные микросервисы из монолита, когда становится очевидным, что определенные функции или задачи могут выиграть от этого.

Гибридная модель — не новая идея. Это то, как часто выглядит реальный мир (где-то посередине), несмотря на споры, которые продолжаются в интернете.

Дэвид Хейнемайер Ханссон (очень сильно за команду монолита) даже, кажется, одобряет эту идею, которую он называет «Архитектура Цитадели».

Размер действительно имеет значение?

«Возможно, префикс "микро" здесь вводит в заблуждение. Это не обязательно "маленькие" в смысле "крошечные". Размер на самом деле не имеет значения.»

— Бен Моррис (источник)

Чем меньше наши сервисы, тем более «микро» они становятся, тем менее полезными они будут, и тем больше их нам понадобится. Уровень сложности возрастает по мере уменьшения размера наших сервисов и увеличения их количества.

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

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

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

Так что давайте перестанем спорить о размере наших сервисов и начнем говорить о «правильно размерных» сервисах, то есть о том, какой размер подходит для нашей ситуации — размер монолита или что-то ближе к меньшему концу спектра. Наши сервисы, независимо от их размера, должны быть организованы вокруг нашего бизнеса и соответствовать нашему домену. Размер — это почти второстепенная мысль; важна общая организация.

Речь не о том, чтобы сделать наши сервисы как можно меньше. За определенной точкой уменьшение размера сервисов становится контрпродуктивным. Чем они меньше, тем больше им нужно общаться с остальной системой для выполнения работы. Чем больше они общаются, тем больше мы платим за сетевые издержки. Не говоря уже о том, что становится намного сложнее понять, кто с кем разговаривает. Нам нужен хороший баланс между размером сервиса и тем, насколько «болтливы» наши сервисы (спасибо Дэмиену Макленнану за термин «болтливый»).

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

Не бойтесь менять свое мнение

«Просто чтобы быть честным — я делал это раньше, переходил от микросервисов к монолитам и обратно. В обоих направлениях.»

— Келси Хайтовер

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

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

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