Может надо просто смотреть уже? Не в плане "все в мейнфрейм", а в плане "зачем вам новый мейнфрейм, если есть cloud"? Куча приложений крутится, для которых стоимость фрейма не оправдана. Как ЖД централизовала центры, и все будут работать далее удаленно. Значит и фрейм мог бы стоять не у ЖД самой, а сдаваться в аренду.

Сергей, это большая ошибка: отождествлять облака просто с неким удаленным сервисом. Масса облаков в корпорациях вовсе даже не удаленно предоставляют доступ, а внутри своей сетевой инфраструктуры. Облако, по определению, обладает следующими характеристиками:
- виртуализированность ресурсов, отвязка от реальных мощностей;
- автоматизированное выделение требуемых мощностей;
- учет потребленных ресурсов.
Таким образом основное отличие облаков от нынешних уже запущенных сервисов - это пункты 1 (там где не слишком развита клиентская и серверная виртуализация) и пункт 2.

Так вот мейнфреймы уже сейчас дают все это, кроме второго пункта (ресурсы по запросу), и даже второй пункт дают легко после минимальных доработок. И все это может стоять внутри компании, то есть быть частным облаком. И тот же РЖД вполне готов создавать такие внутренние частные облака, если оно будет ему надо.
Возвращаясь к Вашему замечанию - если РЖД или другой корпорации предложат облако с аналогичными применяемым приложениям, то совсем не факт, что РЖД вынесет свои информационные активы во вне. Скорее, они решат построить облако у себя внутри. Будет ли это мейнфрейм - другой вопрос. Для меня важно другое - предлагают ли облака некое новое качество сервиса по сравнению с мейнфреймовской инфраструктурой? Сильно сомневаюсь.

Облако, это всегда сервис. Если внутри, то это "IT as a service". Я вообще то в курсе что такое private cloud, так как моя компания учавствует в их популяризации и VMWARE это тоже почти наша собственность. Вопрос был, что мы можем предложить широкой аудитории, я сказал, что можно начать с узкой. Мейнфрейм с правильно настроенным сисплексом уже почти облако. Джобы бегают с железа на железо, SMF все собирает, Tivoli считает. Автоматизация не очень, то тоже все делится динамически между логическими LPAR.

мейнфрейм с сисплексом потому не облако, что не дает пользователю доступ к ресурсам и приложениям по запросу автоматически. его для этого сильно настраивать надо, и с RACF-ом идти на компромисс. но естественно, все это сделать можно и не с заоблачными затратами. другое дело - есть ли в этом потребность у пользователей, которые до этого на мейнфрейме не сидели?
что касается "IT as a service", то оно вообще и не внутри может, а может быть снаружи, если довести идею аутсорсинга до идиотизма. также как и SaaS, IaaS и PaaS могут лежать и внутри, и снаружи корпорации. Просто я думаю, что как публичный сервис облачные мейнфреймы с проприетарными платформами и приложениями не будут реально распространены никогда, а как внутренние сервисы мейнфреймовские облака возможны, но маловероятны в силу того, что никакого кардинально нового гешефта пользователи не получат, а вот ресурсы какие-никакие на создание такого счастья потратить надо!
Облако всегда сервис по бизнес-терминологии, если понимать под сервисом услугу в ее общем смысле. Если же говорить в техническом, программистском смысле, то выложенная в облако голая виртуальная машины (Intel или другой архитектуры) вполне может теоретически быть востребована, предлагая к потреблению не готовые софтовые сервисы, а всего лишь платформу для их создания...
попутно замечаю - очень много смыслов и контекстов у слова "сервис". надо что-то делать, а то запутаемся.

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

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

Вообще-то юное дарование почти право, особенно если будет продавать эти данные по требованию и быстро добавлять новые точки сбора и повышать точность замера.
Виртуализация, автоматизация - это не облако, а текущая его реализация или просто удобство пользования. Мне вот наши гении сделали ежедневный бекап вин-сервера в wmware, но не сделали авто-ресто. У меня даже кнопки нет. Я должен писать письмо запрос на ресто такого-то дня. Так что, это не облако? Так вот, облако - это продажа чистой силы, а не ее источника. Мейнфрейм превращается в облако, если ваш отдел платит за мощности, а не за железо. Это трудно понять системному программисту. Скажем так, за vmware тоже стоит реальная стойка железа и кто-то там меняет процессора, докупает блейды и тянет кабели. Для техников это не облако, а реальное железо. А облако оно просто потому, что железо принадлежит техникам и отдел платит за 2Гц и 60Гб. В обычной старой схеме, отдел владеет сервером и платит только за аренду места в зале и тех обслуживании. Фрейм уже умеет делиться на LPAR, балансировать нагрузку, распределять вычисления и делать рековери. Главный вопрос - это как быстро можно поднять новый сервер на существующем железе. То, что в wmware занимает пару кнопко-тыков, на фрейме целый процесс.
Ну и теперь, кому эти мощности продавать? Только тем, кто уже имеет фрейм приложения. Вы правильно заметили, что новым людям фрейм-облако не продашь, так как нет приложений или они очень дороги, а отдачу за 5 лет тяжело подсчитать.

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

