mskmel wrote:Небольшой пролог, чтобы в топик попасть.
Совсем недавно внедряли новый проект на... коболе. С нуля писанный. Благо задачка была одноразовая, до этого уже решалась и на джаве и даже на php. Так вот, спецы что писали на коболе, написали так, что она работала часы, по сравнению с неделями на предыдущих языках. Я не виню языки, видимо тот самый программерский скиллсет повлиял.
Теперь в оффтопик, который тут уже топик. Про облака и прочие новомодности некрасивые.
Всем аксакалам известны ленточные библиотеки. Это такой редкостный геморрой, когда надо бэкапить сотни источников с разной производительностью, и как назло в одно окно бэкапа. То драйвы заняты, то ленточки пополомались. То очередной бэкап вместо с 1:00 до 5:00 вбежал во окно работы приложения. То очередной lazy backup отобрал 4 драйва и никому больше не даёт. К этому добавим загруженность драйвов на дублицрование лент, 5 (!) операторов 24х7 смотрящих за всем этим хозяйством и еще кучкой всего.
Но тут пришел, нелюбимый в этом топике, количественный прогресс - куча ядер и гигабайтов памяти, когда исконно железячные задачи решили софтом. Имён уже несколько, но скажем это EMC Avamar или подешевле HP StoreOnce (и то и другое пользовал). Чисто софтовые эмуляторы ленточных библиотек на обычных commodity x86, имеющие внутри нужное количество дисков, с default дедубликацией, репликацией и прочими вкусняшками. По началу счастью не было конца, операторы довольны что не надо бегать с картриджами (а вы когда нибудь своими руками грузили 1000+ новых картриджей в библиотеку?), админам нет нечитаемых лент, нет конкуренции за драйвы. Потом, первые, т.е. операторы, были просто разогнаны, ROI проекта 100% только на персонале. Админы по прежнему довольны, всегда есть свободные "драйвы", не надо вообще следить за тем что экспайрится на ленточках, ленточки то виртуальные... Решение из разряда поставил и забыл.
Вот это, количественные изменения, или качественные? Возможны ли они были бы на безумно дорогих не х86 железках?
Ето развитие технологии накопителей, в данном случаe backup типа...
К х86 железкам не имеет никакого отношения, по крайней мере удешевление етих самых накопителей и увеличение обьемов етих накопителей.
На безумно дорогих и старых технологиях накопутелей естественно было невозможно, но тогда ето было особо и не нужно, обьeмы данных было на много порядков ниже.
У нас кстати тоже и автоматическая EMC backup картриджная система(она кстати делает backup и всеx x86 серваков тоже, их у нас более десятка разных, две полноразмерные стойки/шкафа набиты ими и storage arrays к ним) и backup на дисковых накопителях, еще и дублирование в co-location всего етого хозяйства...
У нас например большой "front end" со своей DB сделан на множестве x86(Linix and Windows) в множестве VMs и сама billing(medical billing) часть сделанна на OpenVMS, которая тесно "обащается" с етим "front end" в том числе real-time. "Снаружи" видна только "морда"(front end), внутри самое главное на OpenVMS, никакого прямо доступа на OpenVMS нет(ето одно из условий нашего бизнеса, полная изоляция ядра). Когда я начинал работать в етой компании никакого front end не было, при мне все создавалось и я естественно принимал непосредственное участие на обоих фронтах и MF и на самом front end... В основном моя отвественность была в написании связывающих модулей межди етими двумя системами конечно, но не только и железе участвовал на фронт енд и железе на OpenVMS и network немного зацепил, все было...
Сейчас большую часть времени на Кобол, DCL и прочее на OpenVMS или модули связи между ними, но иногда и на x86 подключаюсь, иногда на VB и прочее.
Все, ладно хватит писанины, всем хороших выходных, я поехал домой...
)? Вот честно попытался и не смог. Это ж "Война и Мир" какая то 
"
