|
13.04.2021, 09:13 | #1 |
Модератор
|
Цитата:
С Уважением, Георгий |
|
13.04.2021, 10:28 | #2 |
Участник
|
Цитата:
Я вижу примеры роста различных BPM систем, low code и вот это всё. Новые пишутся в такой парадигме, в т.ч. некоторые "клиенты" пишут под себя такое и потом выходят на рынок с "платформой". Но пока рано говорить о значительной доли рынка таких систем.
__________________
Ivanhoe as is.. |
|
13.04.2021, 11:35 | #3 |
Модератор
|
Это да... Во-первых, рынок ERP довольно неповоротливый. И просто так все на новой архитектуре переписывать не будет, хотя попытки мы видим. И они, кажется, не всякого радуют .
К тому же, ERP лицензируются по пользователям, сервисы - скорее по потреблению ресурсов (ЦПУ / трафик / место на диске). В итоге приходится много чего пересматривать с точки зрения лицензирования, чтобы новое сводное не отъедало тысячу конкурентных пользователей, но при этом подчинялось базовым настройкам безопасности. С Уважением, Георгий |
|
|
За это сообщение автора поблагодарили: Lemming (5). |
13.04.2021, 14:07 | #4 |
Moderator
|
|
|
02.06.2021, 12:28 | #5 |
Участник
|
Когда говорят о микросервисах, то в качестве их преимуществах говорят о слабосвязанности.
А насколько она - слабосвязанность - нужна? В концептуальном анализе есть прием - антропоморфная редукция. Это когда сложные системы понятий проектируются на человека и/или его деятельность - при этом все должно вставать на свои места и сложные понятия становятся простыми до очевидности. Попробуем спуститься еще ниже - не до человека, а до повара (повароморфная редукция, мда..). Представим повара и его, ну например, микроволновку (сервис). Повар засовывает в него курицу (информационный продукт) и, согласно контракту, микроволновка должна его разморозить. При этом: - если открыть дверцу микроволновки во время работы она должна выключиться. Это жесткая функциональная связь, реализуемая на "железячном" уровне. - после отработки микроволновки повар (процессный движок) должен вынуть курицу (информационный продукт) из микроволновки и засунуть её в кастрюлю, согласно рецепту (шаблон бизнес-процесса). Здесь связи определяются процессом и также достаточно жесткая, хотя может в процессе приготовления меняться. - после отработки микроволновка блямкает - посылает сигнал о завершении работы в космос. Кому он нужен? Да мало ли кому - на кухне и в зале трётся много народа. Может кому и сгодится. И только вот эти, самые малозначимые с точки процесса, связи и являются "слабосвязанными". И только они в достаточной мере годны для реализации микросервисами. Получается, что основная выгода от микросервисов - реализация самых малозначимых компонентов системы. |
|
02.06.2021, 13:09 | #6 |
Участник
|
Цитата:
Cоздадим монолит: привяжем повара к микроволновке цепочкой, и мордочку закрепим скотчем на уровне дверцы: он сразу будет видеть курочку, а это конкурентное преимущество над микросервисом. Тут же вырисовываются и проблемы: поваренок должен быть мелким иначе проигрываем по габаритам и не на каждую кухню влезет такая система + есть опасность потребления ресурсов со стороны поваренка. Последний раз редактировалось axm2017; 02.06.2021 в 13:13. |
|
02.06.2021, 13:30 | #7 |
Участник
|
Давайте определим что такое слабосвязанность?
Когда говорят о микросервисах, то обычно разделяют следующие выгоды:
В качестве минуса - Eventual consistency - повар может не услышать сообщение от микроволновки и думать что еда готовится, когда еда уже готова. |
|
|
За это сообщение автора поблагодарили: Sancho (1), Dynamics365Eng (1). |
02.06.2021, 15:46 | #8 |
Участник
|
Когда говорят о микросервисах возникает одно ощущение — мешанина.
Начиная от определения, например Фаулера: архитектурный стиль микросервисов — это подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными используя легковесные механизмы, как правило HTTP. Мешанина туманной концепции (небольшие сервисы) и конкретной реализации. Теперь к нашим баранам, сиречь повару. Независимость повара и микроволновки, производителя микроволновки, команды микроволновки и установки микроволновки определяемтя не микросервисной архитектурой (использованием отдельного процесса, отдельного источнока данных и протокола HTTP), а компонентной архитектурой. Вспомним приснопамятную RAD-архитектуру и наборы компонентов для Delphi, покупаемых на Горбушке. Без микроскрвисов. Динамическое обслуживание кучи микроволновок - архитектура main/worker процессов. Пример - Apache, PostgreSQL (что знаю). Без микросервисов. Единственное применение микросервисов - использование другой технологии (скорее всего, языка программирования). Я знаю не много языков, но мне не особо верится что есть такие технологии, которые можно реализовать в одном языке и невозможно реализовать в другом. Конечно, беря во внимание наиболее распространенные универсальные языки. Скорее, речь пойдет о том, что независимая команда не шарит в языке и технологии, на которой реализована основная система. Причиина опять не технологическая, а организационная. И особенно доставляет слушать доклады с всевозможных конференция о историях успеха внедрения микросервисной архитектуры (или особенно какой-нибудь Event-Driven Microservice Architecture) в крупных гигантах. Ребята все делают правильно, а получают неуправляемый ворох сервисов и перекосы в системе хранения данных. Но это неважно, ведь используются самые передовые технологии, правдв? |
|