Что ждет средства виртуализации через 10 лет?

Для начала хочется определить понятие «средства виртуализации». Виртуализация по сути представляет собой абстрагирование от аппаратных средств, от их микроархитектуры. Поэтому говоря о средствах виртуализации, следует понимать, что это далеко не только серверная виртуализация и виртуальные машины VMware. Программно-определяемые СХД, контейнерные технологии, удаленные рабочие столы и потоковая доставка приложений – это тоже виртуализация.

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

Все более набирает обороты концепция Software Defined Everything, программно-определяемое все или, по сути, виртуализованное все. Большинство корпоративных СХД уже практически ничем не отличаются от серверов, кроме форм-фактора исполнения. Производители уже отказались от специальных процессоров, все крутится на x86. Все больше производителей отказываются от сопроцесоров и специализированных ASIC'ов, перекладывая задачи на могучие Intel Xeon последних поколений. Современная СХД корпоративного класса уже по сути является стандартным сервером со стандартным оборудованием, просто с большим количеством жестких дисков. Вся логика в программном обеспечении. Граница между серверами и СХД размывается еще сильнее при помощи умных драйверов, управляющих содержимым кэш-памяти, и флэш-кэшами, устанавливаемыми в серверы. Где кончается сервер-потребитель и начинается СХД?

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

Идет постепенное принятие всей индустрией ИТ давно известной среди хостинг-провайдеров технологии контейнерной виртуализации. В дальнейшем мы будем наблюдать слияние в единой системе и платформе как полной виртуализации, так и контейнерной. Новые и модные контейнеры Docker и сопутствующие им не готовы для работы в корпоративном секторе – недостаточно проработаны вопросы обеспечения качества обслуживания, информационной безопасности, но нет никаких сомнений в их готовности через 10 лет.
Уровень управления сетью все больше перемещается в программный, размывается сетевой уровень доступа – ну а что ему еще делать при коммутации внутри гипервизора под сотню ВМ? Единственным прибежищем аппаратных специализированных архитектур будут оставаться высокоскоростные терабитные коммутаторы уровня ядра сети или специализированные коммутаторы со сверхнизкими задержками, как например Infiniband. Но и у тех останется уровень данных и сверхскоростные матрицы коммутации, в то время как уровень управления будет жить в облаке.

Все идет к смерти ОС общего назначения, как мы их знаем. Ведь по сути нам не нужна ОС, нам нужны лишь приложения, а они все больше и больше виртуализуются и упаковываются в контейнеры. Вместо ОС нас ждет гипервизор нового поколения. Что в конечном итоге выльется в полное размытие понятия «персональный компьютер» - это будет и планшет, и десктоп, и даже смартфон. Сегодня мы все еще устанавливаем приложение и привязываем его к ОС, хотя данные все чаще храним в облаке. Но через 10 лет можно быть уверенным, что контейнер с приложением будет просто мигрировать между этими устройствами так же легко, как сейчас между серверами переезжает виртуальная машина.

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

Дизайн VDC. Расчет системы хранения

Расчет классической СХД по производительности

Классическая СХД всегда рассчитывается по худшему варианту (worst case scenario), исключая влияние оперативного кэша и оптимизации операций.
В качестве базовых показателей производительности принимаем механическую производительность с диска (IOPSdisk):
- 7.2k – 75 IOPS
- 10k – 125 IOPS
- 15k – 175 IOPS

Далее количество дисков в дисковом пуле рассчитывается по следующей формуле: = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. Где:
- TotalIOPS – суммарная требуемая производительность в IOPS с дискового пула
- RW – процентная доля операций чтения
- RAIDpen – RAID penalty для выбранного уровня RAID

Подробнее об устройстве RAID и RAID Penalty рассказывается здесь - Производительность СХД. Часть первая. и Производительность СХД. Часть вторая. и Производительность СХД. Часть третья

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

Особенности расчета систем с Flash Cache

Flash Cache – общее название для всех фирменных технологий использования флэш-памяти в качестве кэша второго уровня. При использовании флэш кэша СХД как правило рассчитывается для обеспечения с магнитных дисков установившейся нагрузки, в то время как пиковую обслуживает кэш.
При этом необходимо понимать профиль нагрузки и степень локализации обращений к блокам томов хранения. Флэш кэш – технология для нагрузок с высокой локализацией запросов, и практически неприменима для равномерно нагруженных томов (как например для систем аналитики).

Расчет гибридных систем low-end / mid-range

