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

[Ivanhoe]

Цитата:

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

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

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

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

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

[George Nordic]

Цитата:

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

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

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

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

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

[fed]

Цитата:

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

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

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

[mau]

Когда говорят о микросервисах, то в качестве их преимуществах говорят о слабосвязанности.
А насколько она - слабосвязанность - нужна?
В концептуальном анализе есть прием - антропоморфная редукция. Это когда сложные системы понятий проектируются на человека и/или его деятельность - при этом все должно вставать на свои места и сложные понятия становятся простыми до очевидности.
Попробуем спуститься еще ниже - не до человека, а до повара (повароморфная редукция, мда..).
Представим повара и его, ну например, микроволновку (сервис). Повар засовывает в него курицу (информационный продукт) и, согласно контракту, микроволновка должна его разморозить. При этом:
- если открыть дверцу микроволновки во время работы она должна выключиться. Это жесткая функциональная связь, реализуемая на "железячном" уровне.
- после отработки микроволновки повар (процессный движок) должен вынуть курицу (информационный продукт) из микроволновки и засунуть её в кастрюлю, согласно рецепту (шаблон бизнес-процесса). Здесь связи определяются процессом и также достаточно жесткая, хотя может в процессе приготовления меняться.
- после отработки микроволновка блямкает - посылает сигнал о завершении работы в космос. Кому он нужен? Да мало ли кому - на кухне и в зале трётся много народа. Может кому и сгодится. И только вот эти, самые малозначимые с точки процесса, связи и являются "слабосвязанными". И только они в достаточной мере годны для реализации микросервисами.
Получается, что основная выгода от микросервисов - реализация самых малозначимых компонентов системы.

[axm2017]

Цитата:

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

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

Попробуем от обратного:
Cоздадим монолит: привяжем повара к микроволновке цепочкой, и мордочку закрепим скотчем на уровне дверцы: он сразу будет видеть курочку, а это конкурентное преимущество над микросервисом.
Тут же вырисовываются и проблемы: поваренок должен быть мелким иначе проигрываем по габаритам и не на каждую кухню влезет такая система + есть опасность потребления ресурсов со стороны поваренка.

[belugin]

Цитата:

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

А насколько она - слабосвязанность - нужна?

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

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

В качестве минуса - Eventual consistency - повар может не услышать сообщение от микроволновки и думать что еда готовится, когда еда уже готова.

[mau]

Когда говорят о микросервисах возникает одно ощущение — мешанина.
Начиная от определения, например Фаулера: архитектурный стиль микросервисов — это подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными используя легковесные механизмы, как правило HTTP.
Мешанина туманной концепции (небольшие сервисы) и конкретной реализации.

Теперь к нашим баранам, сиречь повару.
Независимость повара и микроволновки, производителя микроволновки, команды микроволновки и установки микроволновки определяемтя не микросервисной архитектурой (использованием отдельного процесса, отдельного источнока данных и протокола HTTP), а компонентной архитектурой. Вспомним приснопамятную RAD-архитектуру и наборы компонентов для Delphi, покупаемых на Горбушке. Без микроскрвисов.

Динамическое обслуживание кучи микроволновок - архитектура main/worker процессов. Пример - Apache, PostgreSQL (что знаю). Без микросервисов.

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

И особенно доставляет слушать доклады с всевозможных конференция о историях успеха внедрения микросервисной архитектуры (или особенно какой-нибудь Event-Driven Microservice Architecture) в крупных гигантах. Ребята все делают правильно, а получают неуправляемый ворох сервисов и перекосы в системе хранения данных.
Но это неважно, ведь используются самые передовые технологии, правдв?

[axm2017]

Цитата:

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

Когда говорят о микросервисах возникает одно ощущение — мешанина.
...
Динамическое обслуживание кучи микроволновок - архитектура main/worker процессов. Пример - Apache, PostgreSQL (что знаю). Без микросервисов.

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

Цитата:

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

Единственное применение микросервисов - использование другой технологии (скорее всего, языка программирования).

Откуда такое мнение?
Естественно как у любой архитектуры есть + и - и бездумно применять не стоит

ps домохозяйкам на заметку
https://habr.com/ru/post/249183/
Не фан микросервисов (мне например не нравятся слухи об invoice машинах и прочем внутри MS как отдельных сервисах так как беглый опрос показывает что MS ники видят это как black boxes со всеми вытекающими) но имеет место быть.

[belugin]

Цитата:

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

(использованием отдельного процесса, отдельного источнока данных и протокола HTTP), а компонентной архитектурой. Вспомним приснопамятную RAD-архитектуру и наборы компонентов для Delphi, покупаемых на Горбушке. Без микроскрвисов.

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

В случае микросервиса, хранение и администрирование лежит на команде, которая поддерживает микросервис, она может даже сменить вид хранилища по желанию.

Цитата:

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

Динамическое обслуживание кучи микроволновок - архитектура main/worker процессов. Пример - Apache, PostgreSQL (что знаю). Без микросервисов.

Да, процессам теперь придется взаимодействовать через IPC, если хочется горизонтального масштабирования (добавлением дополнительных VM) придется учится межсетевому взаимодействию. Если не хочется тащить в worker процессы код и данные, которые в них не используются, придется запускать не копии одного приложения, а отдельные приложения для разных видов задач. Что-то это напоминает.

Цитата:

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

Единственное применение микросервисов - использование другой технологии (скорее всего, языка программирования).

Еще хранилище, например.

Цитата:

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

Я знаю не много языков, но мне не особо верится что есть такие технологии, которые можно реализовать в одном языке и невозможно реализовать в другом.

Все верно. Если не думать о стоимости. (вон фейсбук свой PHP написал) Языки связаны с технологиями. Сборка мусора на .NET, JS, Python и GO устроена по-разному. На objective C неудобно писать под Android и так далее, для DataScience много либ и материалов под питон.

Цитата:

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

И особенно доставляет слушать доклады с всевозможных конференция о историях успеха внедрения микросервисной архитектуры (или особенно какой-нибудь Event-Driven Microservice Architecture) в крупных гигантах. Ребята все делают правильно, а получают неуправляемый ворох сервисов и перекосы в системе хранения данных.
Но это неважно, ведь используются самые передовые технологии, правдв?

Можно сослаться на примеры, пожалуйста? Что за доклады? Кто получил неуправляемый ворох?