Обсуждение стоимости владения D365FO и AX2012

[fed]

Цитата:

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

А насколько версия On-Prem дороже облачной при прочих равных ? Цена инфраструктуры On-Prem сопоставима в сравнении с 2012 или тоже значительно выше ?

Там надо 21 виртуальную машину. (Для PROD и TEST). На каждую машину нужно Windows Server покупать. Надо две лицензии на SQL Server, поскольку оно вроде бы требует отдельных серверов для PROD и TEST. (Может и можно на один SQL Server поставить, но я не уверен что оно поддерживаться будет). Кроме того, On Premises требует SQL Server 2016. SQL Server 2016 в Standard Edition не поддерживает более 24 ядер. Так что если у тебя клиент более или менее крупный (типа от 300 пользователей), то придется под SQL (по крайней мере - продуктивный) отводить 32 ядра и выше и ставить SQL Server Enterprise Version (которая на 32 ядра стоит порядка 400-450K USD. Само-то железо по нынешним временам тысяч в 100-150 обойдется (а в экстремально урезанной конфигурации для тестирования и изучения - может даже тысяч в 30). Проблема в софте.

[ax_mct]

Цитата:

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

On Premises требует SQL Server 2016. SQL Server 2016 в Standard Edition не поддерживает более 24 ядер. Так что если у тебя клиент более или менее крупный (типа от 300 пользователей), то придется под SQL (по крайней мере - продуктивный) отводить 32 ядра и выше и ставить SQL Server Enterprise Version (которая на 32 ядра стоит порядка 400-450K USD. Само-то железо по нынешним временам тысяч в 100-150 обойдется (а в экстремально урезанной конфигурации для тестирования и изучения - может даже тысяч в 30). Проблема в софте.

Я правильно понимаю что необходимость такого железа это из-за кривизны архитектуры решения?
Или там In-Memory technologies in (Azure) SQL Database и все летает?

Что интересно компаний предоставляющих хостинг/облако для SAP S/4HANA сильно больше 10.
То есть конкуренция и возможность переходить. Что делает стоимость владения рыночной.
https://www.sap.com/dmc/exp/2014-09-...#recordid=1155

Вот Principles of SAP HANA Sizing —on premise and cloud, достаточно увлекательно.
https://www.sap.com/documents/2016/1...71af511fa.html
Архивирование данных и разделение старых и текущих данных это очень сильно.

[fed]

Цитата:

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

Я правильно понимаю что необходимость такого железа это из-за кривизны архитектуры решения?
Или там In-Memory technologies in (Azure) SQL Database и все летает?

Проблема в Azure Service Fabric, которая изначально разрабатывалась под кровавый entterprise и на маленьком числе VM работать не умеет
Более интересно то, что до недавнего времени вполне работоспособные на среднем числе пользователей окружения уровня Tier-1 и Tier-2 деплоились на основе обычного IIS и работали на всего паре VM+ база данных где-то в Azure. То есть - не было и нет никаких технических ограничений для того чтобы Microsoft выпустил бы D365FOE On Premise SMB, которое требовало бы двух-трех виртуалок+SQL Server. Но они из за чмошно-маркетинговых побуждений выпустили On Premise на основании тяжелейшей архитектуры. Кроме того, есть сильное подозрение, что продуктивные инстанцы в облаке, на самом деле, до сих пор работают на основе IIS. Микрософт только недавно начал ASF-based окружения в TEST деплоить, причем не во всех регионах. То есть - похоже что микрософтовцы просто решили за счет тех клиентов, кому On Premises нужен просто протестировать альфа-версию ASF-based D365FOE.

Касательно числа ядер для SQL Server: Я видел несколько достаточно больших (типа 200-300 пользователей) внедрений DAX2009/DAX2012 (причем нормально сделаных, без грязного переписывания). Так вот при 16 ядрах у SQL Server, логистика там работала без огонька. Так что при числе пользователей выше 300 я бы думал о где-нить 32 ядрах на SQL Server. Проблема в том что с каждой новой версией SQL Server, стоимость лицензии на ядро росла. Во времена DAX2009 и SQL Server 2008R2, стоимость SQL Server была сопоставима со стоимостью железа, на котором он исполнялся. Сейчас стоимость Enterprise Edition SQL Server 2016/2017 явно раза в 3-4 выше стоимости железа.

[trud]

Цитата:

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

Архивирование данных и разделение старых и текущих данных это очень сильно.

Цитата:

Data aging is a business data management concept for reducing the memory footprint in
SAP HANA
▪
Only operationally relevant (“hot”/current) data is loaded into main memory of SAP HANA
▪
Other (“cold”/historical) data remains primarily stored on disk, not affecting hot data performance, yet cold data
remains accessible via SQL on request

Так а в чем тут сила то? На первый взгляд SQL Server работает точно также, данные помещаются в память если к ним обращаются

Цитата:

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

Так вот при 16 ядрах у SQL Server, логистика там работала без огонька. Так что при числе пользователей выше 300 я бы думал о где-нить 32 ядрах на SQL Server. Проблема в том что с каждой новой версией SQL Server, стоимость лицензии на ядро росла. Во времена DAX2009 и SQL Server 2008R2, стоимость SQL Server была сопоставима со стоимостью железа, на котором он исполнялся. Сейчас стоимость Enterprise Edition SQL Server 2016/2017 явно раза в 3-4 выше стоимости железа.

Тут кстати смотря как трактовать ядро. т.е. при 16 ядрах у тебя может быть и мощный 4 процессорный сервер с включенным HT полностью выделенный под SQL( и стоимость этого сервера будет больше лицензий), где будут новые процы 3.5ГЦ так и виртуалка которая занимает половину какого-нибудь старого процессора 2ГЦ

[fed]

Цитата:

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

Так а в чем тут сила то? На первый взгляд SQL Server работает точно также, данные помещаются в память если к ним обращаются

Не могу рассказать про HANA, но вообще говоря In Memory Database != Cache. То есть - в InMemory database данные храняться в собственных структурах, не ориентированых на табличное хранение. Например, классические БД используют для быстрого поиска B-Tree, просто потому что данные на диске хранятся страницами и время чтения одной записи равно времени чтения страницы. А вот если данные всегда хранятся в памяти, то выгоднее использовать обычные сбалансированные деревья, а не B-Tree. Опять таки, большая часть БД не использует хэширование для хранения данных (вроде бы только в Oracle и в Postgress что-то есть). А если даннные хранятся в оперативке, то построить и какое-то время поддерживать хэш-таблицу можно достаточно дешево.

[ax_mct]

Цитата:

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

Так а в чем тут сила то? На первый взгляд SQL Server работает точно также, данные помещаются в память если к ним обращаются

Про силу я по части архивирования. Для производительности (или меньшего железа) горизонтально делить данные на устаревшие и текущие это очень сильно. Ну вот зачем нам SalesLine c данными за N лет для текущих операций?

А то что In-Memory уже устоявшаяся мода и тренд - это факт.

[gl00mie]

Цитата:

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

В свете того что большинство клиентов DAX2012 на D365FOE никогда не перейдет это собственно все и определяет.

Что им помешает перейти на D365FOE OnPrem? Тем более, через год-другой, когда детские болячки пройдут и производительность выправится?

Цитата:

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

Стоимость владения D365FOE да и любого облачного ERP решения не интересна для Enterprise уровня.

Опять же, забываете про OnPrem - почему?

Цитата:

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

Стоимость перехода с DAX2012 на D365FOE не дешевле чем на любой другой продукт.

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

Цитата:

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

При этом выбор D365FOE выглядит очень рискованным для Enterprise.

Если речь только про Azure, то может быть. На счет OnPrem-версии я бы не был так категоричен.

Цитата:

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

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

Если день расширить до суток, то в OnPrem это вполне реально. В принципе и в течение дня реально, если совсем поверхностно тестировать

Цитата:

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

Даже если что-то сломалось после релиза, то во-первых мы можем это достаточно быстро отладить прямо в PROD

В D365O OnPrem - можно! Через удаленную отладку с виртуалки, где есть исходники.

Цитата:

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

(ну или очень быстро скопировать данные на TEST)

В D365O OnPrem - можно!

Цитата:

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

во-вторых - мы можем исправленную версию быстро зарелизить

В D365O OnPrem - можно! А если с тщательно вымытыми руками да в обход песочницы, то - весьма быстро, буквально меньше часа

Цитата:

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

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

В D365O OnPrem - можно!

Цитата:

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

Там надо 21 виртуальную машину. (Для PROD и TEST).

Ну, при желании можно и меньше, вон люди пишут, что тестовую среду до 4-х виртуалок сокращали (по количеству ролей SF, которые каждая должны быть на отдельном хосте). А так: рабочая среда 8 узлов под SF плюс 2 узла на кластер SQL Server, тестовая - 7 узлов, считая SQL Server (можно 2 AOS'а вместо 3-х и SSRS поставить на хосте СУБД, без кластеризации), итого условно 17, а не 21. Инфраструктура - отдельно, потому что ADFS и файл-сервер могут быть нужны не только для D365FOE. А вся песочница по ресурсам при желании умещается в 8 ядер и 64Гб памяти, т.е. штатный сервер всё-в-одном для AX2012.

Цитата:

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

На каждую машину нужно Windows Server покупать.

Ну... такова селяви. Наверно, если очень захотеть, под песочницы можно использовать триальные версии и переразворачивать всё раз в полгода-год, как делают с DEV-виртуалками.

Цитата:

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

Надо две лицензии на SQL Server, поскольку оно вроде бы требует отдельных серверов для PROD и TEST.

Для песочницы можно использовать бесплатный SQL Server Developer Edition - это ж не продуктивная среда.

Цитата:

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

Проблема в Azure Service Fabric, которая изначально разрабатывалась под кровавый enterprise и на маленьком числе VM работать не умеет

Ну что такого-то? 3 АОСа как бы и раньше не были какой-то роскошью, а за вычетом АОСов и SSRS получается всего 4 "лишних" виртуалки: 3 оркестратора и Management Reporter.

Цитата:

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

Цитата:

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

Кроме того, On Premises требует SQL Server 2016. SQL Server 2016 в Standard Edition не поддерживает более 24 ядер. Так что если у тебя клиент более или менее крупный (типа от 300 пользователей), то придется под SQL отводить 32 ядра и выше и ставить SQL Server Enterprise Version (которая на 32 ядра стоит порядка 400-450K USD).

Тут кстати смотря как трактовать ядро. т.е. при 16 ядрах у тебя может быть и мощный 4 процессорный сервер с включенным HT полностью выделенный под SQL( и стоимость этого сервера будет больше лицензий), где будут новые процы 3.5ГЦ так и виртуалка которая занимает половину какого-нибудь старого процессора 2ГЦ

К слову, да, если не ставить под СУБД древние Xeon 2.4GHz и не считать количество ядер с учетом HT, то и на 16-и ядрах можно ого-го сколько сделать. Скажем, 4x4 ядра Xeon E7-8893 v4 3.2GHz 60Mb L3 - это совсем не то же самое, что какие-нить 2x8 ядер Xeon E5-2630 v3 2.4Ghz 20Mb L3.

[ax_mct]

Цитата:

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

Что им помешает перейти на D365FOE OnPrem? Тем более, через год-другой, когда детские болячки пройдут и производительность выправится?
...
Опять же, забываете про OnPrem - почему?
...
Из моего скромного опыта, стоимость все же сильно зависит от объема кастомизаций и готовности отказываться от них в пользу нового стандартного функционала.Если речь только про Azure, то может быть. На счет OnPrem-версии я бы не был так категоричен.

Какие базовые пункты у нас есть?
Функционал.
Стоимость.
Надежность.
Гибкость.
Популярность.

Та же AX соответствовала всем этим пунктам на уровне конкурентов и выделялась среди прочих стоимостью и удобством разработки. Много ни мало но 20,000 компаний.

А чем выделяется D365FOE OnPrem чтобы привлечь? Чем она лучше конкурентов?
Она ни чем особенным уже не выделяется в положительную сторону. Нет?
Какова ее популярность? Все смотрят на соседей.

Да, через год-другой она станет лучше, но и Windows Phone был не самым плохим продуктом.
Важнее ведь не "качество" продукта, а его цена, место на полке, доверие к бренду, срок годности то есть контекст рынка.

В то же время все партнеры продолжают стоять в низкой беговой стойке на D365FOE, это да.
И есть интерес со стороны клиентов, все же сила маркетинга.
Но где это у соседа так чтобы захотелось?

[Morpheus]

Цитата:

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

Какие базовые пункты у нас есть?
Функционал.
Стоимость.
Надежность.
Гибкость.
Популярность.

Always up to date.

Цитата:

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

Но где это у соседа так чтобы захотелось?

Успешные внедрения есть. Например одна глобальная компания, название не имею права сказать, замещает SAP на облачную D365FO.

[ax_mct]

Цитата:

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

Проблема в Azure Service Fabric, которая изначально разрабатывалась под кровавый entterprise и на маленьком числе VM работать не умеет
...
Но они из за чмошно-маркетинговых побуждений выпустили On Premise на основании тяжелейшей архитектуры.
...
Во времена DAX2009 и SQL Server 2008R2, стоимость SQL Server была сопоставима со стоимостью железа, на котором он исполнялся. Сейчас стоимость Enterprise Edition SQL Server 2016/2017 явно раза в 3-4 выше стоимости железа.

Думаю потому что Azure Service Fabric гораздо для них важнее чем D365 On Premise.
То есть им в принципе им плевать на D365 On Premise. Другие приоритеты с учетом того что 2/3 дохода от подписки. А Azure Service Fabric это один из основных драйверов Azure.

Очень возможно они формально имея D365 On Premise они делают все чтобы он был неинтересен.
То есть когда хотят отказать вежливо то назначают неадекватную цену.

В этой связи интересно связано ли текущая стоимость "On-Premise" SQL Server c заталкиванием в облака. Типа сравните как выгоднее Azure SQL.