#AnaystDays Валерий Разномазов. Аналитика микросервисов. Практический опыт аналитика в enterprise. Работают с банками, используют DDD и онтологию. В докладе рассказывали о тех новых компетенциях которые требует от аналитиков микросервисная архитектура. Все это - инженерные компетенции, и в ответах на вопросы Валера сказал, что аналитик, который ими не владеет, в современных enterprise-проектах не нужен.

Докладе начался интересной моделью от MS, в котором ИТ-система сравнивается с городом времен начала промышленной революции. Транспорт - протоколы, Склады - базы данных, Лавки - АПИ и так далее.

Что позволяют микросервисы
* Можно быстро заменить функционал - и угроза санкций резко повысила значимость такой замены.
* Масштабируемость, во всяком случае есть такой миф.
* Изменение технологий: с Java на php, на go, в масштабах монолита нельзя.
* Микросервис может сопровождаться одним человеком.

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

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

Способы взаимодействия: файл, БЛ, сообщения, http API. В этом аналитику надо разбираться.
Каждый сервис со своей моделью данных - отдельного администратора БД нет, надо разбираться аналитику, идемпотентность данных, безопасность данных, NoSQL базы данных. Еще вопрос дизайна. Дизайнер что-то согласовал с бизнесом. И там интерфейс намерения - вопрос данных, Дизайнер, Архитектор и Аналитик работают вместе. Соответствие между бизнес-сущностями и ИТ-реализацией. Однозначное соответствие с DTO и базой данных - а для этого надо разбираться в технической части.

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

Оркестрация или хореография? Если стабильная понятная система, то лучше хореография, сами договорятся. А вот если там неясно или будет изменяться - то оркестрация лучше. И стартуем от бизнес-процесса.

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

* В микросервисы выносим лишь изменчивые части.
* Жизненный цикл требований. Регуляторы пишут про будущие изменения.
* Выносим то, где нагрузка, внешние АПИ и так далее
* Никто в бизнесе не даст сломать старое - надо обеспечить непрерывность работы.
* Окружаем старый монолит аванпостами нового. И потихоньку заменяем - обращения в базу данных, интерфейс и так далее.

Оценка эффективности - ROI. Две базовых метрики: UpTime - время бесперебойной работы и Yield - время необработанных запросов. По ним оценивается стоимость, и дальше можно оценивать стоимость простоев.

Важнейшим артефактом становится тикет в Jira. Согласованные по стандартам (ГОСТ34, ITIL) не получается.
К тикету - дизайн в Figma, описание фичи в confluence, содель данных, обычно xsd. Коммиты в git - ссылаются на тикет.