Главное чтобы IBM нас поняло и докрутило все гайки. Они вроде что-то делают, но тааак медленно.

Чем обеспечена максимальная защищённость базы, если по определению мы не контролируем, кто запрашивает сервис?
Никакой разницы, если база будет не в z/OS. Грубо говоря, два пользователя - администратор, и все остальные.
Опять же - нет проблем на каждый web запрос порождать отдельный address space, который будет выполнять работу для запросившего с известным уровнем изоляции - напуркуа туча виндов и линуксов?
Принципиально - в чём разница между кучей address space и тучей виндов/линуксов?
Пользователю не по барабану ли?
А как проще IT персоналу? Пользователям вообще по барабану, но IT персоналу проще если куча address spaces. Вообще облака предназначены для экономии на IT. то есть это - для IT-шников. А не для пользователей.

Защищенность здесь это не только прав\неправ, но и про availability 24\7, и в том числе и устойчивость к тысячам запросов и отказам. Далее, разница фрейм\не фрейм в цене обработки запроса и наличии уже готовых приложений. Можно еще и скорость упомянуть. Кучу работы можно делать быстро и дешево на линуксе и только по необходимости ходить в дорогой и тормозной мейнфрейм(не у всех же последние модели и по 10 процессоров включено). Может кто-то знает секрет почему САП не стоит на фрейме где живет его база? Я бы послушал про всемогущие адрес спейсы...

Куча работы будет выполнятся самым дешёвым способом, если она снесена в один бокс.
Чем больше в него напихать - тем ниже стоимость единицы работы.
Грубо говоря, Db2/Z для SAP - это экономический нонсенс, бред, и не имеет смысла.
Куча работы, размазанная по тысячам машин - самый дорогой способ выполнения работы

Кстати, про SAP - они самостоятельная компания. Сами что хотят, то и делают.
Но запросы к ним на "всё в z/OS" уже поступают.
Вы будете смеятся - есть запрос "1C в z/OS" !!
А уж свой любимый "кааагнас" (Cognos) IBM так давно уже со всех сил тащит в z/OS, уже втащили и раздали на тестирование крупнейшим клиентам/партнёрам.
Тенденция есть, и очень сильная.
А SAP пусть сиськи мнёт, потом или в P Blades в составе z196 войдёт, или даже не знаю, может и переделывать начнут, хоть в USS.
Кстати, по этой теме, или близко.
Вот на встрече шла речь, akost пропустил, видимо.
Крупнейший пользователь Z проводит уже многолетнюю планомерную консолидацию, как Z, так и перенос всякой фигни в Z. Так вот есть проблемы с кучей программ, работающих под zOS - их невозможно централизовать, то есть вместо кучи мелких одинаковых на разных машинах, иметь одну но большую, на одной машине. Ну так вот разработчики писали. Теперь без переделки не централизовать. А на переделку нет средств. Так и плодят кучи LPAR мелких, и распихивают по ним програмки, те поделии ещё и на современном железе не идут...
Сильно дорого обходятся архитектурные просчёты.
А тоже, когда писали, надеялись на постоянный рост вычислительной мощности, и что всё будет нормально. Угадали, да, мощность растёт.
А вот что когда-то встанет задача централизации - не угадали.

Гриша, я про эту консолидацию у "одного крупного пользователя System Z" слышу очень давно. И появилась россыпь слабоконсолидированных приложений не потому, что программисты так написали, а потому, что программисты выполнили определенные, навязанные извне условия. И эту россыпь можно и нужно собирать не в LPAR-ы, а по человечески под zVM с дальнейшей постепенной консолидацией на уровне приложений. И опять же - не ресурсов не хватает, чтобы сделать, а не хватает ресурсов, чтобы сделать именно так, как это видят конкретные архитекторы.
Вообще консолидация - это очень, как мы понимаем, нелинейный и не всегда благотворный процесс. Особенно если этот процесс идет без учета ресурсов и архитектуры.

