Микросервисы в ERP

[Lemming]

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

Основным вопросом остается взаимодействие модулей. Когда мы в единой БД и едином приложении, из которого доступны все бизнес-сущности, мы можем строить и управлять картиной в целом, однако если все это разделить на несколько независимых "небольших" приложений, то сразу возникает вопрос их взаимодействия и обмена данными (пример из мира 1С, когда в компании используется три конфигурации: Бухгалтерия, Кадры, Торговля и данные между ними надо как-то склеивать и держать в актуальном для всех баз виде).

Так вот, для меня остается открытым вопрос о том, как например данные из сервиса Склад будут взаимодействовать с сервисом Главная книга? Если это две разные базы данных, то как мы будем обмениваться данными между ними, REST, SOAP, что-то ещё?

Кроме того, если падает общее приложение то все как бы понятно, поднимать надо все. Если же сервис Главная книга упал, а сервис Продажи ждет от него номер бухгалтерской операции, то чем это будет принципиально отличаться от падения общей БД/приложения?

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

Мысли, идеи, мнения? Вам слово!

[MikeR]

По определению микросервисы - это слабосвязанные модули, причем могут быть реализованы на разных языках и платформах.
Если рассматривать ERP, конкретно DAX, то это отсутствие единого АОС под все модули и единой базы данных.
У каждого модуля должен быть свой API, через который происходит общение с этим модулем.
Идеально, если вам не нравится, как реализован, допустим склад, то вы его заменяете на модуль склад другого поставщика. Допиливаете API по своим существующим модулями и вуаля у вас ERP с другим модулем склад.
Уже не имеет смысл рассматривать интеграции с 1С или еще чем- то, так как у вас каждый модуль отделен. И вам без разницы с каким модулем у вас работает, допустим, модуль производство. API есть, оно работает, данными обменивается.
У вас в качестве модуля главной книги очень может быть 1С.
Модули обмениваются через шину данных.
Если у вас, допустим упал модуль расчеты с персоналом, то остальные модули продолжают работать.
Минусом этого, однозначно, будет сложность администрирования и управления всеми частями.

[mazzy]

Цитата:

Сообщение от MikeR

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

Согласен с MikeR.
И сейчас взаимодействие между "модулями" происходит через публичный интерфейс классов. Никто ж в здравом уме не пишет финансовые проводки вручную, а обращаются к классам LedgerVoucher*

другое дело, что классы в аксапте слишком много знают друг о друге.

Цитата:

Сообщение от Lemming

Кроме того, если падает общее приложение то все как бы понятно, поднимать надо все. Если же сервис Главная книга упал, а сервис Продажи ждет от него номер бухгалтерской операции, то чем это будет принципиально отличаться от падения общей БД/приложения?

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

сейчас это RabbitMQ, Kafka и подобные (эти живут и здравствуют)
Раньше в виндах был MicrosoftMQ и BizTalk (эти умерли)

Цитата:

Сообщение от Lemming

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

Ну... на самом деле не очень.
История повторяется:
1. раньше были "мощные" мэйнфреймы и тупые терминалы.
2. решили что это не гибко и монстроидально, начали в персональные компьютеры
3. персональные компьютеры изначально были персональными и плохо работали в сети.
4. затем появились сетевой инструментарий для персональных компьютеров
5. теперь снова уходит "в облака", где работают мощные "мэйнфреймы", а персональные компьютеры являются тупыми терминалами по большей части

идея с микросервисами - примерно то же самое.
она привлекательна только для небольших и независимых команд разработчиков.

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

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

Майкрософт так и сделал со сводным планированием. Можно почитать отзывы, посмотреть на результат, так сказать

но когда с уровня космического архитектора спускаешься на уровень реализации, тут же выясняется, что в ERP есть много действительно общих вещей. Валюты и валютные курсы например. Особенно с учётом разных стран, кросс-курсов, управляемых курсов типа УЕ.
А также нормативные справочники типа налоговых инспеций, ИНН/КПП. В Аксапте DirInfo, не к ночи будь помянут... Даже тривиальные финансовые периоды, которые в Аксапте в модуле главной книги. И даже в существующей аксапте они не очень используются....

Стоит примерить как придется реализовать ЭТО в парадигме микросервисов. И сколько этих микросервисов придется сделать.

