:-) А производитель не подумал что его сервисы или подписки нужны пользователю "как собаке пятая нога"? Или "китайцы" не "заложившие" в цену "сервисы и подписки" получается умнее и эффективнее? По факту это просто желание и жадность Яндекса "доить" своих пользователей пока им "не надоест" платить в три дорого за "навязанный сервис".... :-) Про цену "пользовательских данных" получаемых от своих "платных сервисов" Яндекс очень скромно умалчивает.... :-)
Вот только о пользе облачных услуг вы вспомните когда "вдруг" оборвется связь с этим облаком (когда она вам реально будет нужна "здесь и сейчас")... :-)
:-) Не нужно маркетинговой шелухи, вы же не "человек с улицы".... Т.е. "в вашей колонке" не китайское копеечное железо с готовыми не китайскими библиотеками ПО? "Эксклюзивная" электроника собственной разработки (а не тупо трассировкой печатной платы под стандартную китайскую электронику)? Почему то "копеешная китайская копия" оказывается функциональнее и дешевле вашего "эксклюзива".... Вот только в чем "эксклюзив" можно пояснить? Чем Яндекс колонка технически лучше "Китайской" (при сравнимых розничных ценах), или Яндекс TV лучше Google/Андроид TV (на который при желании легко ставится любое ПО)? :-)
:-) А где вы увидели логическую связь между "Большинство успешных продуктов - коммерческие, с закрытыми исходниками" и "невозможностью использовать некоммерческое ПО поскольку поставщик делает все чтобы его невозможно было использовать"? На ваши исходники и коммерческое ПО никто и не претендует... Если оно "такое прекрасное" его никто и не будет "улучшать"... :-) Потребитель "покупает изделие", оно имеет цену, в эту цену поставщик уже включил и свои затраты и планируемую прибыль. После приобретения "изделия" покупатель в полном праве как не пользоваться навязанной ему "экосистемой" или "изделием", так и "модернизировать" (в том числе и программно) свое личное устройство по своему выбору. Или нет? А вот если нет - значит покупатель не купил "изделие" в собственность, а "взял в аренду" с соответствующими условиями договора аренды.... Как то так... :-)
:-) Не нужно строить из себя "человека не в теме"... - Для начала блокировка рекламы с известных хостов.... - Далее "вырезание" ее же, встроенную в предустановленные приложения - Далее установка "нежелательных" для "экосистемы" приложений (сторонних) Мне продолжать? Любители вашей экосистемы делать этого не будут, но производитель изо всех сил "упирается" чтобы те 10% которым ваша "экосистема" не нравится (хотя аппаратная платформа устраивает вполне) этого сделать не смогли.... Как можно "паразитировать" на инфраструктуре не имея к ней официального клиентского доступа? У вас она настолько "дырявая"? Да нет и никогда не было в вашей инфраструктуре чего-то "эксклюзивного", чего невозможно получить от других поставщиков.... Хотя на "человека не в теме" ваши маркетологи тратят много ресурсов.... :-)
А вот про ВСЕ и "копеечные" клоны не нужно рассказывать сказки... Поскольку именно с "таким подходом" вместо продукта которым хочется воспользоваться потребители получают "дерьмо обмазанное шоколадом"... Зачем программерам делать "хорошо и правильно"? Конечный пользователь будет "жрать" что ему дадут закрытые экосистемы и прошивки... Расходы на маркетинг на порядок превышают затраты на разработку.... Или как? У пользователя продукта "когда слижет шоколад" есть альтернатива?
:-) Так именно это я и хотел услышать... Так сказать "из первых уст"... Желание "прибить" пользователя к своей "экосистеме", не "выпускать" из нее (по факту приобретенное устройство пользователю "не принадлежит" раз его программную составляющую он не может контролировать) и "доить" его средства таким подходом - основной и безальтернативный подход Яндекса к своим пользователям... :-)
:-) Комментарий правильный.... 1) От разработчиков требуется полноценный программный продукт... С полноценной системой дистрибуции и обновления, мало того еще и масштабируемый (если клиентам это необходимо), и защищенный (если хранит/обрабатывает приватные данные) и безопасный (если не хотите получить проблемы со временем)... И это точно проблемы прикладных разработчиков, а не "дяди" администратора который будет этот продукт эксплуатировать. Администратору нужны указания/документация что он должен обеспечить, чтобы прикладной продукт работал безотказно и безопасно... И на нем же "висит" обязанность кроме прикладного ПО обеспечить "правильную эксплуатацию" системного ПО (ПО третьих производителей связанного с прикладным ПО). 2) Мало кого интересует сколько ресурсов требует "простаивающая система" - если она "простаивает" значит и ресурсы ей не нужны. "Умение" контейнеров "захватывать" ресурсы - требует времени на такой "захват", и если ваше прикладное приложение "по бизнес требованиям" может себе позволить "не отвечать" на время выделения ресурсов (или отвечать "повторите еще раз позже") - контейнеризация вам возможно подходит, а если после "простоя" приложения происходит "непредвиденный всплеск" нагрузки в 100 раз, ответ на которую требуется в течении 1 секунды - проблемы с "временем захвата" ресурсов и отказами в прикладной обработке будут. Разница же в потребляемых ресурсах (на высоконагруженных сервисах/приложениях) в пиках прикладной нагрузки между контейнерами и VM - малозначительна. Более того "вспомогательные" сервисы контейнеризации при абсолютной необходимости обеспечения их устойчивости к сбоям как правило нивелируют снижение требования к контейнеризированным прикладным сервисам (по сравнению с прикладными сервисами в VM). Общий вывод - если у вас "наколенная система" с 10 прикладными TPS, контейнеры ваш выбор. Если же у вас в пиках от 300TPS, миллионы хранимых в сутки операций (БД с десятками терабайт) и простой в 5 секунд недопустим (поскольку после него придется обрабатывать уже 1500TPS), то что-то вспомогательное (не критичное) вы можете "запихнуть" в контейнеры, но основную нагрузку вы в контейнеры просто "не впихнете"...
:-) Oracle так же много заявлял и заявляет и про RAC и про Exadata. А вот когда дело доходит до нагрузочных тестов конкретного прикладного приложения, и последующих вопросов к их специалистам "а почему собственно по факту ваши заявления не работают?", можно много нового узнать....
Про OLAP не скажу опыта маловато, но для OLTP (где Read/Write как 1/100) есть еще много проблем.... Начнем "с простого" в блоке реляционной БД "лежит" N записей (включая индексные блоки) и если обращаетесь из нескольких процессов транзакционно к разным данным в блоке - без блокировок (причем в RAM) не обойтись. Т.е. транзакции БД нужно делать как можно "короче", а вот использовать наиболее "легкую в реализации" транзакционную целостность БД в бизнес транзакциях (включающих множество изменений в БД) короткими сделать "часто не возможно" просто по их бизнес логике. Вот и приходится "городить" прикладную логическую транзакционность данных. Та же EXADATA "по факту" решает проблемы OLTP масштабирования (без партиционирования) скажем не очень идеально... Что же касается PG (PG ProEE) в плане "сравнения с Oracle" много в интервью озвучено, но есть "не затронутая" проблема "трассировки пользовательской сессии", и есть постепенные "сдвиги" в плане "хинтов запросов" (т.к. "хороший" разработчик прикладного ПО зачастую "понимает и знает" какими данными приложение "манипулирует", "как" и "в каких объемах/соотношениях", ну а стоимостные оценки БД для "тупых разработчиков" даже в Oracle не всегда "оптимально работают").
Вот когда прогноз погоды (хоть на пару дней вперед) станет совпадать с реальной погодой (а в какой области сейчас есть больше собранных данных и круче алгоритмы для их анализа?), вот тогда я и поверю в "магию" big data и ИИ алгоритмов...
:-) Прекратите уже делить системы на "монолиты" и "микросервисы", они бывают просто хорошо или плохо спроектированные. Более того в большинстве случаев (~80% , для больших систем) построение "смешанной" система будет более оптимальным технологическим выбором... Все "упирается" в нормальную аналитику при "первоначальном проектировании" архитектуры системы.
:-) Тут ситуация гораздо хуже... В паре банков я операционистам прямо говорил (когда становился клиентом). "Готов подписать бумагу/заявление, где я беру на себя ответственность за собственную удаленную аутентификацию только по паролю. Возможно у вас это сделать? Могу я сам определять безопасность собственных средств?" Ни один не предоставляет такую услугу.... :-(
:-) А кому не понятно что микросервисам (при той же прикладной производительности) при эксплуатации у клиента необходимо: - Больше вычислительных ресурсов - Больше организационных реурсов (персонала и его квалификации) Что "в прямую" влияет на эксплуатационные расходы....
:-) А производитель не подумал что его сервисы или подписки нужны пользователю "как собаке пятая нога"? Или "китайцы" не "заложившие" в цену "сервисы и подписки" получается умнее и эффективнее?
По факту это просто желание и жадность Яндекса "доить" своих пользователей пока им "не надоест" платить в три дорого за "навязанный сервис".... :-)
Про цену "пользовательских данных" получаемых от своих "платных сервисов" Яндекс очень скромно умалчивает.... :-)
Вот только о пользе облачных услуг вы вспомните когда "вдруг" оборвется связь с этим облаком (когда она вам реально будет нужна "здесь и сейчас")... :-)
:-) Не нужно маркетинговой шелухи, вы же не "человек с улицы"....
Т.е. "в вашей колонке" не китайское копеечное железо с готовыми не китайскими библиотеками ПО? "Эксклюзивная" электроника собственной разработки (а не тупо трассировкой печатной платы под стандартную китайскую электронику)?
Почему то "копеешная китайская копия" оказывается функциональнее и дешевле вашего "эксклюзива".... Вот только в чем "эксклюзив" можно пояснить? Чем Яндекс колонка технически лучше "Китайской" (при сравнимых розничных ценах), или Яндекс TV лучше Google/Андроид TV (на который при желании легко ставится любое ПО)? :-)
:-) А где вы увидели логическую связь между "Большинство успешных продуктов - коммерческие, с закрытыми исходниками" и "невозможностью использовать некоммерческое ПО поскольку поставщик делает все чтобы его невозможно было использовать"?
На ваши исходники и коммерческое ПО никто и не претендует... Если оно "такое прекрасное" его никто и не будет "улучшать"... :-)
Потребитель "покупает изделие", оно имеет цену, в эту цену поставщик уже включил и свои затраты и планируемую прибыль. После приобретения "изделия" покупатель в полном праве как не пользоваться навязанной ему "экосистемой" или "изделием", так и "модернизировать" (в том числе и программно) свое личное устройство по своему выбору. Или нет?
А вот если нет - значит покупатель не купил "изделие" в собственность, а "взял в аренду" с соответствующими условиями договора аренды....
Как то так... :-)
:-) Не нужно строить из себя "человека не в теме"...
- Для начала блокировка рекламы с известных хостов....
- Далее "вырезание" ее же, встроенную в предустановленные приложения
- Далее установка "нежелательных" для "экосистемы" приложений (сторонних)
Мне продолжать?
Любители вашей экосистемы делать этого не будут, но производитель изо всех сил "упирается" чтобы те 10% которым ваша "экосистема" не нравится (хотя аппаратная платформа устраивает вполне) этого сделать не смогли....
Как можно "паразитировать" на инфраструктуре не имея к ней официального клиентского доступа? У вас она настолько "дырявая"? Да нет и никогда не было в вашей инфраструктуре чего-то "эксклюзивного", чего невозможно получить от других поставщиков.... Хотя на "человека не в теме" ваши маркетологи тратят много ресурсов.... :-)
А вот про ВСЕ и "копеечные" клоны не нужно рассказывать сказки... Поскольку именно с "таким подходом" вместо продукта которым хочется воспользоваться потребители получают "дерьмо обмазанное шоколадом"...
Зачем программерам делать "хорошо и правильно"? Конечный пользователь будет "жрать" что ему дадут закрытые экосистемы и прошивки... Расходы на маркетинг на порядок превышают затраты на разработку....
Или как? У пользователя продукта "когда слижет шоколад" есть альтернатива?
:-) Так именно это я и хотел услышать... Так сказать "из первых уст"...
Желание "прибить" пользователя к своей "экосистеме", не "выпускать" из нее (по факту приобретенное устройство пользователю "не принадлежит" раз его программную составляющую он не может контролировать) и "доить" его средства таким подходом - основной и безальтернативный подход Яндекса к своим пользователям... :-)
А есть с этим действием большие проблемы? Наверно только если получаете готовые "китайские" сборки...
:-) А в чем смысл прошивать "готовое изделие" вместо прошивки "микросхемы ПЗУ"? И в чем смысл теста изделии не на "родном блоке питания"?
:-) Комментарий правильный....
1) От разработчиков требуется полноценный программный продукт... С полноценной системой дистрибуции и обновления, мало того еще и масштабируемый (если клиентам это необходимо), и защищенный (если хранит/обрабатывает приватные данные) и безопасный (если не хотите получить проблемы со временем)... И это точно проблемы прикладных разработчиков, а не "дяди" администратора который будет этот продукт эксплуатировать. Администратору нужны указания/документация что он должен обеспечить, чтобы прикладной продукт работал безотказно и безопасно... И на нем же "висит" обязанность кроме прикладного ПО обеспечить "правильную эксплуатацию" системного ПО (ПО третьих производителей связанного с прикладным ПО).
2) Мало кого интересует сколько ресурсов требует "простаивающая система" - если она "простаивает" значит и ресурсы ей не нужны. "Умение" контейнеров "захватывать" ресурсы - требует времени на такой "захват", и если ваше прикладное приложение "по бизнес требованиям" может себе позволить "не отвечать" на время выделения ресурсов (или отвечать "повторите еще раз позже") - контейнеризация вам возможно подходит, а если после "простоя" приложения происходит "непредвиденный всплеск" нагрузки в 100 раз, ответ на которую требуется в течении 1 секунды - проблемы с "временем захвата" ресурсов и отказами в прикладной обработке будут. Разница же в потребляемых ресурсах (на высоконагруженных сервисах/приложениях) в пиках прикладной нагрузки между контейнерами и VM - малозначительна. Более того "вспомогательные" сервисы контейнеризации при абсолютной необходимости обеспечения их устойчивости к сбоям как правило нивелируют снижение требования к контейнеризированным прикладным сервисам (по сравнению с прикладными сервисами в VM).
Общий вывод - если у вас "наколенная система" с 10 прикладными TPS, контейнеры ваш выбор. Если же у вас в пиках от 300TPS, миллионы хранимых в сутки операций (БД с десятками терабайт) и простой в 5 секунд недопустим (поскольку после него придется обрабатывать уже 1500TPS), то что-то вспомогательное (не критичное) вы можете "запихнуть" в контейнеры, но основную нагрузку вы в контейнеры просто "не впихнете"...
Для некоторых (у которых минимум 100TPS финансовых транзакций) "это имеет значение"... :-)
:-) По безопасности первое место во всех тестах занял выключенный и запертый в банковский сейф компьютер...
:-) Oracle так же много заявлял и заявляет и про RAC и про Exadata. А вот когда дело доходит до нагрузочных тестов конкретного прикладного приложения, и последующих вопросов к их специалистам "а почему собственно по факту ваши заявления не работают?", можно много нового узнать....
:-) Спасибо посмотрю. Правда поддержка ванильной версии не заявлена, но попробовать наверно можно.
:-) - Кому и кобыла невеста....
Про OLAP не скажу опыта маловато, но для OLTP (где Read/Write как 1/100) есть еще много проблем....
Начнем "с простого" в блоке реляционной БД "лежит" N записей (включая индексные блоки) и если обращаетесь из нескольких процессов транзакционно к разным данным в блоке - без блокировок (причем в RAM) не обойтись. Т.е. транзакции БД нужно делать как можно "короче", а вот использовать наиболее "легкую в реализации" транзакционную целостность БД в бизнес транзакциях (включающих множество изменений в БД) короткими сделать "часто не возможно" просто по их бизнес логике. Вот и приходится "городить" прикладную логическую транзакционность данных.
Та же EXADATA "по факту" решает проблемы OLTP масштабирования (без партиционирования) скажем не очень идеально...
Что же касается PG (PG ProEE) в плане "сравнения с Oracle" много в интервью озвучено, но есть "не затронутая" проблема "трассировки пользовательской сессии", и есть постепенные "сдвиги" в плане "хинтов запросов" (т.к. "хороший" разработчик прикладного ПО зачастую "понимает и знает" какими данными приложение "манипулирует", "как" и "в каких объемах/соотношениях", ну а стоимостные оценки БД для "тупых разработчиков" даже в Oracle не всегда "оптимально работают").
Вот когда прогноз погоды (хоть на пару дней вперед) станет совпадать с реальной погодой (а в какой области сейчас есть больше собранных данных и круче алгоритмы для их анализа?), вот тогда я и поверю в "магию" big data и ИИ алгоритмов...
:-) Прекратите уже делить системы на "монолиты" и "микросервисы", они бывают просто хорошо или плохо спроектированные. Более того в большинстве случаев (~80% , для больших систем) построение "смешанной" система будет более оптимальным технологическим выбором... Все "упирается" в нормальную аналитику при "первоначальном проектировании" архитектуры системы.
:-) Тут ситуация гораздо хуже...
В паре банков я операционистам прямо говорил (когда становился клиентом). "Готов подписать бумагу/заявление, где я беру на себя ответственность за собственную удаленную аутентификацию только по паролю. Возможно у вас это сделать? Могу я сам определять безопасность собственных средств?"
Ни один не предоставляет такую услугу.... :-(
:-) А кому не понятно что микросервисам (при той же прикладной производительности) при эксплуатации у клиента необходимо:
- Больше вычислительных ресурсов
- Больше организационных реурсов (персонала и его квалификации)
Что "в прямую" влияет на эксплуатационные расходы....