Первое и второе - это уже история. Последнее - тема для размышления. И что же на самом деле произойдет, мы увидим только в будущем.
Прежде чем пытаться понять судьбу мэйнфреймов, необходимо определить этот термин. Дословный перевод англоязычного термина mainframe почти однозначен - главная (основная) стойка. Что же касается существа дела, то здесь не все так просто. Просто было только в самом начале. Когда они были одни. Есть процессор и память - это мэйнфрейм. Нет - терминал или перфоратор. Потом появились мини. Стало уже сложнее. Занимает здоровый зал, составлен из нескольких шкафов, охлаждается воздухом или фреоном - мэйнфрейм; ничего этого нет, есть только процессор и память - мини, нет процессора и памяти - терминал или перфоратор. Дальше совсем плохо - мэйнфрейм, суперкомпьютер, минисуперкомпьютер, супермини, мини, персональный. Теперь к этому добавились серверы, Unix-серверы, суперсерверы, ПК-серверы, кластеры ... продолжать можно долго. При этом такие простые атрибуты как размеры, количество стоек, наличие охлаждения не позволяют произвести полную классификацию всех приведенных классов компьютеров. Чем отличается мэйнфрейм от суперкомпьютера? Почему же никто не пророчит исчезновения последним? Потому что всегда существуют задачи для решения которых нужны суперкомпьютеры. Почему это неверно по отношению к мэйнфреймам? Или верно?
Основным слабым местом архитектуры мэйнфреймов считается ее закрытость. Все свое: аппаратура, процессоры, память, шины, интерфейсы, память. Операционная система и приложения. Однако, постепенно все это становится более унифицированным. (Я имею в виду аппаратную составляющую архитектуры. О программной - чуть позже.). С другой стороны, производители серверов корпоративного класса все чаще применяют свои собственные разработки при проектировании своих систем. Появляются специализированные шины, интерфейсы, микропроцессоры становятся очень сложными и, зачастую, являются наборами схем. Так что в этом смысле мэйнфреймы сближаются с другими архитектурами. Надо заметить при этом, что закрытость и нестандартность архитектуры возникли не сами по себе. В значительной степени, это плата за необходимость обеспечения самых строгих требований по надежности и производительности этих систем.
Теперь о программной части архитектуры мэйнфреймов. На мой взгляд, очень просто сделать, чтобы они (мэйнфреймы) исчезли. Достаточно назвать их MVS-серверами. И все. Нет предмета для обсуждения. Обсуждать теперь можно лишь следующее: Unix-серверы вытеснят MVS-серверы или наоборот? Или они превратятся в одно и то же. Если же говорить серьезно, возникновение и воплощение в реальную практику концепции открытых систем оказало сильное влияние и на мэйнфреймы. Все производимые и разрабатываемые компьютеры этой категории стали гораздо более дружелюбными по отношению к окружающему вычислительному миру. Они легко могут работать в составе сетей (это относится как к оборудованию так и к программам). Приложения, работающие на мэйнфреймах, могут взаимодействовать с приложениями, функционирующими на других установках. Поэтому и здесь все у мэйнфреймов становится лучше.
Еще одним признанным недостатком мэйнфреймов, вытекающим из закрытости архитектуры, является их относительная дороговизна. С одной стороны, это обусловлено все теми же требованиями по обеспечению надежности и производительности, с другой - слишком малым числом установок и большими накладными расходами на разработку нестандартной архитектуры. Конечно, дорого - это плохо. Однако, иногда возникают ситуации, когда лучше заплатить дорого, чтобы минимизировать стоимость эксплуатации системы за все ее время жизни. Эти ситуации свойственны крупным проектам, и каждый раз разработчики должны четко представлять себе все достоинства и недостатки применения мэйнфреймов в своих системах.
Сейчас очень много внимания уделяется многозвенной технологии построения информационных систем. Одно из ключевых понятий - сервер приложений. Сервер приложений может располагаться на различных аппаратных платформах. В том числе и на мэйнфреймах. Нет ничего противоречащего такому расположению. Более того, поскольку в крупных корпоративных приложениях, использующихся тысячами пользователей, к надежности сервера приложений (как и сервера баз данных) почти всегда предъявляются очень жесткие требования. Слишком велика может быть цена выхода из строя или даже кратковременной остановки таких систем. А надежность всегда была одной из самых сильных сторон мэйнфреймов, и, может быть, другие архитектуры не скоро сравняются с ними в этом отношении.
Как скажется на судьбе мэйнфреймов бурное развитие Internet? В последнее время много говорят о сетевых компьютерах. Много спорят - "толстый" клиент или "тонкий"? Чем "тоньше" клиент, тем "толще" сервер. Возможно, сетевой компьютер окажется настолько "тощим" клиентом, что сервер на другом конце сети должен будет оказаться мэйнфреймом. А с ростом Internet клиентов станет настолько много, что количество мэйнфреймов тоже будет увеличиваться.
И последнее. По всей видимости, самый серьезный аргумент в пользу выживаемости мэйнфреймов - огромное количество работающих на них приложений и накопленных оперативных данных. Замена использующихся сейчас в наиболее критичных по надежности и производительности системах приложений - задача невероятно трудная. Уж если сейчас столько внимания уделяется одной маленькой (относительно конечно) частной проблеме, состоящей в обеспечении применимости этих приложений после двухтысячного года, то что же можно сказать о задаче в целом? С данными еще сложнее. Несмотря на относительную дороговизну систем, построенных на мэйнфреймах, не исключено, что дешевле будет производить новые модели таких компьютеров и подключать дополнительные устройства хранения информации к уже существующим устройствам, чем пытаться заменить систему в целом. Впрочем, если осуществлять полную замену работающих систем (и оборудования и приложений), двухтысячный год - хороший повод (но не причина) для этого.
P. S. Перечитав все изложенное выше, я так и не понял, какой точки зрения сам придерживаюсь по поводу жизни или смерти мэйнфреймов. Не знаю. Время покажет.
Андрей Волков - главный редактор журнала "Системы Управления Базами Данных". С ним можно связаться по электронной почте: volkov@osp.ru.