1. Да никто ничего программистам не навязывал. Привязатся к 3380 дискам их под угрозой расстрела застявляли?
2. Не принципиально - LPAR или zVM - речь шла о невозможности централизации. Консолидация идёт, не в ней речь. Не путай консолидацию и централизацию, под ними я имею в виду
- консолидация это совмещения разных задач на одних мощностях
- централизация это замещения множетсва однотипных задач одной более крупной
3. не хватает ресурсов на переделку. на переделку архитектуры с целью централизации задач ресурсы просто не выделяются. так что тут я не понял, о чём ты начал.

тогда давай по пунктам.
1) программисты - люди подневольные. и решение привязаться к архитектуре дисков - это не принципиальная проблема ни для консолидации, ни для централизации. есть масса возможностей обойти это ограничение. а вот выбор архитектуры приложения - это, как правило, не прерогатива программистов, особенно в больших конторах. как правило, программисты просто реализовуют волю, имея очень небольшие допуски на действия. так что если было написано так, что мешает принять архитектурное решение, значит была реализована другая архитектура. и реализована неслучайно. так вот - сменились ли те предпосылки, которые привели к принятию децентрализованной архитектуры? есть ли у бизнеса желание консолидироваться? оно ему нужно? какие преимущества, понятные для архитекторов и управленцев? а 3380 - фигня. побеждаемо непринципиальными усилиями.
2) слабоконсолидируемые - это те, которые хреново консолидируются потому, что были спроектированы, чтобы работать в одиночку. я видел такие, даже в моей конторе, когда два приложения в одной бизнес-цепочке работают каждая со своей базой и СУБД, по своей архитектуре, написанные на своих средствах разработки и даже интерфейс у них разный до неузнаваемости. там только реинжениринг.
3) ресурсы не выделяются не зря. в первую очередь потому, что бизнесу пофиг. понимаешь, Гриша, что у нас ИТ не есть часть бизнеса? и не распределяет ресурсы (и, наверное, к лучшему, а то бы нараспределяли....). Поэтому еще раз скажу непопулярное среди ИТ-шников - любое ИТ-решение должно быть не только технически обусловлено, но и бизнес-мотивировано. А наши ИТ-заморочки типа "так технически правильнее" - это только наша любовь к искусству.

1. Я вообще не понял, с чего ты вдруг стал про программистов. Я вообще-то писал про разработчиков, и про архитектуру систем, мешающую централизации. Ты же начал про кодеров.
А я - про разработчиков, цельный отраслевой институт.
2. Ты путаешь централизацию и консолидацию. Не бывает "слабоконсолидированных" приложений. Не мешает ничто поставить два разных приложения со своими собственными базами данных в один бокс в разные LPAR - и пусть себе работают в одиночку. Или на разные образы в VMWare - и пусть таки опять себе работают в одиночку.
3. Этот пункт вообще не в тему. Во всняком случае в твоём изложении. Ты наверное хотел сказать, что не эффективные IT системы никак не влияют на доходы отдельных личностей в нашей стране. Ну так это так и есть. И до тех пор, пока ситуация не изменится, будут процветать такие, как наш общий знакомый...

к п3. Так ведь и эффективные ИТ-системы тоже не влияют на бизнес, вот ведь какая хохма! я собственно что хочу пунктом 3 сказать - что проблема невыделения ресурсов состоит в том (часто), что ИТ не может доказать обоснованность своих запросов. Почему не может? тысяча причин. одна из них - то, что зачастую наши технические посылы вообще не подкрепляются бизнес-требованиями. так что пункт этот сильно в тему - в тему ресурсов для централизации, и о том, кому нужна та централизация.
2) не "слабоконсолидированные", а слабоконсолидируемые - те, которые только в образе отдельном и живут. пример - есть два приложения. их можно собрать в одно приложение, в одну систему или в два образа. в первом случае - гуд, совсем хорошо, как бывает когда приложения 1С объединяют в одной прикладной конфигурации. Это централизация. второй случай - компромисс на операционных расходах, пример - приложения на одном сервере приложения или с единой базой или с единым сервером базы и т.д.. это тоже бывает интересно. а третий - типичная консолидация, как у меня в описанном выше случае. или я что-то не так понимаю? так вот, слабоконсолидируемые приложения - это третий случай.

"слабоконсолидированные" приложения - это как?
бывают слабо интегрированные.

в дополнение к комменту 57 - те приложения даже конфликтовали между собой внутри одной системы)))

ничто не мешает их иметь в разных образах ОС.
То есть консолидировать - можно.

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

Не знаю, что там идёт от вас, но я впервые его услышал совсем не применительно к вам.
и 1С я никак не связываю с консолидацией.
То ли я внятно написать не смог, то ли ты меня внятно понять не смог