Гибридные системы нижнего и среднего классов используют многоуровневое хранение с перемещением данных между уровнями по расписанию. При этом размер блока многоуровневого хранения у лучших моделей составляет 256 МБ. Данные особенности не позволяют считать технологию многоуровневого хранения технологией повышения производительности, как ошибочно считается многими. Многоуровневое хранение в системах нижнего и среднего классов – это технология оптимизации стоимости хранения для систем с выраженной неравномерностью нагрузки.

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

Использование SSD в многоуровневом дисковом пуле

Использование SSD в многоуровневом дисковом пуле имеет вариации, в зависимости от особенностей реализации алгоритмов флэш кэша у данного производителя.
Общая практика политики хранения для дискового пула с SSD уровнем - SSD first.
Read Only Flash Cache. Для флэш кэша только на чтение уровень хранения на SSD появляется при значительной локализации операций записи вне зависимости от кэша.
Read / Write Flash Cache. В случае с флэш кэшем на запись сначала устанавливается максимальный объем кэша, а уровень хранения на SSD появляется лишь при недостаточности размера кэша для обслуживания всей локализованной нагрузки.
Расчет производительности SSD и кэша производится каждый раз исходя из рекомендаций производителя, но всегда для наихудшего варианта.

Дизайн VDC. Расчет ресурсов и выбор архитектуры

Разделение на пулы ресурсов

После сбора всей первичной вводной информации первым шагом является группировка наборов данных и ИС в пулы, исходя из моделей угроз и требований регуляторов. Определяется вид разделения различных пулов – программно на уровне системного ПО или физически.
Примеры:
- Контур, обрабатывающий персональные данные, полностью физически отделен от остальных систем;
- Резервные копии хранятся на отдельной СХД.

При этом пулы могут быть с неполной независимостью, например, определяется два пула вычислительных ресурсов (процессорная мощность + оперативная память), которые используют единый пул хранения данных и единый пул ресурсов передачи данных.

Процессорная мощность

Абстрактные потребности в процессорной мощность виртуализованного ЦОД измеряется в количестве виртуальных процессоров (vCPU) и коэффициенте их консолидации на физических процессорах (pCPU). В данном конкретном случае 1 pCPU = 1 физическое ядро процессора (без учета Hyper-Threading). Количество vCPU суммируется по всем определенным пулам ресурсов (каждый из которых может иметь свой коэффициент консолидации).
Коэффициент консолидации для нагруженных систем получают эмпирическим путем, исходя из уже существующей инфраструктуры, либо при пилотной установке и нагрузочном тестировании. Для ненагруженных систем применяются «best practice». В частности, VMware называет средним коэффициентом 8:1.

Оперативная память

Общая потребность в оперативной памяти получается путем простого суммирования. Использование переподписки по оперативной памяти не рекомендуется.

Ресурсы хранения

Требования по ресурсам хранения получаются путем простого суммирования всех пулов по объему и производительности.
Требования по производительности выражаются в IOPS в сочетании со средним соотношением чтение/запись и при необходимости максимальной задержкой отклика.
Отдельно должны быть указаны требования по обеспечению качества обслуживания (QoS) для конкретных пулов или систем.

Ресурсы сети передачи данных

Требования по сети передачи данных получаются путем простого суммирования всех пулов пропускной способности.
Отдельно должны быть указаны требования по обеспечению качества обслуживания (QoS) и задержек (RTT) для конкретных пулов или систем.
В рамках требований к ресурсам сети передачи данных так же указываются требования по изоляции и/или шифрованию сетевого трафика и предпочтительным механизмам (802.1q, IPSec и т.д.)

Выбор архитектуры

В рамках данного руководства не рассматривается иной выбор, кроме архитектуры x86 и 100% виртуализации серверов. Поэтому выбор архитектуры вычислительной подсистемы сводится к выбору платформы серверной виртуализации, форм-фактора серверов и общих требований по конфигурации серверов.

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

Классическая архитектура подразумевает использование интеллектуальных внешних подсистем хранения и передачи данных, в то время как серверы привносят в общий пул физических ресурсов только процессорную мощность и оперативную память. В предельном случае серверы становятся полностью анонимными, не имеющими не только собственных дисков, но даже системного идентификатора. В этом случае используется загрузка ОС или гипервизора с встроенных флэш носителей либо с внешней системы хранения данных (boot from SAN).
В рамках классической архитектуры выбор между лезвиями (blade) и стоечными (rack) осуществляется прежде всего из следующих принципов:
- Экономическая эффективность (в среднем стоечные серверы дешевле);
- Вычислительная плотность (у лезвий выше);
- Энергопотребление и тепловыделение (у лезвий выше удельное на юнит);
- Масштабируемость и управляемость (лезвия в целом требует меньше усилий при больших инсталляциях);
- Использование карт расширения (для лезвий очень ограниченный выбор).

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