С другой стороны, микрсервисы - это именно такие справочники, а не сводное планирование

[trud]

Цитата:

Сообщение от mazzy

Майкрософт так и сделал со сводным планированием. Можно почитать отзывы, посмотреть на результат, так сказать

Ну кстати по поводу сделал - если посмотреть список тех настроек стандартных сводного планирования что не поддерживается этим сервисом, он просто огромен, т.е. сделали какую-то упрощенную модель. Можно посмотреть по словам - not supported и pending
https://docs.microsoft.com/en-us/dyn...n-fit-analysis

Думаю реализовать такой же сервис внутри D365 было бы на порядок проще, плюс работал бы он так же быстро, т.е. основная сложность таких операций, это как раз множественные настройки, каждая из которых резко усложняет систему, вынуждает делать доп. запросы и прочее

Микросервисы это все же про людей, а не про техническую составляющую, вот просто отличное видео, которое раскрывает проблему
https://www.youtube.com/watch?v=gfh-VCTwMw8

[skuull]

Есть же ещё сервис для on hand https://docs.microsoft.com/en-us/dyn...ory-visibility реализованный на Dataverse и судя по слайдам это первый из многих. Далее обещают сервис для цен.

[George Nordic]

Цитата:

Сообщение от Lemming

Основным вопросом остается взаимодействие модулей. Когда мы в единой БД и едином приложении, из которого доступны все бизнес-сущности, мы можем строить и управлять картиной в целом, однако если все это разделить на несколько независимых "небольших" приложений, то сразу возникает вопрос их взаимодействия и обмена данными (пример из мира 1С, когда в компании используется три конфигурации: Бухгалтерия, Кадры, Торговля и данные между ними надо как-то склеивать и держать в актуальном для всех баз виде).

Так вот, для меня остается открытым вопрос о том, как например данные из сервиса Склад будут взаимодействовать с сервисом Главная книга? Если это две разные базы данных, то как мы будем обмениваться данными между ними, REST, SOAP, что-то ещё?

Кроме того, если падает общее приложение то все как бы понятно, поднимать надо все. Если же сервис Главная книга упал, а сервис Продажи ждет от него номер бухгалтерской операции, то чем это будет принципиально отличаться от падения общей БД/приложения?

А почему именно микросервисы? Потому что модно? Вообще-то, они в основном нужны для быстрого развертывания, например когда на сайт заходит не 5, а 50 000 человек - в обычной архитектуре сайт бы упал, но при использовании докеров просто поднимается куча готовых виртуалок с преднастроенными сервисами, которые отрабатывают запрос. Валидна ли подобная технология для ERP - вопрос открытый.

С другой стороны, можно посмотреть как работает Oracle Fusion. В ERP есть "сердце" - основные справочники (номенклатура, план счетов, валюта) и транзакционные таблицы (главная книга, перемещение номенклатуры). Данные справочники едины для всех модулей, которые являются расширением базового функционала. Т.е. все модули видят, какой товар есть в наличии на каком складе, а где именно он лежит - знает только модуль WMS. Если WMS упал - ну, чините, ничего страшного, система работает. CRM - видит список компаний и контактов, а как именно с ними ведется работа - знает только сам CRM, который, в свою очередь, может выдавать информацию о заказе или предполагаемых заказах, основанную на оценке стадии сделки и её предполагаемой сумме. И подобные модули являются расширением стандартного функционала системы, без которого она может работать, но которые дополняют и расширяют стандартную функциональность.

Таким образом, Fusion выступает как сервер приложений, который обеспечивает контроль доступа, работу с БД и шину данных.

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

Но у меня не вяжется "микроcервис" и, например, "WMS". Микросервис ближе к мобильному рабочему месту оператора, чем к модулю ERP.

С Уважением,
Георгий.

[Ivanhoe]

Я когда думал на эту тему для себя разделил примерно как расписали уже выше: внутри "модуля" можно сделать модную микросервисную архитектуру (и пример масштабирования сводника - это запуск много отдельных параллельных микросервисов расчета), а вот сама ERP - это уже система из таких модулей-"сервисов".

В общем случае модули ERP могут быть на разных платформах, ПО и т.п. По сути классика жанра Аксапта + 1С для БУ + WMS + BI и есть модульная ERP.

[George Nordic]

Цитата:

