О микросервисах не говорит только ленивый. Когда они только появились в 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 лет фактически поменял способ и место учета. Вместе с этим появились несколько совершенно разных окон, в которых мы можем узнать информацию о гарантии:
сайт;
чат-бот;
личный кабинет оператора;
мобильное приложение;
- call-центр и т.д.
Казалось бы, все это можно собрать в одном месте, например, в 1С и транслировать через API во все внешние системы. Но это еще не микросервис, это единая структура по управлению e-commerce и вообще продажами (и электронными, и обычными), которая состоит из кучи разных сервисов. Каждый из этих сервисов имеет свое API для взаимодействия с внешними системами.
В итоге получается огромный монстр. Он вроде не такой уж и страшный, у многих компаний в разных отраслях такие монстры успешно функционируют.
Однако в нашем примере мы можем наблюдать за тем, как быстро растет скорость изменений: если за первые 5-7 лет деятельности мало что поменялось, то за последние несколько лет появилось несколько новых систем. Хорошо, что сейчас компания производит и продает только свои холодильники. А если она захочет стать мультибрендовым интернет-магазином? В этом случае появится десяток производителей, каждый из которых захочет учитывать гарантии в своей системе. В чем же проблемы монстров? Их всего две, и обе они связаны со скоростью изменений.
1. Первая проблема заключается в том, что монстра очень сложно релизить. Да, мы хотим менять и развивать продукт, в условиях монолита обновления возможно внедрять отдельными релизами. Мы собираем один релиз, тестируем его и накатываем на всю систему. В условиях монстра, внутри которого все взаимосвязано, без тестирования не обойтись. Получается, что разработка одного продукта развития может тормозиться из-за того, что другой продукт развивается в несогласованном темпе, т.е. для обновления другого продукта придется ждать релиза первого.
2. Вторая проблема заключается в том, что внедрить стороннего эксперта в монолитную систему сложно и долго. В нашем монстре много различных правил, legacy, старого кода, ранних наработок. Чтобы эксперт в этом разобрался, понадобится время, много времени. Предположим, у нас есть задача сделать гибкое ценообразование. Нам нужен эксперт по гибким ценам, человек, который умеет работать с большими данными, что-то парсить, проверять. Для того чтобы его на несколько месяцев подключить сюда к нам в систему, нужно те же несколько месяцев его погружать в нюансы работы нашего монстра.
Было бы куда проще, если бы мы могли параллельно готовить обновления для разных продуктов внутри компании и привлекать внешних экспертов для работы в локальном сервисе. Монолитная аритектура, этого, к сожалению позволить не сможет.
Микросервисы - это не панацея, с их помощью нельзя решить любую проблему, особенно, если это управленческая проблема.
Однако с точки зрения бизнес-процессов процессы, которые можно выделить в отдельный продукт и гибко и быстро развивать, нужно выделять в микросервисы. Это позволит вам быстрее реагировать на меняющуюся конъюнктуру рынка, на изменяющуюся ситуацию на рынке, новые правила работы. В конечном счете это позволит вам выиграть в конкурентной борьбе.
и что Битрикс24 хорош?
web на Битрикс ужасен.