Дизайн VDC. Конфигурация серверов и кластеров виртуализации

CPU / Memory

Для корректного расчета конфигурации нужно понимать тип нагрузки для среды или каждого из независимых кластеров.
CPU bound – среда, ограниченная по производительности процессорной мощностью. Добавление оперативной памяти ничего не изменит с точки зрения производительности (количества ВМ на сервер).
Memory bound – среда, ограниченная оперативной памятью. Большее количество оперативной памяти на сервере позволяет запустить большее количество ВМ на сервер.
GB / MHz (GB / pCPU) – среднее соотношение потребления данной конкретной нагрузкой оперативной памяти и процессорной мощности. Может использоваться для расчетов необходимого объема памяти при заданной производительности и наоборот.

Расчет конфигурации сервера

Для начала необходимо определить все виды нагрузки и принять решение о совмещении или разделении различных вычислительных пулов по различным кластерам.
Далее для каждого из определенных кластеров определяется соотношение GB / MHz при известной заранее нагрузке. Если нагрузка не известна заранее, но есть примерное понимание уровня загрузки процессорной мощности, можно использовать стандартные коэффициенты vCPU:pCPU для перевода требований пулов в физические.

Для каждого кластера сумму требований пулов vCPU делим на коэффициент:
vCPUсумм / vCPU:pCPU = pCPUсумм – требуемое количество физ. ядер
pCPUсумм / 1.25 = pCPUht – количество ядер с поправкой на Hyper-Threading
Предположим, что необходимо произвести расчет кластера на 190 ядер / 3.5ТБ ОЗУ. При этом принимаем целевую 50% загрузку процессорной мощности и 75% по оперативной памяти.

pCPU	190	CPU util	50%
Mem	3500	Mem util	75%
Socket	Core	Srv / CPU	Srv Mem	Srv / Mem
2	6	25,3	128	36,5
2	8	19,0	192	24,3
2	10	15,2	256	18,2
2	14	10,9	384	12,2
2	18	8,4	512	9,1

В данном случае всегда используем округление до ближайшего целого вверх (=ROUNDUP(A1;0)).
Из таблицы становится очевидно, что сбалансированными под целевые показатели являются несколько конфигураций серверов:
- 26 серверов 2*6c / 192 GB
- 19 серверов 2*10c / 256 GB
- 10 серверов 2*18c / 512 GB

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

Особенности выбора конфигурации сервера

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

Размер домена единичного отказа.

Выбор размера сервера также осуществляется из принципа минимизации домена единичного отказа. Например, при выборе между:
- 3 x 4*10c / 512 GB
- 6 x 2*10c / 256 GB
При прочих равных необходимо выбирать второй вариант, поскольку при выходе одного сервера из строя (или обслуживании) теряется не 33% ресурсов кластера, а 17%. Точно так же вдвое снижается количество ВМ и ИС, на которых отразилась авария.

Дизайн VDC. С чего надо начинать

Введение

Информационная система с точки зрения пользователя хорошо определяется в ГОСТ РВ 51987 - «автоматизированная система, результатом функционирования которой является представление выходной информации для последующего использования». Если рассматривать внутреннюю структуру, то по сути любая ИС является системой реализованных в коде взаимосвязанных алгоритмов. В широком понимании тезиса Тьюринга-Черча алгоритм (а сл-но ИС) осуществляет трансформацию множества входных данных в множество выходных данных.
Можно даже сказать, что в трансформации входных данных и есть смысл существования информационной системы. Соответственно ценность ИС и всего комплекса ИС определяется через ценность входных и выходных данных.
Исходя из этого проектирование должно начинаться и брать за основу данные, подстраивая архитектуру и методы под структуру и значимость данных.

Хранимые данные
Ключевым этапом подготовки к проектированию является получение характеристик всех наборов данных, планируемых к обработке и хранению. Эти характеристики включают в себя:
- Объем данных;
- Информация о жизненном цикле данных (прирост новых данных, срок жизни, обработка устаревших данных);
- Классификация данных с т.з. влияния на основной бизнес компании (то триаде конфиденциальность, целостность, доступность) вместе с финансовыми показателями (напр. стоимость утери данных за последний час);
- География обработки данных (физическое расположение систем обработки);
- Требования регуляторов по каждому классу данных (напр. ФЗ-152, PCI DSS).