Сообщение от Ivanhoe

По сути классика жанра Аксапта + 1С для БУ + WMS + BI и есть модульная ERP.

Нет, Иван. Это не так. Ты не поднимешь 100 экземпляров 1С для расчета или 1000 экземпляров DAX для параллельного запуска сводного планирования, а это и есть смысл микросервисов.

С Уважением,
Георгий

[Ivanhoe]

Цитата:

Сообщение от George Nordic

Нет, Иван. Это не так. Ты не поднимешь 100 экземпляров 1С для расчета или 1000 экземпляров DAX для параллельного запуска сводного планирования, а это и есть смысл микросервисов.

С Уважением,
Георгий

Так я не говорю, что текущие системы / модули написаны в парадигме микросервисов. Они могли бы / будут. Сейчас в ентерпрайзе среди ERP, WMS, TMS и т.п. я не знаю примеров. Тот же новый сводник совсем не туда?

Я вижу примеры роста различных BPM систем, low code и вот это всё. Новые пишутся в такой парадигме, в т.ч. некоторые "клиенты" пишут под себя такое и потом выходят на рынок с "платформой". Но пока рано говорить о значительной доли рынка таких систем.

[George Nordic]

Цитата:

Сообщение от Ivanhoe

Но пока рано говорить о значительной доли рынка таких систем.

Это да... Во-первых, рынок ERP довольно неповоротливый. И просто так все на новой архитектуре переписывать не будет, хотя попытки мы видим. И они, кажется, не всякого радуют .

К тому же, ERP лицензируются по пользователям, сервисы - скорее по потреблению ресурсов (ЦПУ / трафик / место на диске). В итоге приходится много чего пересматривать с точки зрения лицензирования, чтобы новое сводное не отъедало тысячу конкурентных пользователей, но при этом подчинялось базовым настройкам безопасности.

С Уважением,
Георгий

[fed]

Цитата:

Сообщение от George Nordic

И они, кажется, не всякого радуют .

С выходом микросервисной версии MRP, выражение "сводник", так любимое выходцами из Коруса, наконец-то начало звучать неожиданно уместно.

[twilight]

Компоненты это хорошо. Но почему обязательно микро? Это какое-то упрощение. Сначала стремимся все запихнуть в одну систему (ERP). Потом все поделить на маленькие кусочки. Надо выделять области наибольшей связности кода, их и можно выносить в сервисы.

[mau]

Цитата:

Сообщение от twilight

Компоненты это хорошо. Но почему обязательно микро? Это какое-то упрощение. Сначала стремимся все запихнуть в одну систему (ERP). Потом все поделить на маленькие кусочки. Надо выделять области наибольшей связности кода, их и можно выносить в сервисы.

Именно. в том же концептуальном анализе есть понятие "естественная целостность", которые необходимо выявлять и строить по ним контуры управления.

[trud]

Вот хороший пример в тему с SAP, но думаю если б была АХ то было бы тоже самое. Процесс расчета календарей работал на SAP 9ч, переписали за полгода на микросервисы, теперь работает 10 минут
https://habr.com/ru/company/mvideo/blog/560726/

[twilight]

Цитата:

Сообщение от trud

Процесс расчета календарей работал на SAP 9ч, переписали за полгода на микросервисы, теперь работает 10 минут

А причем тут микросервисы? Просто переписали с нуля отдельно взятый алгоритм.

[axm2017]

Цитата:

Сообщение от twilight

А причем тут микросервисы? Просто переписали с нуля отдельно взятый алгоритм.

Архитектура микросервисов формально позволяет сделать это безболезненно. Сервис то отдельный: творим что хотим лишь бы внешние интерфейсы не изменились.

Но как обычно может быть куча нюансов.

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

[pitersky]

Цитата:

Сообщение от twilight

А причем тут микросервисы? Просто переписали с нуля отдельно взятый алгоритм.

Соглашусь
Там даже в явном виде написано

Цитата:

Это решение довольно давно было поставлено “костылем” в SAP ERP

Проще говоря, когда-то какие-то индусы написали неоптимизированную приблуду, а сейчас её просто оптимизировали. Микросервисы как таковые тут вообще ни при чём

[Ivanhoe]

Если по пиццам, то это я и мой коллега как двумя пиццами накормить 12 разработчиков?