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

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

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

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

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

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

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

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

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

«Вы должны быть высококвалифицированными профессионалами, чтобы пользоваться микросервисами» (Мартин Фаулер).

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

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

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

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

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

«Если вы не можете построить монолит, почему вы думаете, что микросервисы — это ответ?» (Саймон Браун)

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

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

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

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

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

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

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

«Микросервисы — это не бесплатный обед». Сэм Ньюман (Building Microservices)

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

Есть ряд известных преимуществ:

Но преимущества – это еще не все. Также необходимо оплатить расходы:

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

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

«Микросервисы обеспечивают непрерывное развертывание больших и сложных приложений» (Крис Ричардсон).

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

Да! Я сказал это: микросервисы — это не причина, а лечение сложности.

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

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

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

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

«Не существует одного архитектурного образца, который мог бы управлять ими всеми» (Доктор Вернер Фогельс).

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

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

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

Убывающая отдача от инвестиций

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

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

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

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

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

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

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

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

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

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

«озможно, приставка «микро» здесь вводит в заблуждение. Это не обязательно слово «маленький», как слово «маленький». Размер на самом деле не имеет значения» (Бен Моррис).

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

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

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

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

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

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

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

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

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

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

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

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