Информационные системы

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

Модель угроз

В обязательном порядке должна быть в наличии формальная модель угроз, от которых планируется защищать данные / сервисы. При этом модель угроз включает в себя не только аспекты конфиденциальности, но и целостности и доступности. Т.е. например:
- Выход из строя физического сервера;
- Выход из строя коммутатора top-of-the-rack;
- Разрыв оптического канала связи между ЦОД;
- Выход из строя оперативной СХД целиком.
В некоторых случаях модели угроз пишутся не только для инфраструктурных компонентов, но и для конкретных ИС или их компонентов, как например отказ СУБД с логическим разрушением структуры данных.
Все решения в рамках проекта по защите против не описанной угрозы являются излишними.

Требования регуляторов

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

Целевые показатели RPO / RTO

Проектирование любого вида защиты требует наличия показателей целевой потери данных и целевого времени восстановления сервиса для каждой из описанных угроз.
При этом в идеале RPO и RTO должны иметь ассоциированные стоимости потери данных и простоя в единицу времени.

Дизайн VDC. Сайзинг хостов. 1

Hyper Threading

Часто встречаются два противоположных и неверных утверждения – HT не надо учитывать, и учитывать надо как полные ядра, т.е. умножать на два.
HT при сайзинге следует учитывать как +25% процессорной мощности. Хост с 2 процессорами по 12 ядер и HyperThreading имеет 24 ядра или 48 потоков, что с указанным коэффициентом дает мощность, эквивалентную 30 ядрам.
Следует отдельно отметить, что максимальный размер ВМ в этом случае должен быть не более 24 vCPU. Hyper-Threading дает максимальный эффект на большом количестве ВМ с малым количеством vCPU.

1 или 2 или 4

Выбор между 2х или 4х процессорными серверами под виртуализацию следует делать исходя из типа нагрузки, планируемой для данного конкретного кластера. Ключевой показатель – это размер домена отказа. Т.е. насколько виртуальная ферма и продуктивная нагрузка пострадает от отказа единичного сервера. Предположим, под 200 продуктивных ВМ нам требуется 10 2х-процессорных серверов с 256 ГБ памяти. Очевидно, что их можно заменить 5ю 4х-процессорными серверами с 512 ГБ памяти без потери производительности. Однако это означает удвоенное количество ВМ на сервер, и соотв. двойной объем памяти ВМ в нагрузке. При выходе одного хоста из строя и срабатывании HA мы имеем разницу в два раза по количеству ВМ и продуктивных сервисов в рестарте, увеличенную нагрузку на СХД при рестарте ВМ. А также выход двойного объема ресурсов из кластера – 20% (4х) против 10% (2х). При запланированном простое хоста (под регламентные работы) двойное количество ВМ требуют миграции, что в 2-2.5 раза увеличивает время самой миграции.

С учетом роста количества ядер в процессорах для 2х процессорных серверов, возникает смысл в переходе даже на 1-процессорные серверы.

Итого. 4х процессорные серверы под виртуализацию рекомендуются в следующих случаях:
- необходимость использования иного семейства процессоров (Xeon E7, а не E5) под продуктивную нагрузку. В этом случае 4х процессорный сервер может быть с 2мя установленными процессорами.
- необходимость в размещении сверхшироких ВМ, шириной в полный двухпроцессорный физический сервер или более, при невозможности или экономической неэффективности кластеризации приложения с разделением нагрузки на ВМ меньшей ширины.

Выбор процессора

Выбор процессора внутри семейства затрагивает сразу несколько параметров, которые необходимо рассмотреть.
- NUMA. Все современные x86 процессоры имеют архитектуру NUMA. Т.е. у каждого процессора в сервере есть своя память, и обращение к чужой памяти напрямую невозможно. Иными словами, если в 2х процессорном сервере установлен 1 процессор, то памяти можно установить только половину от максимально возможной.
- Стоимость самого процессора и стоимость в расчете на ядро.
- Стоимость лицензий на системное и прикладное ПО и модель лицензирования.

