https://habr.com/ru/companies/typeable/articles/567430/

Микросервисы начали набирать популярность в 2011-2014 годах, органично заменяя тяжеловесные SOA и монолитные решения

Для MVP не стоит тк важно время

Итак, когда же стоит выбирать микросервисы?

Если:

• цель разработки — среднего размера нетривиальное веб-приложение, состоящее из набора слабосвязанных или полностью изолированных модулей;

• есть критичные требования по устойчивости приложения к нагрузкам и/или поддержке интеграции с внешними сервисами (платежные системы, банки, внешние хранилища и т.п);

• бизнес уже сейчас требует значимого ускорения разработки, планирует выводить на рынок изменения сразу по всем направлениям, и не готов ждать последовательного внедрения ключевых изменений в каждой области;

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

• можно выделить модули, допускающие повторное использование с поддержкой вызова по разнородным каналам (сервисы авторизации и аутентификации, поисковые движки, аудит и т.п);

• бизнес выдвигает требования к блокам системы с различной скоростью, важность быстрого вывода в релиз отдельных блоков также неоднородна;

• есть экономически обусловленная необходимость дальнейших частых изменений в отдельных блоках (следование тренду, маркетинговой стратегии);

• стратегические цели бизнеса требуют, или потребуют в перспективе, точечного горизонтального масштабирования, либо разной скорости изменений в различных точках приложения;

• тактические цели бизнеса требуют внесения множества микроизменений в различные модули системы «на лету» без угрозы падения всего приложения (доступ 24/7 и высокая вероятность багов ввиду сложности системы),

Комунда исследование

63% предприятий ратуют за внедрение микросервисов или уже внедряют их, только 45% явно документируют бизнес-процессы, и это представляет определённую сложность для оценки влияния микросервисной архитектуры на реализацию этих процессов.

При этом основными причинами выбора микросервисной архитектуры компании называют:

• повышение масштабируемости (64%),

• ускорение цикла разработки (60%),

• поддержка трендов цифровой трансформации и интеграция с приложениями следующего поколения (54%),

• обеспечение автономности команд разработки (54%),

• повышение устойчивости приложения (50%).

по данным компании O’Reilly

микросервисами пользуется 77% опрошенных, при этом практически треть в течение последних трёх лет

К тому же есть ограничивающие факторы, которые стоит принять во внимание:

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

2. Ваша devops архитектура настроена на поддержку независимой разработки или вы готовы выделить на это ресурсы и время. Для начала у вас точно есть devops. Убедитесь в этом. 

3. Вы готовы к организации тестовых окружений, подходящих для независимого тестирования микросервисов, а также для тестирования взаимодействия микросервисов, и готовы уйти от концепции чистого end-to-end тестирования к структуре, состоящей из модульных, интеграционных, компонентных и end-to-end тестов с разработкой заглушек и публикацией контрактов.  

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

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

Микросервисы всегда несут в себе определённую сложность, и если у бизнеса нет проблем, которые нивелирует внедрение микросервисов, то не стоит их добавлять, бизнес не оценит. Здесь как в анекдоте: если жизнь стала слишком простой и лёгкой — заведи козу.

Я уже выбрал микросервисы, что пошло не так?

Если скорость выхода в релиз не увеличилась, то всё пошло не так, увы.

Скорее всего, вам нужно ещё раз оценить возможные источники проблем:

• Слишком много микросервисов. Возможно вместо 7 микросервисов на которых зашивается пять команд, стоит завести только пять? Или вообще два. На самом деле, мнение, что микросервисов должно быть много — ошибочно. В большинстве случаев компания не является ни Amazon, ни Netflix.

• Плохо проведён анализ бизнес-доменов. Есть неявные зависимости, требуется обеспечение транзакционности, отсутствует общее решение по архитектуре.

• Отсутствуют/нарушены предварительные договорённости по разработке API, тестированию, настройке CI/CD цикла.

• Команды не автономны, либо чересчур автономны и отсутствует практика обмена опытом и ретроспективы.

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

#### Выводы

На этом позвольте закончить статью и привести кратко выводы по этой теме:

• Не стоит рушить то, что хорошо работает, просто ради модной тенденции.

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

• Если бизнес пришёл к вам с похвальной инициативой, также объясните им последствия. Бизнес есть бизнес, они не обязаны знать обо всех подводных камнях.

• Убедитесь, что у вас есть все ресурсы и чёткое понимание маршрута, прежде чем пускаться в путь.

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