24.12.2019

Структура команды
в MSA

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

В статье я хочу ответить на вопрос о размере микросервиса, опираясь на свой опыт и опыт крупных компаний.

Популярные версии

В разных источниках можно встретить разные мнения по поводу размера микросервиса:

  • Это сервис, в котором не должно быть больше 10k строк кода
  • Сервис такого размера, что его можно переписать на другой язык за 2 недели
  • Сервис такого размера, что его может поддерживать команда из 2 пицц
  • Сервис такого размера, что 1 человек в состоянии осознать все приложение полностью
  • Сервис должен полностью реализовывать свою бизнес-функцию, быть автономным, а размер не так важен


Two Large Pizza team

Очевидные ошибки в размере

На практике я видел такие кейсы:

  • Команда из 6 человек развивает 20 микросервисов. И зачастую такая команда работает неэффективно, так как инфраструктурные издержки на разработку, координацию и выкладку 20 микросервисов съедают большую часть их времени.
  • Система разбита на сервисы настолько мелкозернисто, что ни один из сервисов не отвечает полностью за определенную бизнес возможность. Это приводит к излишним коммуникациям между сервисами. Изменять, проводить рефакторинг, тестирование таких сервисов становится все труднее. В итоге это также негативно влияет на систему.

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

Итоги

Учитывая выше сказанное, мы можем сделать вывод, что физический размер сервиса имеет далеко не первостепенное значение. По этим критериям определять размер микросервиса не стоит:

  • Это сервис, в котором не должно быть больше 10k строк кода
  • Сервис такого размера, что его можно переписать на другой язык за 2 недели

Но крайне важно, чтобы сервис был автономным, самодостаточным и реализовывал полностью определенную бизнес возможность, он может быть совсем не маленьким, но такого размера, что его может эффективно развивать команда из 5-9 человек. При этом команда не должна владеть более чем 1-2 сервисами. Написать огромный монолит таким составом крайне проблематично, поэтому размер команды не явно определяет размер микросервиса.
Размер команды не явно определяет размер микросервиса.
Если члены команды все больше и больше понимают, что не осознают размеров сервиса, который они развивают — это также является той гранью, когда сервис достиг своего максимума и его необходимо декомпозировать.
Эта и другие темы подробно рассмотрены в моем обучающем курсе.