Консолидация сама по себе - мало что даёт, по сравнению с централизацией.
Было 1000 отдельно стоящих систем, консолидировали в 1000 систем на одном боксе. Ну и что?
А вот поиметь ОДНУ систему вместо 1000 - это немного другое по выгоде.

Гриша, централизация - это управленческая концепция. ИТ-шники не должны быть ее инициаторами. а если бизнес решит централизовываться - они найдут решение.
про 1С я тебе как-нибудь тоже отдельно расскажу.

А кто оспаривал, что
- централизация
- децентрализация
это концепции построения управления бизнесом?
Ты вот статью, которую своими руками разместил здесь на сайте - читал?
Чтой-то мне не верится....
Потому как там этот вопрос затронут.
Но тут приходит капитан Очевидность, и...

Гриша, ты чего сегодня такой противный? централизация, децентрализация - вещь обоюдоострая (привет, капитан Очевидность!). весь бизнес я строить не решаюсь. я больше думаю об отображении даже не структуры управления, а потребностей дядек с портфелями на нас, скромных тружеников.

воткну сюда еще мысль про адрес спейсы. Мне может нужен z/OS с другими параметрами? Может я хочу XRC только с util девайсами запускать. Или просто считаю, что все имеют право sys1.parmlib править как хотят и перегружать z/OS, не всё же динамически правится. Тоесть жить в пределах одного LPAR это утопия. Значит нужно несколько = LPARs, VM. А далее нужен механизм чтобы все это нарезать очень быстро, бекапить. А потом еще и отдать это во власть пользователя. В самом IBM я такого не видел, хотя и сапортил их систему которая по всему миру считает по SMF логам кто сколько цпу скушал и чего ему это будет стоить. Тоесть IBM научился продавать ресурсы, но не научился выделять столько сколько требуется. Платишь бешеные деньги за съеденный Гц, когда рядом 10 тупо простаивают.

Массово никому нафиг z/OS не нужен.
Массово нужены банковские услуги, страховые услуги, и так далее.
Потому я и писал - address space, в которых работают алгоритмы предоставления услуг.
Продажа образов операционок - это для маргиналов и для гиков.
Тоже можно делать, но это не будет таким массовым, как уже есть массово распространена услуга банкинга через интернет.

1. Не понимаю, почему "облако" это куча линуксов/виндоусов. Почему это не может быть куча zLinux'ов? Или куча прикладных систем? Feducia - предоставляет облачные сервисы? Очень похоже, но интелами и не пахнет. Чем проще управлять - 1000 боксов Intel с VMWare, или одним боксом Z с zVM?
2. Автоматизация. Выделения ресурсов. Дают мне доступ к Z, и проводят инструктаж. Вот заходишь терминалом, логинишся, получаешь панельку ISPF. Выбираешь, сколько и каких тебе процессоров, памяти, параметры дисковой подсистемы, перечень софта. Жмакаешь правый Cntrl - и в секунду получайшь собственную z/OS со всеми заказанными параметрами. Пишешь, компилишь, ломаешь всё к чёртовой матери - повторяешь процесс, получаешь новенькую исправную систему, и продолжаешь насиловать её в извращённом виде. Стоит это где-то в америках, на каких-то мощностях - мне фиолетово. Работает. Для меня, и кучи разработчиков-тестировщиков - чем не облако?
Детали мог и подзабыть, но выглядело именно так. Сильно сложнее, чем VMWare? Процесс? Я не думаю, что за этим стоит космическая технология. Наоборот, скорее всего кондово просто устроено. Работает каждый день, 24x7.
3. Кому нафиг нужен выделенный виртуальный сервер, даже если за малые деньги? Людям не нужны дрели, людям нужны дырки. Feducia предоставляет дырки восьми сотням коммерческих банков.

Вообще-то я как раз и говорил, что фрейм уже почти облако. Читайте внимательнее коллега. А тучи вин-линуксов потому что на них есть куча недорогих полезных приложений, а не z/Linux еще портировать надо. Как говорит Александр: "Построить можно. Что продавать будем?"

Пункт 2 звучит как сказка. Никогда не слышал. Видел только удобный vmware, где почему-то нет образа z/OS. Еще интересно сколько стоит лицензия на такое счастье и лицензия на запуск z/OS в ней? Боюсь, что многие предпочтут vmware после ответа. (хотя мне интересно, если правда)

Угу.
Сказка.
Мифология.
Народов мира.
Лююбой системщик на zVM такое сваяет на раз.
Только это никому не надо.
За этим нет денег.
Потому как никому ни z/OS ни Linux где-то там не нужны.
Сколько процентов населения хотят получить себе во владение образ операционки?
А сколько хотят пользоваться банковскими и страховыми услугами?

