Единость приложения - это не хорошо.

[mazzy]

Цитата:

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

Единость приложения - это нехорошо. То что зоопарк хуже - это миф.
...
Единое приложение это наращивание сложности в одном приложении что рано или поздно приводит к проблемам.
Единое приложение это актуальные данные из единой базы. Это хорошо? - Нет.

Единое != одно приложение.

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

Единое приложение с точки зрения пользователя != Единое приложение с точки зрения разработчика
Единое приложение вовсе не означает, что используется одна база.
А Единая база данных вовсе не означает, что на этой базе работает только одно приложение )))

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

О разном user expirience, наконец. Например, окно аксапты закрывается без дополнительных вопросов, а окно cloudPOS зачем-то требует подтверждения. Зато окно аксапты просит отрефрешить себя после простоя, а окно cloudPOS рефрешит себя само. И так далее. Бесит этот разнобой неимjверно.

[ax_mct]

Цитата:

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

Единое != одно приложение.

Единое приложение с точки зрения пользователя != Единое приложение с точки зрения разработчика

Единое приложение вовсе не означает, что используется одна база.

А Единая база данных вовсе не означает, что на этой базе работает только одно приложение )))

Microsoft Dynamics 365 - это единое приложение?

Цитата:

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

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

Если все модули AX были бы способны работать автономно для выполнения своей основной функции
и имели каждый свою базу и возможно свои технологии (то есть модули AX как "microservice") - это зоопарк?

[mazzy]

Цитата:

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

Microsoft Dynamics 365 - это единое приложение?

1. нет приложения с названием "Microsoft Dynamics 365" )
2. под названием "Microsoft Dynamics 365" чаще всего выступает MS CRM. MS CRM единое приложение. пока еще.
3. если под названием "Microsoft Dynamics 365" имеется в виду все продукты Microsoft Dynamics, то нет, не единое.
4. если в данном вопросе имеется в виду Аксапта, включая Retail, то нет, не единое приложение. см. Какие библиотеки используют разные веб-клиенты Dynamics?
5. если в данном вопросе имеется в виду Аксапта без Retail, без WMS, без корпоративного портала, без OLAP, то оставшееся с натяжкой можно назвать единым приложением. Натяжка возникает прежде всего из-за Reporting Service.

Цитата:

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

Если все модули AX были бы способны работать автономно для выполнения своей основной функции и имели каждый свою базу и возможно свои технологии (то есть модули AX как "microservice") - это зоопарк?

дык, оно уже зоопарк )
для зоопарка не обязательно ВСЕ, достаточно некоторых модулей и компонент.

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

пример единых продуктов:

• FAR и плагины к нему
• Chrome и плагины к нему (с натяжкой)
• Facebook и его Messenger
• вКонтакте с его огромным количеством собственных компонент и сторонних приложений
• хороший пример единого продукта - vBulletin форум, его движок для блогов, его движок для проектов, его движок для порталов и плагины к ним
• хороший пример единого продукта - конфигурации 1С, написанные на одной платформе с учетом ограничений компоненты Распределенная база данных (или как она сейчас называется) и не использующие внешних компонент (как Инталев, например)

[ax_mct]

Цитата:

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

