MSA. Микросервисная архитектура, зачем?

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

Почему микросервисы, чем плох монолит?

Давайте быстренько и кратко разберемся. Но сначала нужно сказать о SPA (Frontend) + API (Backend) — это эволюция модульного монолита, с той лишь разницей, что Frontend вынесен уже за пределы монолита, и у нас отдельно существует Backend и Frontend. Также упомянем SOA — была популярна в 2000х и до сих пор существует во многих компаниях. Особенность SOA — это использование универсальной корпоративной шины (ESB) для связи разных сервисов, при этом у нас всё еще присутствует централизация в виде ESB, ведь если ESB будет плохо, то все сервисы пострадают. Мы же рассмотрим две крайности архитектурных решений — самую примитивную архитектуру в виде монолита и вершину эволюции — микросервисы.

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

Вкратце рассмотрим плюсы и минусы обоих подходов.

Минусы монолита:

• Сложность понимания для новых сотрудников и зачастую текущих, ввиду большой кодовой базы и наличия связанностей классов.
• Сложность внесения изменений из-за наличия большой связанности классов внутри кодовой базы. Изменяя один кусок кода вы неизбежно столкнетесь с тем, что нужно изменить код еще в нескольких местах.
• Привязанность к технологическому стеку, т.к. вы не можете очень быстро поменять технологический стек монолита. Например, если он написан на Java, вы не можете просто переписать его на Go или дописать что-то на другом языке программирования.
• Сложность тестирования. Зачастую вы не можете приступить к тестированию, потому что связанный код еще дорабатывает другая команда.
• Ненадежность. Если вдруг произойдет какой-то сбой или утечка памяти в одном из модулей монолита, неизбежно весь монолит упадет.

Плюсы монолита:

• Простота разработки. То есть разобравшись однажды, один разработчик может изменить код во всех слоях монолита: frontend, backend, инфраструктурном слоем.
• Простота развертывания: проще развернуть одно приложение, чем группу микросервисов.
• Меньше требований к компетенциям. Разработчику например не нужно знать как делать реализацию транзакционности (как в случае микросервисов), ему не нужны архитектурные компетенции.
• ACID транзакции. Большое преимущество перед микросервисами, где зачастую у каждого сервиса своя база данных и вероятнее, каждая от разных вендоров.

Минусы микросервисов:

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

Плюсы микросервисов:

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

Даже монолит со структурой «Big Ball of Mud», это неплохая архитектура для стартапов или идеи, которую вы хотите запрототипировать и показать инвестору. Лучше написать плохой код и использовать какую-нибудь простую архитектуру, чтобы показать инвестору ваш проект, чем … Если вы будете несколько недель разбираться с Kubernetes, Kafka, RabbitMQ и ничего не покажите инвестору, соответственно не получите инвестиции и ваш стартап не начнется.

Когда компания уже существует и размер компании не большой, примерно до 100 разработчиков, мы все еще можем использовать монолит или SPA + API. Все могут
эффективно работать в одной кодовой базе, применяя методологию CI/CD, работая с ветками в git, выполняя Merge Requests, Review и т.п. Разработчиков не очень много и работать в одной кодовой базе выгоднее и дешевле, чем расходиться в микросервисы и получать минусы этой архитектуры (сложность правильной декомпозиции, большие трудозатраты на интеграцию, отсутствие транзакционности).

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

Таким образом, микросервисы и монолит — два подхода, которые хороши в своей области, при определенном уровне зрелости компании и/или продукта.

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

Цель внедрения микросервисов (MSA)

Зачастую, если спросить у разработчиков: «Для чего мы внедряем микросервисы?», можно услышать следующие ответы:

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

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

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

Что нужно бизнесу?

Бизнес хочет как можно чаще проверять какие-то гипотезы. Потому что, когда мы делаем какой-то продукт, мы не всегда понимаем чего хочет клиент. Мы делаем эксперименты, предлагаем клиенту одну, вторую, третью функции. И в конечном счете оказывается, что только 1 из 3 функций приносит прибыль компании. Чем чаще мы проверяем гипотезы на клиентах, тем быстрее мы нащупываем рынок и понимаем какие функции нам приносят
деньги. Чем чаще конкурентов вы делаете релизы, тем больше вероятность найти первыми прибыльную функцию. Соответственно клиент будет считать ваш продукт более удобным, более функциональным и клиентская база у вас будет больше.

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