Предоставление выделенного виртуализованного сервера что VMWare с WIndows, что z/VM с z/OS или zLinux - это дрели. Никому нафиг не нужные. Сплошные понты и шум. Пошумят, и успокоятся. А Feducia заключит договора с новыми банками, и будет продолжать работу, без шума и пыли. 8 человек обслуживают 800 коммерческих банков. Хороший бизнес

Гриша, вот то, что ты сказал с заказом ресурсов - это фактически и есть облако, не сомневайся. Или почти облако, чтобы точно знать, что оно облако, надо знать, как там учитывают ресурсы, отданные пользователю, и как там заточен WLM на раздачу мощностей. Вообще "облако" - это всего лишь концепция. Причем явно менеджерская. И, как я много раз говорил, на мейнфреймах реализуемая с легкостью. Другое дело - кому продавать все это счастье. Да, Feducia нашла свою нишу. И там у нее точно будет или есть облако сервисов. А кроме?...

так в том то и задача - как говорил гениальный кот Матроскин, чтобы продать что-то ненужное, надо иметь что-то ненужное.
Нужно что-то предложить.
Реально полезное, чтобы закричали - дайте две!
А раз речь о "реально крутом" облаке, в публичном доступе - то сразу начинается, отдел борьбы с безопастностью скажет своё веское слово, если это компания, если частное лицо - тоже ничего серйозного не захотят... Как бы чего не вышло... Почта, документы, типа google mail, google doc - это пожалуйста.
Что-то серёзнее - это вряд ли.
Вот и получается детская игрушка.
А если глянуть по-пристальнее на бизнес Feducia.
Можно себе представить в принципе, чтобы наш кондовый российский банк отказался нафиг от своей банковской системы, и купил сервис этой системы у той же Feducia, которая имеет незапятнанную репутацию?
Я сильно сомневаюсь. Куча препятствий.
Привезли специалиста по Temenos. В наш банк.
Тот долго и красиво рассказывал, как всё будет зашибись после внедрения такого действительно полезного продукта.
Задают вопрос:
- а вот сегодня мы можем провести платёж двумя днями ранее?
- без проблем, делаете так и так, и вуаля.
- нет, вы не поняли, надо чтобы дата проводки была два дня назад, и чтобы все остатки с того момента пересчитать вот по-сейчас!
У мужика зрачки расширяются и глаза лезут из орбит:
- это не только невозможно, но мы сделали всё, чтобы это было в принципе невозможно!!!

Гриша, если бы ты видел глаза мужика из банка, который понял, что Feducia держит информацию из других банков? Он просто даже представить не мог, что кто-то из банков отдал вовне свою информацию.... У него глаза были даже не по 5 копеек величиной, а древняя шведская монета в 10 даллеров (почти 20 кг весом и размером с кухонный поднос)! А ты говоришь - проводки задним числом. Тут сама мысль о выводе информационных активов ставит мужика на уши...
Да бог с ними, с банками. Мы уже говорили - страховщики базу единую сделать не могут, пенсионный фонд работу по централизации не завершил, ГИБДД толковый единый доступ сделать не может, МВД сопли жует, хотя уж кому-кому... Вот там внутренние безопасные постоянно доступные облака делать надо, а не продавать воздушные услуги.

Почему я в гугле только Fiducia вижу? Это оно или не оно?

Да фиг его знает - немецкая фирма, продаёт доступ к банковским системам на IMS+DB2/Z
У меня есть и ролик, и презентация

FIDUCIA AG, они самые.

да не надо там никаких облаков.
там надо просто с самого начала начать.
просто системы делать, которые выполняют работу, автоматизируя деятельность.
а не то, что тут одну системку запустил, на клипере, чего-то нашёл, на листочек записал, выключил, запустил другую, чего-то нашёл, выполнил, на листочек записал, повернулся к другому компутеру, запустил там, чего-то сделал...
Не надо облаков.
Нужны системы, автоматизирующие деятельность, разумно централизованные, в части касающейся, разумно распределённые (нечего словари, обновляемые раз в год, держать центрально и лазить за ними в центр, к примеру), и так далее.
забыть надо про облака.
Ничего нового за этим нет.
Сколько крику было по поводу SOA?
Кого из мира Z (IMS, CICS) это удивило, или дало что-то новое?
Вау, оказывается наши поделки надо оформлять как сервисы, документировать интерфейсы, чтобы другие могли их вызвать, надо же!
Ессно и CICS, и IMS лабы тут же выставили лэйбл "SOA Ready!" потому как им нифига не пришлось менять, дабы это задекларировать.
ну да, для доступа по web сгавнякали gateway-чик, дабы транзакцию можно было вызвать чреез вэб и/или SOAP...
Хотя SOA != SOAP или web, это всего лишь один из транспортов.
Так и с облаками - нету за этим ничего нового, если с Z смотреть, а остальные пусть восхищаются.