Предположим, что в качестве платформы выбран сервер Intel R1304WT2GS, и теперь стоит вопрос сколько и каких процессоров в него установить для максимальной экономической эффективности. В качестве ПО предполагается vSphere Standard ($1940), Windows 2012 R2 Datacenter ($6155 / 2 CPU), Veeam Backup Standard ($1116).
Итак, для конфигурации 1xE5-2670v3 (12c) и 192 GB сервер будет стоить в сборе $7970 и потребует по 1 лицензии ПО (лицензирование по сокетам), что дает $6133 за софт или $14100 за сервер.
При выборе варианта с 2мя процессорами E5-2620v3 (6с) стоимость самого сервера уменьшается до $6890, однако стоимость лицензий удваивается и дает $19160. /* расчет не является 100% корректным и призван лишь проиллюстрировать сам принцип
При равной мощности и объеме памяти двухпроцессорный сервер обладает большей ценой (спасибо лицензиям) и потенциально меньшей производительностью за счет 2х узлов NUMA.

Так зачем же нам нужны двухпроцессорные и, тем более, четырехпроцессорные серверы?
- В двухпроцессорном сервере вдвое больше максимальный объем памяти.
- Одного, даже топового, процессора может не хватать по вычислительной мощности.
- Многоядерные процессоры не всегда имеют высокую тактовую частоту, а стоимость лицензий на системное ПО значительно ниже стоимости прикладного ПО, лицензируемого по ядрам. Например 2*E5-2637 v3 (4с, 3.50 GHz) и 1*E5-2667 v3 (8с, 3.20 GHz) имеют 10% разницу в пиковой производительности (28GHz vs 25,6GHz), что может стать решающим фактором для выбора процессоров для нагруженной Oracle DB.

Общие рекомендации:
- Многоядерные процессоры хорошо подходят для большого количества ВМ малой или средней загрузки.
- Чем более широкие ВМ используются – тем лучше они работают на многоядерных процессорах.
- Если машин немного и прикладное ПО плохо работает с параллельными потоками, предпочитая частоту, то выбор должен осуществляться в пользу процессоров с большей частотой в ущерб количеству ядер.
- Надо всегда начинать с варианта с одним процессором, и добавлять второй только при нехватке памяти, или оставлять второй процессор как опцию под будущий апгрейд виртуальной фермы.

Какой же язык программирования самый облачный?

Данный пост навеян обсуждением в Фейсбуке, начавшимся с "на JS и PHP написаны все говнооблака спорить не буду. А что потом? Так вот, за F# будущее".
В процессе обсуждения была высказана интересная мысль, даже смелая: "Облако - это новая вычислительная среда. Она устроена действительно по-иному нежели привычные нам персоналки".
И вот в чем вся соль: оба этих утверждения неверны.

Облако - это прежде всего самообслуживание и биллинг, это непременные атрибуты XaaS. Внизу облачный сервис состоит из множества маленьких сервисов, подсервисов и подсистем, каждая из которых может быть написана на любом языке или даже смеси языков. На некоторых языках программирования удобнее писать определенный вид сервисов. И то, если у вас есть команда разработчиков, хорошо владеющих данным языком и всей обвязкой к нему в виде библиотек и импортируемых модулей.
Я лично назвал бы только два с половиной языка, на которых можно написать полный стек облачного сервиса - это C, C++ и Java. Во всех остальных случаях придется использовать несколько языков. Но удивительное дело, ни один из них не нов и ни разу не облачен.

Вернемся ко второму утверждению о принципиально новом устройстве облачной среды с точки зрения программирования.
Как только мы отбрасываем биллинг и самообслуживание в PaaS, то оказываемся в совершенно традиционной среде, существовавшей задолго до облаков, хотя может быть и не столько популярной. И называется она Grid. Ничего нового облака нам снова не принесли, кроме значительной популяризации архитектуры грида. Возьми любое популярное PaaS облако, как например AWS или Azure - это не более чем набор очень больших гридов на каждый сервис и API к ним. API, кстати, тоже совсем не облачное изобретение.
Впрочем, есть пожалуй одна из архитектурных концепций, зародившихся примерно одновременно с облаками. Хотя я бы поставил ее как основу облаков, а не их следствие. Архитектура, построенная по принципу Design To Fail, или по-русски рассчитанная на отказ. Классическая привычная нам архитектура монолитных систем высокой доступности не может масштабироваться, и по сути ограничена сверху размером хоста. Для Scale-Out, неограниченно масштабируемой горизонтально системы, требуется не высокая доступность, а способность переживать отказ части узлов грида с минимальными последствиями для жизни всей системы.

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

Горизонтальное и вертикальное масштабирование. Взгляд со стороны бизнес приложений.

К концу 2012 года более 50% приложений работающих на х86 платформе виртуализированы. Вместе с тем виртуализировано только 20% бизнес критических приложений .

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

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

Тогда если доверие или стабильность не являются проблемой в чём же причина того что ИТ отделы еще не виртуализировали оставшиеся приложения?