Что грядущий Dynamics AX 7.0 нам готовит?

[EVGL]

Цитата:

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

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

Выгодно было бы держать БД и AOS где-то там и незаметно для пользователя их масштабировать. Что, собственно, и призван поддерживать System Center.

[fed]

Цитата:

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

Выгодно было бы держать БД и AOS где-то там и незаметно для пользователя их масштабировать. Что, собственно, и призван поддерживать System Center.

Кстати тут подумал что модель облака основана на предположении более или менее равномерной загрузки. Например - если мы хостим 100 сайтов, то вероятность того что более 10 из них будут иметь пиковую нагрузку в один и тот же день - весьма мала. В то же время, мы все знаем что при автоматизации бизнеса, пиковая нагрузка приходится на конец-начало месяца. Соответственно - если провайдер у нас специализируется на бизнес-приложениях, ему придется держать сервера с большим запасом - в рассчете на конец месяца. А если же наш провайдер держит смесь бизнес-приложений, почты, веба, да и вообще любых приложений, то вроде бы особых преимуществ в плане поддержки он давать не будет (поскольку у него не хватит грамотных спецов чтоы весь этот зоопарк поддерживать).
Так что получается что вообще никаких преимуществ по масштабируемости и скалируемости в области бизнес-приложений облако дать не может...

[Vadik]

Цитата:

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

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

Вот они там все идиоты и такую фигню элементарную не просчитали, ага ? Ну вот мы к примеру достаточно большой бизнес и закрытие месяца растянуто дней на 7-10 а не "в ночь с 31 на 1" (разные компании в группе \ регионы \ подразделения и модули в конце концов. Потом, не забывай что пользователи облака - из разных географических и временных зон, так что очень даже равномерно нагрузка может размазываться.

Цитата:

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

Есть преимущества, нет их - выдерживать SLA и минимизировать затраты - головная боль сервис провайдера, ты как клиент сервис либо покупаешь за заявленную заранее денежку, либо нет - тебе не все равно ? Не хочешь в облако - использовать аксапту on premise тебе вроде пока никто запрещать не собирается

[fed]

Цитата:

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

Вот они там все идиоты и такую фигню элементарную не просчитали, ага ? Ну вот мы к примеру достаточно большой бизнес и закрытие месяца растянуто дней на 7-10 а не "в ночь с 31 на 1" (разные компании в группе \ регионы \ подразделения и модули в конце концов. Потом, не забывай что пользователи облака - из разных географических и временных зон, так что очень даже равномерно нагрузка может размазываться.

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

Цитата:

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

Есть преимущества, нет их - выдерживать SLA и минимизировать затраты - головная боль сервис провайдера, ты как клиент сервис либо покупаешь за заявленную заранее денежку, либо нет - тебе не все равно ? Не хочешь в облако - использовать аксапту on premise тебе вроде пока никто запрещать не собирается

Ну так для того чтобы дать клиенту какие-то ценовые преимущества - поставщик сам должен их иметь. Ну то есть - если мы имеем 10 клиентов и под 10 клиентов держим 10 мощных серверов, то клиент, в конечном итоге заплатит столько же сколько бы ему обошлись бы те же серверы в собственности+наша прибыль. Вот если мы имеем 1000 клиентов с равномерной загрузкой (типа e-mail серверов) и мы этих клиентов держим всего-лишь на 300 серверах (вместо 1000), то мы можем для клиентов установить стоимость аренды равную, условно говоря, 40% от их расходов при покупке сервера в собственность. При этом и клиент экономит (за счет экономии масштаба) и мы деньги зарабатываем (потому что часть экономии масштаба мы кладем себе в карман). А раз провайдеру сэкономить негде, то и клиенту особой экономии не случиться...

[belugin]

Цитата:

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

Ну то есть - если мы имеем 10 клиентов и под 10 клиентов держим 10 мощных серверов, то клиент, в конечном итоге заплатит столько же сколько бы ему обошлись бы те же серверы в собственности+наша прибыль.

1. Не факт, что 1000 серверов на 1000 клиентов в одном датацентре стоит столько же сколько 1000 серверов у 1000 клиентов отдельно - возможна экономия масштаба на инфраструктуре и администрировании

2. Если в датацентре работает зоопарк приложений это не значит, что этот зоопарк поддерживается силами хостера. Хостер может просто предоставлять платформу или инфраструктуру ("вот вам SQL сервер под SLA" или даже "вот вам виртуалка под SLA"). Таким образом саппорту достаточно решать прорблемы своего уровня абстракции.