а кто обещал выплеск про SOA на мейнфреймах? воооот... ждемс.

>> да не надо там никаких облаков.
Вот тут никак не могу согласиться. Проблема в том, что у меня есть сервер(на винде например), ему надо 1Гц и 5 гиг на диске. Покупать слабый комп глупо, вдруг база до 6 Гиг вырастит. Покупать навороченный комп дорого и не рационально. Облако позволяет мне купить силу, а не железо. У своего IT или у другой конторы не важно. В этом идея облака и его красота. Я плачу за маленький комп, и ничего не теряю, если завтра мне понадобиться лишний Гц. Далее следствие, чтобы отделить систему от железа, запускать несколько систем на одном железе нужна виртуализация и тд. И по мере роста IT само доставляет винты и процессоры.

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

я же выше писал, как это сделано, и сделано не у мифической фирмы - так работает разработка и тестирование в лабах IBM, а это worldwide.
И так может сделать каждый - там примитивно всё устроено, я специально вчера спросил.
Если это не сделал никто из партнёров до сих пор - это не имеет спроса.
Иначе бы уже и CA, и BMC уже давно сделали.
Будет спрос - сделают, или IBM соё продавать начнёт.
VM тоже была внутренняя разработка, только для своих инженеров, пока просто клиенты не стали требовать - продай!

По поводу старого компаи купить "силу" у друга.
Да без проблем!
Но технически всё в разы проще, и дешевле, если купить ту жде силу с Z.
А не с тысячи интеловых боксов.
Разница в стоимости обслуживания тысячи боксов, по сравнению с одним.
Именно в обслуживании.
Но вопрос покупки "силы" - нифига не коммерция.
Игрушки.
Типа google docs или почты.
Хотя имеет место быть.
Но всё равно - продажа вычислительной мощности на Z будет более прибыльной, в связи с более низкими затратами.

Как минимум в 4x IBM центрах worldwide я такого не видел.
1. Фрейм не годится для скоростных вычислений, хоть тресни. Его удел много паралельных транзакций.
2. Сила Z не умеет запускать уже существующие вин сервера. Вполне серьезные.
3. Сопостовимые решения стоят намного дороже. Если я хочу просто пописать/подебажить проги на Си, я и за 100 лет не отобью разницу на обслуживании.
4. Фрейм не дружелюбен в принципе. Интерфейсы и действия.

Так что облака будут развиваться и очень бурно. А наша задача не кричать "Это давно известно и нам не надо", а правильно вписать фрейм в облачную инфраструктуру. Не сам по себе, а как необходимая часть современного центра. Не даром же в последний фрейм обычные блейды вставляются. "Ибо довески они неразумные и нет бога кроме мейнфрейма. IPL. "

Э, ну кто же виноват, что не видели.
Не повезло.
Я не выходя из Москвы - увидел.
1. Почти так - с появлением z196 наметилась новая тенденция. Уже появилась принципиальная возможность выполнять скоростные вычисления на процессорах P не выходя из бокса Z - экономия на администрировании.
2. Не технологическое, но политическое решение. Ибо нефиг.
3. Если весь Z для того, чтобы скомпилячить и один раз прогнать проггу на C - точно, это нафиг не надо. Но вы ведь об облаке? А он не предназначено обслуживать одного пользователя. Но миллионы. И тогда Z - выгоднее. За счёт разницы в затратах на обслуживание. И вот тогда альтернатива - или я покупаю для одноразовой С программы маленький бокс, или мощности на Z - склоняют выбор в сторону Z
4. Это о чём было? не дружелюбно - что? Какой интерфейс? Rational Developer for Z? При чём тут Z? Что мешает по образу и подобию RDz делать? Не нравится 3270 - есть варианты. Хотя ещё много лет 3270 будет удобнее разным сонмам операторов. Это простые исследования юзабилити операторской работы - действия при мыши всегда будут прогирывать горячим клавишам.

Кроме криков кормящихся с этого маркетологов ни малейшего признака о светлом будущем в виде неба в алмазах. Я о перспективе облаков.
Остаётся подождать, и проверить.

Блейды вставляются немного не для того. Они вставляются как раз для того, чтобы в перспективе Z был не частью датацентра, а единственным, что в нём находится.
z196 позиционируется не совсем под условия РФ.
Он позиционируется под тех, у кого уже 40 лет бизнес на Z, и со временем, как вы справедливо указываете, появилось куча разных систем на писюках. И теперь под постулатом "Ну если у вас уже и так почти всё на Z" даётся возможность и тот жалкий остаток, что не на Z, занести внутрь. С единственной целью - сокращать затраты на административное обслуживание.
Которые уже несколько лет опережают в росте всё остальное.

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

