Берем и отжимаем: Microsoft признает, что не может позволить себе собственное облако

Аватар пользователя gruzzy

Microsoft признала унизительное поражение после долгой борьбы за права своих партнеров.

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

Однако, в начале недели 8 июля Microsoft незаметно объявила, что лицензионные льготы будут отменены с 1 июля 2020 года.

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

Microsoft отбилась иронично: поскольку большая часть портфеля фирмы была перенесена в облако, стоимость предоставления бесплатных лицензий своим партнерам оказалась слишком большой дырой в ее карманах.

Это очень достойный аргумент: когда-то партнерам приходилось платить за аппаратное обеспечение для запуска своего бесплатного программного обеспечения, таким образом, стоимость делилась. В соответствии с новой облачной моделью Microsoft несет больше затрат.

Но это объяснение не успокоило партнерв Microsoft и они продолжают бушевать.

И к субботе Microsoft отменила изменения, дополнив их обычными откоряками и пообещав в будущем стать более консультативными.

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

Но факт остается фактом: Microsoft безоговорочно науськивает читателей iTnews к Azure. Тем не менее, мы слышим многочисленные истории о возврате вычислительных мощностей из облака.

 

Авторство: 
Авторская работа / переводика
Комментарий автора: 

Чему это нас учит? Тому, что на чужой хлебок не разевай хлебало.

Местные реалии таковы, что "креативный" молодняк рвал одно место на американский флаг, мечтая о вечной беззаботной жизни. Ведь именно так им обещал Microsoft - становитесь нашими партнерами, это бесплатно. И мы будем делиться с вами как с партнерами, не упоминая какими именно "партнерами". А оказалось, очень даже обычными половыми.

Теперь у Microsoft осень, пол-шестого и любовь ушла. Платите деньги, дорогие партнеры.

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

Помню отличный пример, когда 1С послала мокрософт и запилила БД на Посгри, а потом и линукс-клиента нарисовала. Давно это было...

Мавры! Вы сделали великое дело! Пошли вон отседа!

Комментарии

Аватар пользователя Брейгель
Брейгель(5 лет 3 месяца)

 Понял только, что Майкрософт фсё. Это же хорошо?

Комментарий администрации:  
*** Возбужденное чмо ***
Аватар пользователя gruzzy
gruzzy(7 лет 7 месяцев)

Простите, но вы неверно поняли. "Фсё" пришло к баранам, которые сделали кассу мокрософту. И теперь бараны будут платить и каяццо.

Аватар пользователя Брейгель
Брейгель(5 лет 3 месяца)

 У баранов тоже на полшестого? Нет? Не будут тогда платить.

Комментарий администрации:  
*** Возбужденное чмо ***
Аватар пользователя gruzzy
gruzzy(7 лет 7 месяцев)

может и найдутся особо "одаренные". Но очевидно же, что платить не за что.

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

Аватар пользователя Twin
Twin(9 лет 11 месяцев)

Да, да, пользуюсь 1С на постгрес =)))

Аватар пользователя 2tvlad
2tvlad(3 года 8 месяцев)

Ага и мы тоже, уже года два.

Аватар пользователя Sergeantez
Sergeantez(6 лет 8 месяцев)

А вот специалисты говорят, что на постгрессе 1С медленнее работает... Да и сколько у вас пользователей? И какое железо на ваше количество пользователей? 

Аватар пользователя И-23
И-23(6 лет 4 месяца)

Вопрос в первую очередь компетенции специалистов.
Начиная с оптимизаций под особенности реализации конкретной БД.

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

Как Вы считает, какой рост производительности при этом наблюдался? ☺ Ну хотя бы порядок величин…

Аватар пользователя Twin
Twin(9 лет 11 месяцев)

Помню мы с админом два дня настраивали в винде дрова для подключения 1С к ораклу. Та еще песня :)))

А так, если руки с одного места растут, то разницы особой не будет. Что MS что Posgres

Аватар пользователя 2tvlad
2tvlad(3 года 8 месяцев)

Оптимизатор запросов в MSSQL сильнее, чем в Постгре. Правда в Оракле он сильнее, чем в MS =))) Да и ГРИД в оракле, оставляет MS далеко позади. 

Аватар пользователя mentat
mentat(10 лет 1 месяц)

Ну так вопрос цены и задач. Возможностей постгреса хватит в 99% случаев для малого/среднего бизнеса

Аватар пользователя 2tvlad
2tvlad(3 года 8 месяцев)

Ага. Многие понять не могут что цена решения - это цена сервера + цена лицензий. И если отказаться от лицензий MS можно позволить себе сервер много лучше. 

