Микросервисы — это хорошо, но до некоторой степени и не для всех команд.

Мы все достаточно читали о микросервисах и преимуществах, которые они приносят.

Большинство говорят о плюсах, таких как увеличение скорости разработки, независимое масштабирование сервисов. О его минусах никто не говорит.

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

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

Вот чему я научился, создавая и поддерживая микросервисы в течение многих лет.

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

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

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

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

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

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

Всегда учитывайте размер вашей команды

Команды, использующие микросервисы, часто имеют больше сервисов, чем количество членов команды. Это не проблема, пока это соотношение не станет 3-4Х.

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

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

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

Кошмар DevOps

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

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

Хорошо спроектированные микросервисы помогают масштабировать сервисы независимо друг от друга и снижать затраты.

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

Управление данными

Когда у вас есть микросервисы, которые взаимодействуют друг с другом, это может сильно усложнить управление данными.

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

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

Обнаружение этих повреждений в данных требует отладки многих служб.

Может стать отладочным адом

Когда взаимозависимые службы не работают должным образом, разработчикам необходимо изучить несколько служб и обмен данными между службами.

Я был в этой ситуации так много раз. Было 3–4 сервиса, которые взаимодействовали друг с другом с помощью очередей. Я знал нужные данные

Прощальные мысли

Я не против микросервисов, но я против создания микросерверов на всякий случай.

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

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

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