роняя скупую слезу, вспоминая свою родную, вылизанную, обласканную SUN Enterprize 2... До сих пор ведь не продал... А просили, не раз... Ностальжи...

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

в корпусе Z10 можно поселить много китайцев, или японцев - это же небольшая комната

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

Ещё по поводу убогого интерфейса.
ISPF я так понимаю, убогий интерфейс.
Был тут специалист из лабы IMS.
Его спрашивают
- а современный GUI для администрирования есть?
Он смеётся, потом отвечает
- есть, но он вам не нужен!
- То есть как это?
- Мы его уже давно то разрабатываем, то забрасываем. Его никто не покупает, он не нужен
- Но почему?
- Потому, что когда администрируется система IMS, выполняющая важные задачи, а других на IMS нет, то администраторы не желают иметь никакого промежуточногго звена между собой и системой, а все свои задачи гораздо быстрей можно выполнить непосредственно подавая команды системе и используя ISPF.

Кстати, ни CA, ни BMC, никто другой тоже не предлагает GUI для IMS.
Случайных людей возле такой системы нету, это не RDBMS, возле которых ныне множество неучей ошивается.

Гриша, снобизм есть зло. А мейнфрейм (и системное администрирование на нем) действительно имеет недружественный интерфейс. Однако для больших железяк это не самое страшное, действительно. Там другие критерии.

Не соглашусь.
Более близкий пример к нашим реалиям.
Вот на встрече будет человек очень опытный в администрации DB2/Z - я надеюсь, будет.
Ему долго рассказывали и показывали про средства администрирования Db2/Z с гуями.
Его заключение - всё то же самое я сделаю быстрее с ISPF.
И я видел - действительное делает.
Уже много лет.
Он сноб?
Вот познакомишся - сам спросишь.

нет, он не сноб. я тоже управляю RACF даже не из ISPF, а командами и скриптами.
а вот заява типа -
Случайных людей возле такой системы нету, это не RDBMS, возле которых ныне множество неучей ошивается.
попахивает слегка снобизмом. Ибо случайные люди везде ошиваются, была бы мода. Когда IMS был "в струе", уверен, тоже всякие ошивались. И вокруг ADABAS, который не RDBMS, тоже всяких болтунов навалом.

Ключевое слово - ошивались, в прошедшем времени.
Мода - это точно зло.
Мода на SOA, мода на облака...
А когда проходит волна, начинается работа, и лишних просто нет
Но по ряду причин, выполнить select * from table во много раз проще, чем
написать что-то типа
L GU
L 9999 GN
только потому, что в последнем случае это должно быть в JCL, с проставленными всякими параметрами, типа PSB, о существованиии которых не все догадываются.
И это правильно!

IMHO хорошо иметь и GUI и full screen text-mode и line-mode интерфейсы
в z/OS традиционно имеет место перекос в сторону text-mode/line mode интерфейса, в Windows - в сторону GUI. А нужно как одно, так и другое

"Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича..." (с) Гоголь.
Оно да, было бы хорошо. Только так обычно не бывает.

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

ну зачем так уж пессимистично... у CICS есть вполне приемлемый web-based GUI, у DB2 UDB GUI + CLP... у Windows наряду с GUI - WMI и прочее так что не так уж все и плохо.

я уже рассказывал про IMS GUI - никто не покупает.
никому он не нужен.
DB2/Z GUI? Обычно Control Center, но уж лучше без него, чем с ним. В ISPF панелях DB2 Administration Tools со товарищи есть практически всё, что надо.
Вопрос не в отсутсвии этих GUI инструментов - вопрос в игнорировании их теми, для кого они предназначены.
Иначе бы уже столько GUI тулзов наклепали.
Ведь z/OS привела к появлению цельного рынка утилит, много компаний кормятся с него.

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

О, именно, не навязываться....
IBM даже планировщик джобов не навязывает...
API есть.
А планировщика - практически нету.
Зато на выбор от третьих фирм.
Ну или Tivoli.
Так и с гуями.
API всё есть.
Была бы потребность - были бы инструменты.
Помоему, IBM как раз в этой ситуации ничего не навязывает.
Более того, ISPF интерфейс по управлению DB2/Z не входит в поставку DB2/Z - не хочешь, не покупай, это не влияет на работоспособность продукта.
Кстати, часто готовая система, использующая DB2, имеет встроенные средства администрирования от поставщика системы. Что не отменяет необходимости иметь DBA. Тем не менее - интерфейс не навязывается.
И отсутсвие новомодных интерфейсов я лично склонен оценивать только отсутсвием спроса.
Поищите, к примеру, анализатор логов, или другие утилиты для DB2/Z - их есть, как минимум от CA и BMC.
Если бы нужны были гуи - их бы сделали.
Всё нужное для этого есть в системе, что zOS, что DB2/Z, что IMS.
Нету как раз спроса.
А удобный анализатор журналов транзакций жизненно необходим каждому администратору, и не обязательно ему быть гуёвым.
так же с кучей других утилит.

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

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

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

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

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