Аватар пользователя И-23
И-23(6 лет 4 месяца)

В Вашей модели куда-то потерялось сопровождение.

Аватар пользователя 2tvlad
2tvlad(3 года 8 месяцев)

Цена сопровождения MS и Постгре примерно равна.

Аватар пользователя aftorshog
aftorshog(4 года 4 месяца)

"Правда в Оракле он сильнее, чем в MS"

Инфа 100% ?

В МС-СКЛ действительно хороший оптимизатор.

Аватар пользователя 2tvlad
2tvlad(3 года 8 месяцев)

Да, правда. Гуглите Оракл-грид. Там чудеса до которых мс "писать и писать".

"В МС-СКЛ действительно хороший оптимизатор."

Хороший. Но в оракле он лучше. Когда МС сделает что то похожее на грид, тогда посмотрим.

Аватар пользователя aftorshog
aftorshog(4 года 4 месяца)

Кажется, оптимизатор запросов и система распределенных вычислений не одно и тоже.

Аватар пользователя 2tvlad
2tvlad(3 года 8 месяцев)

Не совсем. Это означает, что оптимизатор умеет работать с распределенными данными. И глупо было бы не применить эту модель к локальным данным, которые на физическом уровне так же "распределены".

Аватар пользователя aftorshog
aftorshog(4 года 4 месяца)

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

Аватар пользователя Sergeantez
Sergeantez(6 лет 8 месяцев)

При чем тут оракл, если речь изначально шла про MSSQL? 

Аватар пользователя И-23
И-23(6 лет 4 месяца)

При том, что иллюстрируется пропущенный Вами вопрос администрирования сервера БД.

Аватар пользователя BMSerg
BMSerg(5 лет 4 месяца)

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

Как Вы считает, какой рост производительности при этом наблюдался? ☺ Ну хотя бы порядок величин…

Опыт подсказывает что от одного до полутора порядков.

Аватар пользователя katu
katu(9 лет 11 месяцев)

Видно мало у вас опыта. Безграмотными настройками можно так упороть сервер, что потом такой простор для улучшения производительности останется, там и два и три порядка легко можно получить. Непонятно, что сравниваем.

Аватар пользователя 2tvlad
2tvlad(3 года 8 месяцев)

Не думаю. Все же обычно стоят настройки по умолчанию. Мало кто лезет и начинает "творить". Тем более настройки того же МС жутко не очевидны.

Другое дело, оптимизация под нагрузку. Но и тут есть проблемы. Я помню мы делали "профили" один для обычной работы, а другие для закрытия периода. Когда бух хотела закрыть период, то сначала профили, потом рестарт сервиса, потом только старт закрытия =))) потом опять смена профиля, потом опять рестарт.

Задача была за ночь период гарантировано закрылся.

Так что задача оптимизации очень интересная и творческая.

Аватар пользователя katu
katu(9 лет 11 месяцев)

Ну там же вопрос был задан явно с подвохом ☺ так что ожидать можно было чего угодно :) В 1С я не специалист, но все же интересно, чего там такого у нее внутри может быть, что для сервера БД в разных ее режимах требуются шибко разные настройки? Речь о Микрософте?

Аватар пользователя 2tvlad
2tvlad(3 года 8 месяцев)

1С общается с серверами на SQL92... что дает возможность использовать разные БД. Но. это рождает и трудности с быстродействием. Т.к. тот же оракл \ мс могут использовать разные расширения, например для графов. Что, конечно делает запросы много быстрее, с другой под каждую БД нужно писать свои обработчики.

Речь про постргре.

Что касается оптимизации, например, память. При работе в хх человек, памяти выделяется около 16 гбайт на 1С и 16 на посттгре. Когда закрывается период, то 6 на 1С, все остальное на постгре. Там же размер журналов увеличиваются, что бы не записывались часто, увеличиваются все кеши ну и т.д. Т.е. при закрытия периода идет оптимизация на чтение. При работе 100 чел на запись. Ибо главное это быстрая запись документа и выставление счета =)))

Аватар пользователя katu
katu(9 лет 11 месяцев)

Надо было на сэкономленные на микрософтовских лицензиях деньги воткнуть в сервер еще на 16 гбайт больше и не мучиться :)

Аватар пользователя 2tvlad
2tvlad(3 года 8 месяцев)

"Речь про постргре." читайте внимательно. И так сэкономили и воткнули и 2 проца и памяти в 2 раза больше и рейд на SSD. Но написание скрипта для оптимизации работы сервере стоила не так уж и дорого, а пользы от нее вагон. Ибо кроме закрытия периода, ночью 1С выполняет миножество других процедур, от проверки контрагентов в ФНС до расчета себестоимости...

