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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Масштабируемость

  • Производительность

  • Команда разработчиков

• Отказоустойчивость

• Независимое (и менее рискованное) развертывание для быстрых циклов разработки.

• Расширение возможностей разработчиков

• Проектирование для одноразового использования

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

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

• Более высокий уровень технических навыков

• Улучшенные системы автоматизации, управления и наблюдения.

• Работа с масштабируемой сложностью

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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