ну и зачем вот ты это сейчас написал?
при чём тут попил?
"освоение бюджета" не имеет ничего общего с криминалом, но с глупым устройством системы.
А попил - имеет отношение прежде всего к нарушению уголовного законодательства.

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

Просто так ERP бизнес не украшают, это вряд ли, что-то меня сомнения берут.
А вот повысить капитализацию методом внедрения продуктов от громко звучащих помпаний - это да, сплошь и рядом.
Если бы при внедрении ERP не нужны были технари - их бы и не привлекали. Их и так очень часто стараются не привлекать. Пытаются консалтерами обойтись.
Объявления на рынке
- компания X внедряет ERP от компании Y на платформе компании Z!
Уууу, как стоимость акций взлетела!
Через время
- для завершения внедрения нанята консалтинговая компания W!
Уууу, опять!
Ведь рынку пофиг, лишь бы громкие новости...

Гриша, попил бывает и вполне законным действием...
но я понял исходный посыл. наши с тобой различия во взглядах обусловлены разными "точками сидения". Это Кучма сказал, когда Лебедя Ельцин пригласил после первого тура голосования возглавить Совет безопасности. Тогда Кучма сказал:"Точка сидения определяет точку зрения. Это пока Лебедь был оппозиционным кандидатом, он критиковал и давал советы. А теперь он будет занят тем, где взять бензин для армии и зимние портянки." Так вот - я-то сижу на том стуле, где с ИТ говорят до появления жопы, но зато те, кому ИТ ну вообще пофиг. Поэтому ты несколько резковато смотришь на дело, как человек из недр вендора. А я - просто тот, которого допускают к вендору, когда уже достигнуты принципиальные соглашения, или сильно до того.
Вот и идет разница во взглядах на централизацию, консолидацию и то, надо ли все это делать.
А попил ты не обижай. Это дело криминальным стает только в руках криминала, а в руках обычных людей это просто распределение бюджетных средств))

кстати, возвращаясь к облакам - Tivoli Service Automation Manager. Полное кроссплатформенное управления средствами виртуализации.
По-другому - средство построения облака.
Мышкой.
Только что вот мне специалист по Tivoli рассказал.
Его бы сюда - он бы...
Я ему сейчас кратко вопрос сформулирую, чтобы он нам пояснил

Всем здравствуйте, я новенький, поэтому не пинайте меня особо сильно
Совершенно случайно наткнулся на статью http://www.livebusiness.ru/news/8590/ и заинтересовался этим решением. Насколько я понимаю, это очередная webOS, серверная часть которой работает на web-сервере. Ничего особенного, но заинтриговало вот это:

Сколько-нибудь внятного и полного материала на сайте ibm найти не удалось, но упоминания есть.
Соответственно, попадалось ли это уже кому-нибудь вживую и кажется ли Вам это решение интересным для организации облака уровня предприятия? (В техническом смысле, не на продажу)
P.S. Про управление ресурсами я догадываюсь
Качаю и ставлю, хоть посмотрю что это

Так это же линуксовая нашлепка. Ее гордо называют "прикладная система". А так - периодически всплывает инфа, один из сотен проектов IBM.
Закачаете, попробуете, расскажите, а?

Закачал, попробовал, рассказываю. Система очень понравилсь, менеджер рабочего стола похож на Gnome. Все работает, FTP-клиенты всякие, офисные побрякушки и даже браузер есть , в котором можно подсоединиться к этой же системе, в которой можно... Есть передача файлов туда-сюда. Пробросил порты и разрешил регистрировать учетные записи, 213.141.131.58, кому интересно-смотрите. Лучше через chrome, через интернет может подтормаживать, в локалке все отлично. С новыми версиями идет OpenOffice

Посмотрел, зашел Chrome, сыграл в шахматы. А на каком железе все это счастье?

P4 3GHz, 1Gb, ubuntu server 10.04. (apache, PHP) На этом железе еще и геркулес крутится. Версия eyeOS довольно старая, 1.8хх, сейчас уже 2.2 stable есть, тоже чуть позже разверну.