Микросервисы: дань моде или способ выжить?

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

Лет 7-8 назад мы в компании SEBEKON всегда предлагали решение задач без микросервисов, поскольку считали тогда, что добротный проект на основе монолитной архитектуры мог гарантированно решить задачи бизнеса. На наш взгляд, микросервисы пришли в бизнес чуть раньше, чем IT-сектор был к ним готов. Со временем рынок и среда до него доросли, но многим промышленным и торговым компаниям до сих пор непонятно, что это за зверь.

Рассмотрим в качестве примера эволюцию одного из процессов — «гарантийные обязательства» (гарантия) — компании, которая производит и продает холодильники.

15 лет назад покупатель в магазине получал выписанное от руки гарантийное обязательство на номерном бланке. В случае обращения по гарантии, он приходил с этой бумажкой в сервисный центр. Со временем производитель этого холодильника захотел, чтобы гарантия оформлялась на сайте и система учитывала все гарантии в учетной системе, например, в 1С.

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

5 лет назад в компании появляется мобильное приложение, в котором тоже бы неплохо показывать гарантии на купленный товар, а еще было бы здорово настроить оформление гарантии через call-центр, а не только через сайт магазина. Для обеспечения этого процесса управление и хранение всех гарантий переносится из 1С в CRM-систему, например, на базе Microsoft Dynamics.

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

В галерее показан весь процесс эволюции оформления гарантии.

Февраль 2022 года перевернул работу компании с ног на голову. Компания Microsoft объявила об уходе из России, следовательно, нужно срочно переместить все процессы с Microsoft Dynamics на Битрикс24.

Что же в итоге мы имеем? Мы имеем один продукт (а их в компании могут быть десятки), который за 15-17 лет фактически поменял способ и место учета. Вместе с этим появились несколько совершенно разных окон, в которых мы можем узнать информацию о гарантии:

Казалось бы, все это можно собрать в одном месте, например, в 1С и транслировать через API во все внешние системы. Но это еще не микросервис, это единая структура по управлению e-commerce и вообще продажами (и электронными, и обычными), которая состоит из кучи разных сервисов. Каждый из этих сервисов имеет свое API для взаимодействия с внешними системами.

Однако в нашем примере мы можем наблюдать за тем, как быстро растет скорость изменений: если за первые 5-7 лет деятельности мало что поменялось, то за последние несколько лет появилось несколько новых систем. Хорошо, что сейчас компания производит и продает только свои холодильники. А если она захочет стать мультибрендовым интернет-магазином? В этом случае появится десяток производителей, каждый из которых захочет учитывать гарантии в своей системе. В чем же проблемы монстров? Их всего две, и обе они связаны со скоростью изменений.

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

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

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

Однако с точки зрения бизнес-процессов процессы, которые можно выделить в отдельный продукт и гибко и быстро развивать, нужно выделять в микросервисы. Это позволит вам быстрее реагировать на меняющуюся конъюнктуру рынка, на изменяющуюся ситуацию на рынке, новые правила работы. В конечном счете это позволит вам выиграть в конкурентной борьбе.