[
...
если под названием "Microsoft Dynamics 365" имеется в виду все продукты Microsoft Dynamics, то нет, не единое.
...
для зоопарка не обязательно ВСЕ, достаточно некоторых модулей и компонент.
...
однако, если бы модули были бы способны работать автономно, работали бы с разными базами, но были бы основаны на единой технологии-архитектуре-библиотеке и могли бы действовать не только автономно, но и совместно, то это можно было бы назвать единым продуктом.

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

Мой посыл в том что степень централизованности системы это как степень нормализации базы данных.Часто не соответствует здравому смыслу.
К примеру если одно приложение с одной базой требуется в режиме терминала
к примеру
- для регистрации пассажиров на рейс в разных аэропортах,
- при вьезде в гостиницу в разных городах
- при производстве на независимых площадках
- продаже в физическом магазине мировой корпорации
и выход из строя этого сервера/кластера блокирует все -
то это заговор IT масонов.

Нет функциональной необходимости использовать одно приложение в большинстве случаев.

[mazzy]

Цитата:

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

То есть единый продукт с точки зрения технической реализации.

Не обязательно.
Ну и бог с вами.

[Zabr]

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

[macklakov]

Цитата:

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

Хотя пассажиру может быть и все едино.

Пассажир существо странное, может он тупо хочет ехать, может шашечки, а может он хочет именно паравоз. Чтобы струя пара по перону, чтобы гудок и колокол, чтобы потный качегар с голым торсом уголь в топку кидал
Поэтому когда обсуждаем инженерные решения, лучше сразу определиться какой цели хотим достигнуть. Наш здравый смысл здесь не очень надежный помошник, т.к. мы продукт советской инженерной школы, которая отличается предельной утилитарностью. В глубине души мы все пытаемся выковать "оружие победы", предельно надежное, дешевое, простое в эксплуатации и обладающее чудовищной поражающей способностью.

Цитата:

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

то это заговор IT масонов.

Индустрия входит в стадию зрелости. Без заговоров никак. У автопроизводителей есть свой заговор, у электриков, у нефтянников, даже у ассенизаторов. А мы чем хуже?

[ax_mct]

Цитата:

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

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

Не только с технической. Это по сути про принятие решения о внедрении AX/SAP/etc. На уровне бизнеса. Когда верят в миф что единое приложение лучше зоопарка то выбирают монолит помощнее. В котором чем больше тем лучше.

Так зачем же внедрять ERP-системы
https://habrahabr.ru/post/256959/

Цитата:

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

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

Есть стандарты/протоколы/сервера обмена информацией. Все нужное - уже есть.
Потенциально есть не только BizTalk популярности которого я не заметил, но и вагон альтернатив серверов трансформации
https://en.wikipedia.org/wiki/Compar...ation_software

Если не лукавить то AX сейчас и уверен что и SAP - тоже зоопарк, дебри и маета.
Критическая запредельная масса функционала она всегда приводит к зоопарку.
Для меня зоопарк - это нарушение заложенных принципов архитектуры и паттернов проектирования. И на одном языке можно сделать полный зоопарк. И,наоборот, на разных языках все может быть на своих местах.

Цитата:

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

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

В самую дырочку. Конфликт менталитетов разных континентов.
Именно что Катюша и Калашников. Именно что эффективно и просто.
То бишь PHP

[Sancho]

Цитата:

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

Критическая запредельная масса функционала она всегда приводит к зоопарку.
Для меня зоопарк - это нарушение заложенных принципов архитектуры и паттернов проектирования. И на одном языке можно сделать полный зоопарк. И,наоборот, на разных языках все может быть на своих местах.

отлично! +

[macklakov]

Цитата:

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

В самую дырочку. Конфликт менталитетов разных континентов.
Именно что Катюша и Калашников. Именно что эффективно и просто.
То бишь PHP

Я как раз на типичную ловушку в рассуждениях указать хотел. Инженер советского разлива склонен концентрировать усилия на надежности, простоте и дешевизне. Но, это не всегда хоршо для бизнеса.
В приминении к нашим баранам, разделение системы на специализированные сервисы, конечно же, дает значительную гибкость. А гибкость позволит создать более надежное решение, лучше подходящее нуждам клиента и стоящее гораздо меньших денег, уже потому, что киленту не надо будет покупать "в нагрузку" кучу ненужных довесков.
Но! Одна из величайших страшилок IT мира это IBM PC. Превосходная, гибкая, открытая платформа, во многом обеспечившая компьютерную революцию. И которая лишила IBM доминирующего положения на рынке. В это же время были абсолютно закрытые продукты Apple. Да, они занимали ничтожную нишу, по сравнению с PC, но все эти деньги шли Apple. Поэтому на Джобса молятся, а кто создал PC мало кто знает.
На этом кейсе уже 3-е поколение менджмента воспитывается. Поэтому мало кто хочет вкладываться в открытые платформы. А если и вкладываются, то первым делом хотят быть уверенными что будут полностью контролировать и иметь с этого деньги.

[egorych]

Цитата:

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

То бишь PHP

Чем зоопарк на php отличается от зоопарка на X++ ?
Знаете, есть такая теория надежности в электротехнике. Один из главных постулатов - надежность обратно пропорциональна квадрату количества соединений между блоками.
ИМХО в IT такими соединениями как раз являются упомянутые протоколы обмена и сервисы трансформации - пару раз передать туды-сюды накладную и вот она уже не накладная, а отгрузка (ну так, к примеру) - сколько таких было приколов.