Плюсы и минусы микросервисной архитектуры

Всем привет! На связи разработчики IT-компании Creative – Валера и Даниил. Недавно у нас прошел довольно жаркий техмитап, на котором мы в формате pros&cons разбирали тему микросервисов – Даниил топил «за», Валера искал подводные камни. В этой статье мы собрали оба мнения – плюсы и минусы подписаны, соответственно, Д и В. Если у вас есть опыт разработки микросервисной архитектуры, расскажите о нём в комментариях. А ещё напишите, чьи аргументы вам показались более весомыми))

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

Как плюсы и минусы отражаются на архитектуре и разработке?

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

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

(Д) При использовании микросервисной архитектуры все сервисы можно писать на разных языках.

(В) Распределённость систем может приводить к возникновению дедлоков (deadlock) и рейс кондишн (race condition). Стоит также помнить, что в таких системах достаточно сложно контролировать выполнение транзакций и согласованность данных.

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

(В) Изоляция способствует быстроте разработки, но делает сообщение между сервисами сложнее. Также придётся попотеть при тестировании – каждый сервис нужно будет тестить отдельно, как и каждое взаимодействие между ними. На одной машине запускать все эти параллельные процессы будет не слишком удобно.

Как это влияет на эксплуатацию?

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

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

(Д) Можно заниматься простым мониторингом каждого сервиса и отслеживать проблемы в любом месте – например, что-то с шиной или с самим сервисом.

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

(Д) Независимость развёртывания позволяет динамически управлять масштабируемостью сервиса (вертикальной / ресурсной).

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

Почему это выгодно клиенту?

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

(Д) Много облачных решений, поэтому это может быть дёшево.

(В) Неоправданно сложно и дорого, если содержать всё у себя.

Собственно, на этом всё. Спасибо за чтение! Что думаете про микросервисы? Сильно «за» или сильно «против»?