Аватар пользователя katu
katu(9 лет 11 месяцев)

читайте внимательно. И так сэкономили и воткнули и 2 проца и памяти в 2 раза больше и рейд на SSD

я так и понял, просто решил, что еще 16 гигов не такая уж большая роскошь по нынешним временам :)

Вообще с 1С сталкивался последний раз больше десяти лет назад, и мне интересно поменялось ли что-нибудь с тех пор, в плане оптимизации работы с базой со стороны приложения. Я в том смысле, что раньше 1С базу использовала исключительно как помойку, просто сваливая туда данные, и о том, чтоб обрабатывать данные на стороне базы, 1Сные разработчики, похоже, даже не задумывались.

Аватар пользователя 2tvlad
2tvlad(3 года 8 месяцев)

И как масштабировать то логику и нагрузку в БД?

1С может использовать кластер серверов приложений. Ну например на 1000 пользователей - 10 физических серверов по 100 пользователей на сервер с балансировкий нагрузки и резервированием, горячей переброской сессий пользователей на другой сервер и прочими чудесами. И все они используют один сервер БД, "как помойка". 

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

Пока не будет стандарта по распределенным вычислением, и их реализации в БД, думаю и 1С и другие системы типа Microsoft Axapta (такой же принцип) не будут менять логику работы.

Аватар пользователя katu
katu(9 лет 11 месяцев)

Ну не обязательно прям всю логику в базу запихивать, и собственно распределенные вычисления ста пользователям могут быть и не нужны, достаточно распределить самих пользователей, как вы написали. Нагрузку на чтение Микрософт уже научился распределять. Но речь скорей про то, что данные можно обрабатывать очень по разному, некоторые на SQL умудряются такие скрипты писать, которые потом сервер БД и за сутки пережевать не может, тогда как то же самое, написанное специалистом, выполняется за несколько минут.

Аватар пользователя 2tvlad
2tvlad(3 года 8 месяцев)

Все же обычно 1С используется как база для ввода данных. Множество договоров, продаж, банковских транзакций и т.д. Получение информации, читай отчетность с аналитикой, можно вывести в отдельные OLAP кубы. Что на мой взгляд эффективнее. 

Да эффективность sql92 и транзакт\пл-sql очень разная. Но опять же, именно этим 1С уходит от единого поставщика баз данных делая решение много дешевле.

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

 

Аватар пользователя katu
katu(9 лет 11 месяцев)

И все же есть вещи, которые могут быть весьма эффективно выполнены на стороне БД. Вы же понимаете, что СУБД это не только про "сложить и выдать обратно". Некоторые процессы уже оптимизированы их создателями и нередко на порядки лучше, чем это могут сделать доморощенные разработчики приложений.

Аватар пользователя 2tvlad
2tvlad(3 года 8 месяцев)

Да, могут быть выполнены. Но не всегда. Все же та же 1С заточена на бизнес-логику. И в 1С я с понятными заранее трудозатратами нарисую бизнес-процесс утверждения документа. Как насчет графа в 40 действий + 50 условий ветвления? А как насчет его изменения так, что старые документы идут по старому БП, а новые по новому =)))

В SQL, такое сделать можно. Но дико сложно. А в 1С есть стандартные механизмы. Графический интерфейс, отображающий пользователю что и как утверждается. На выходе задачи пользователям и документ.  Все это учитывая сложный доступ, включая заместителей и т.д.

Но самое главное, от SQL этот механизм не требует особых ресурсов. Так слезы. Вся логика реализована на сервере приложений. 

Ну и самая главная беда всех SQL они не умеют вести обработку данных на клиенте =))) Потому что я считал массив, он висит в памяти и мне нужно найти там максимум. На SQL понятно, повторный запрос и в дамках. А в 1С можно обойтись без серверного вызова, сделать на клиенте, у которого ресурсов навалом =))))

Аватар пользователя katu
katu(9 лет 11 месяцев)

Ну на клиенте клиент и ведет обработку данных, как ему надо, то есть ровно всё так, как вы и хотите :) Только вот заканчивается это тем, что когда пользователю нужно только найти максимум, шибко умный клиент запрашивает весь массив и ищет его там, увеличивая тем самым нагрузку и на клиента и на сервер БД на несколько порядков. В итоге, когда сто таких клиентов подключается к базе, создается впечатление, что база не тянет и необходимо срочно что-то масштабировать, а на самом деле проблема просто в подходе.

