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

Еще в начале карьеры разработчика я услышала и запомнила два забавных определения:

Если над сервисом работает команда, которую можно накормить всего 2 пиццами, то это микросервис

🍕🍕

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

Это сложно назвать определением, хотя про логику замечание валидное 😃

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

Давайте посмотрим, какие определения дают известные авторы:

➡️ Крис Ричардсон (автор книги "Паттерны микросервисов")

Микросервисы — это сервисы, которые:
independently deployable - можно поставлять независимо (без необходимости одновременно выкатывать другие сервисы)
loosely coupled - слабо связаны друг с другом
Обычно они организованы вокруг бизнес-возможностей, а отдельный сервис часто находится в зоне ответственности одной небольшой команды.

➡️ Сэм Ньюман (автор "От монолита к микросервисам", "Создание микросервисов")

Микросервисы — независимо релизящиеся сервисы, смоделированные вокруг бизнес-домена.

➡️ Влад Хононов (автор книги "Изучаем DDD")

У него есть интересная статья про баланс сложности в распределенных системах.

Локальная сложность — сложность внутри отдельного сервиса
Глобальная сложность — сложность связей и зависимостей между сервисами

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

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

Хононов предлагает необычный взгляд:

Микросервис — это сервис с маленьким публичным интерфейсом.

Условно, сервис может содержать 100 тысяч строк кода, но наружу выставлять буквально несколько высокоуровневых операций:

- createOrder()
- cancelOrder()
- getOrder()

Поэтому прямой доступ одного сервиса в БД другого сервиса — антипаттерн: база фактически становится огромным публичным интерфейсом.


➡️ Отличия от монолита

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

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

При этом если наши микросервисы сильно связаны друг с другом, и релиз выглядит так:

Order v5 требует Payment v7
Payment v7 требует Customer v4,
поэтому вынуждены выкатывать всё вместе

то Ньюман и Фаулер называют это распределенным монолитом.

Кто сталкивался, тот сразу вспомнит такие релизы 😂

Нашла еще несколько статей, и во всех можно проследить повторение нескольких вещей:
🔴независимость изменений и деплоя
🔴слабая связанность
🔴осмысленная бизнес-граница

В итоге, если спросят, что такое микросервис, я бы ответила как-то так:

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

Забавно, что на собесах мне такой вопрос ни разу не задавали. А вас спрашивали, что такое микросервис?