Карго-культ микросервисов

Перевод: The microservices cargo cult
Автор: Ставрос Корокитакис (Stavros Korokithakis)

"Всё сделано правильно. Форма совершенна. Он выглядит точно так же, как и раньше. Но он не работает."

Микросервисы - это чудо. Мы знаем это, потому что об этом говорят все последние истории успеха. Новости наполнены историями о том, как люди берут огромную монолитную систему, разбивают её, добавляют веб-API и наслаждаются всеми выгодами.

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

Прежде чем продолжить, я хочу разъяснить, что я не заявляю о том, что микросервисы не работают. Как и везде, есть достоинства и недостатки, поэтому я хочу рассказать о недостатках, потому что достоинства уже достаточно освещены.

Карго-культы

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

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

Достоинства

Давайте начнём с рассмотрения достоинств.

• Масштабируемость: Это главное. Поскольку микросервисы малы и самодостаточны, их можно разместить на выделенном сервере, если это будет необходимо. Можно поделить данные между экземплярами, распределять между ними нагрузку и настраивать любым способом, который имеет значение для вашего приложения.
  Вы также можете принять решение хранить данные в каждом из сервисов, воспользовавшись таким хранилищем данных (и даже языком программирования или технологией), которое лучше подходит в данном конкретном случае.
• Более понятная архитектура: Каждый сервис имеет чётко определённые границы, которые обычно неприкосновенны. Больше нельзя обращаться к приватным данным лишь потому, что это удобно. Каждый сервис теперь скрывается за собственным API и не доступен иным образом.
• Независимое развёртывание: Поскольку каждый сервис отделён, при необходимости его легко можно развернуть даже несколько раз за день. Это может способствовать увеличению времени бесперебойной работы.
• Меньшая кодовая база: Поскольку код небольшой, в нём проще разобраться. Назначение каждого сервиса и его интерфейс чётко определены, что позволяет кому-нибудь быстрее прочитать код и разобраться в нём, а стало быть - быстрее изменять, расширять и поддерживать его.

Недостатки

• Сложность: Сразу на порядок увеличивается количество работы, выполняемой серверами. Между ними появляются промежуточные прослойки, работающие через сеть, что на порядок увеличивает общее количество развёртываний и нагрузку на администраторов, а количество сервисов, требующих мониторинга, увеличивается во много десятков раз.
  Также появляется масса дополнительного кода, выполняющего сериализацию и десериализацию данных, передаваемых между сервисами. И хотя обычно его суммарный объём не велик, ничего хорошего в этом нет.
• Накладные расходы: Все эти разнообразные хранилища данных, преобразования данных и сетевые вызовы не обходятся даром. Лично мне встречалось замедление порядка 1000% из-за перехода на микросервисы (да, в десять раз медленнее).
• Сегрегация данных: Поскольку все данные теперь хранятся в разрозненных хранилищах данных, нужно следить за их согласованностью. Если в монолитной системе можно было обойтись простым каскадным удалением, то теперь нужна сложная симфония зависимостей, вызовов и перепроверок. Это очень похоже на использование не реляционного хранилища данных. Если у вас есть опыт работы не реляционными хранилищами и вы успешно с ними справлялись, то проблем возникнуть не должно.

Критическая оценка

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

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

Стоит ли вам использовать микросервисы?

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

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

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

Простой способ принятия решения

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

Диаграмма для принятия решений, нужны ли вам микросервисы

Эта диаграмма ответит на все ваши вопросы о микросервисах.

Это немного щекотно.

Заключение

Не начинайте с микросервисов, это сложный способ, который вначале не требуется.

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

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

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

Примечания переводчика

Сам довольно скептически отношусь к идее микросервисов, по многим причинам.

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

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

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