Аватар пользователя 2tvlad
2tvlad(3 года 8 месяцев)

Не совсем. Если предлагаете передать бизнес логику на SQL то SQL должен иметь возможность работать как сервер приложений =))))  а он не умеет.

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

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

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

Для этого у 1С есть кеширование, включая кеш выполнения функций. Если вы даете ей одинаковые параметры, она вам вернет то же значение. Кешированием вы можете управлять, что по сессии, что по вызову. Если клиент запросил кол-во документов, то второй раз он получит их мгновенно. Читай хранимая вьюха, только процедура\функция =))))

 

Аватар пользователя katu
katu(9 лет 11 месяцев)

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

Аватар пользователя 2tvlad
2tvlad(3 года 8 месяцев)

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

согласен.

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

Да. а если у вас уже есть массив с документами? Зачем дергать сервер? Проще дернуть массив, который вернет кол-во быстрее, чем серверный вызов.

"Последовательная обработка - тоже отдельная песня, когда речь идет об MS SQL. Например, разработчики не сильно знакомые с особенностями сиквела, любят открыть курсор и обрабатывать свой массив данных построчно, тогда как те же самые действия можно производить сразу над всем массивом, что может быть выполнено сервером в сто раз быстрее."

Когда у вас расчет данных в одном документе, влияете на расчет данных в другом? Ну например задача оптимизации резервирования остатков. Т.е. если в документе, есть 100% предоплата, и клиент хочет получить часть товара уже завтра, то он будет отгружен в первую очередь, чем заказ по которому нет предоплаты. А еще нужно учесть товары в пути, наличие на складе, обороты по клиенту и т.д.

Это классическая задача по теории оптимизации (у меня используются штрафные баллы). И классически она решается только итерационными проходами. Да можно разбить на потоки по "коллекциям" номенклатуры. В худшем случае задача решается в один поток, в лучшем в n, где n = кол-во заказов.

Аватар пользователя katu
katu(9 лет 11 месяцев)

Да. а если у вас уже есть массив с документами? Зачем дергать сервер?

когда массив уже есть, понятно что незачем

Когда у вас расчет данных в одном документе, влияете на расчет данных в другом?

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

Аватар пользователя 2tvlad
2tvlad(3 года 8 месяцев)

Спасибо вам за диалог. Было познавательно.

Аватар пользователя katu
katu(9 лет 11 месяцев)

Взаимно.

Аватар пользователя И-23
И-23(6 лет 4 месяца)

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

Аватар пользователя katu
katu(9 лет 11 месяцев)

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

Ну, судя по всему, 1Сникам это не грозит :) я про проектирование

Аватар пользователя BMSerg
BMSerg(5 лет 4 месяца)

Безграмотными настройками можно так упороть сервер ...

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

Аватар пользователя И-23
И-23(6 лет 4 месяца)

Если бы действительно считал — мы бы хотя бы знали что такое «домен AD».

А ещё результат оценки сильно зависит от уровня анализа.
Полагаю, феерию, сопутствующую включению линукс-сервера в домен со стороны увидеть… сложно, а верифицировать — скорее невозможно.

Аватар пользователя roman.kuvaldin
roman.kuvaldin(10 лет 1 месяц)

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

Аватар пользователя И-23
И-23(6 лет 4 месяца)

Вы исходите из результатов анализа содержимого чёрного ящика.
Что далеко не всегда реализуемо. И дело даже не в известной карикатуре о чтении чужого кода…

Товарищ выше правее ☺ Но недостаточно радикален ☺

Аватар пользователя BMSerg
BMSerg(5 лет 4 месяца)

Но недостаточно радикален ☺

У меня исходные условия не совсем ужас-ужас - выше написал почему. А так-то да, нет предела тупизне.

Аватар пользователя Хмурый ослик

Ну, оракл много чего позволяет и может.
Даже - изначально.
Помницца, исчо о 2001 годе, в эдинбургском охвисе Оракла народ конкретно прифигел, когда, вместо привычной, многолетней традиции аренды на три недели для обсчёта своего биллинга, Дойчетелеком вдруг запросил всего два с половиной часа... devil

Аватар пользователя 2tvlad
2tvlad(3 года 8 месяцев)

Да работает медленнее. Подтверждаю. Вот только если брать совокупную стоимость лицензий на MSSQL + сервер и Постгре + сервер... то на разницу можно позволить шикарный сервер =))) И рейд на SSD и памяти раза в 4 больше... И процессоры тактовой частотой побольше =))) 

И в итоге работает быстрее =)))

Страницы