Хабрахабр

Микросервисы делают мир проще (а вот и нет)

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

Но, как по мне, от сложности не избавится совсем, нельзя переделать проект, чтобы сразу всё стало просто. Основной посыл всех этих докладов — микросервисы помогают уйти от излишней сложности и запутанности проекта. Сложность растет: это и распределенные транзакции, которые нужно журналировать так, чтобы понять, что это одна транзакция; для каждого сервиса прибавляется CI/CD и поставка; схема взаимодействия становится нетривиальной. Сложность из одной области перейдет в другую.
Например: был очень сложный запутанный монолит, мы его разбили на несколько сервисов, каждый из них выглядит прекрасно, любой сможет разобраться с кодом, но что происходит с окружением?

Самые спорные тезисы или утверждения, которые я слышал на докладах и с которыми я готов спорить:

Почему-то принято оценивать стоимость вхождения в проект по тому, как быстро новый разработчик начнёт делать задачи. Вход в проект монолита дороже для новых членов команды. Да, в маленьком сервисе он разберется очень быстро и задачу выдаст очень быстро (тем более по спецификации, «что написали, то я и сделал»).

Но как насчет других членов команды?

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

Новый аналитик на первых порах может вообще голову сломать, пока разберется во всех хитросплетениях внутренних вызовов.

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

Чаще всего в самом начале будет одна задача — сделать общую функциональность (общую БД подправить, или интерфейс доработать), а дальше каждый будет пилить свои подзадачи и отдавать их в тестирование. С монолитом тоже можно так делать, всё зависит от декомпозиции задачи.

Фича будет закрыта только когда будут выпущены все компоненты. И время выпуска фичи, за которую платит бизнес, будет одинаковое. Микросервисы могут решить 99% задач, но пока не закроется последняя фича, их не выпустят в бой.

О чем еще не говорят

Сложность растет

При использовании микросервисов усложняется инфраструктура. Это связано с тем, что нужно поддерживать работу не одного приложения, а множества сервисов. Нужно мониторить работоспособность всех сервисов, хорошо понимать зависимости сервисов по версиям, иметь CI/CD-планы для сборки сервисов и поставки, механизмы реагирования на выходы сервисов из строя, чтобы не легло всё остальное.

Только в монолите мы работаем над одним приложением, а с увеличением количества сервисов сложность растет, что требует от поддержки более высоких навыков. Вроде бы простые вещи, и в монолите мы должны делать всё то же самое.

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

Если с починкой мы справляемся без проблем, то чтобы раскатать изменения по 200—300 сервисам, понадобится время и развитые средства управления. Но и в них могут быть ошибки, которые придётся чинить. А если понадобится пересобрать сервисы с обновленной библиотекой, а то и вызовы переделать (вот так починили, не предусмотрели), то всё это будет не весело.

Монолит — небольшой комок грязи(big ball of mud)

Как обычно начинаются рассказы про прекрасный мир микросервисов? «Был у нас монолит, это был сплошной комок грязи, в котором всё запутанно и непонятно», плюс ещё картинку страшную покажут. И монолит уже стал чем-то пугающим, «будете плохо работать, ваш проект превратится в монолит». Но НЕТ.

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

Так что же использовать?

Хороший вопрос, и ответ можете дать только вы. Потому что только вам известно, какие проблемы бизнеса вы решаете, каким будет проект. Нет серебряной пули, нет идеальной архитектуры, которую можно использовать и будет всегда “счастье”.

С документацией лучше, чем без неё. И в монолите, и в микросервисах следите за документацией и поддерживайте её в актуальном состоянии.

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

Простой и понятный код — это не про микросервисы, код априори таким должен быть.

Автоматизация тестирования — это тоже про качество кода.

Наверное, есть такой стек технологий, который очень трудно затянуть в CI/CD, но 99% сборок/поставок можно автоматизировать. Автоматизируйте всё, что можно автоматизировать — CI/CD.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»