В истории ИТ было много значительных событий, но одно из них оказалось исключительно важным. Речь идет о выпуске микропроцессора Intel 8086 —
В современных условиях, когда заметные сдвиги в технологиях происходят каждые
Важную роль в популяризации x86 в конце
В конце концов IBM остановилась на 8088, поскольку его
По мере модернизации технологических процессов Intel выпускала все новые и новые поколения чипов: 286, 386 (первая
IaaS и PaaS: сложность выбора
Этот перечень был бы не полным без учета смартфонов, Open Source, новых методологий разработки ПО и нескольких поколений языков программирования. В той или иной степени x86 присутствует везде, но есть сегмент, где эта архитектура обладает абсолютной монополией — облачные службы. Как типичные пользователи, так и предприятия постепенно переносят свои данные и приложения в публичные или частные облака. Для этих целей используется преимущественно сервис IaaS, впрочем миграция зависит от конкретных задач. В зависимости от ситуации предприятие может перенести локальную инфраструктуру в облако либо полностью, либо использовать для её работы гибридную облачную среду. Последнее имеет смысл, поскольку не требует переделки унаследованных приложений или написания новых, но уже для облака.
И здесь среди преимуществ IaaS можно отметить то, что она предоставляет возможность гибкой виртуализации рабочих окружений начиная от образов операционных систем и заканчивая сетями, СХД и приложениями, которые в сущности являются аналогами рабочих сред, развернутых в локальных ЦОДах. Конечно, для их выверенной работы потребуется некоторая подстройка параметров безопасности и авторизации. Управившись с этим, предприятие в итоге может рассчитывать на автоматизацию процессов. В среде IaaS их работа в виде виртуализированной инфраструктуры будет мало чем отличаться от работы в локальном окружении.
Но у IaaS есть и минусы. Как пишет Перлоу, одним из них является малоэффективная работа облачных окружений — без оптимизации и балансировки запущенные в среде IaaS приложения потребляют много вычислительных ресурсов, что выливается для конечных пользователей в ощутимый перерасход средств. Ситуация усложняется ещё и тем, что работать в этой среде могут далеко не все программы, к тому же облачные вендоры взимают плату за каждую отдельно запущенную виртуальную машину (ВМ) вне зависимости от загрузки процессора. И если расценки за пользование хранилищами в базовых пакетах ещё можно признать относительно недорогими (они рассчитываются исходя из необходимого клиенту объёма ОЗУ), то стоимость премиальных пакетов, предлагающих более высокую производительность для хостинга ВМ, берётся из расчёта за потребляемый объём SSD-хранилища. Такой способ тарификации предлагается, к примеру, сервисом Microsoft Azure.
Но у IaaS имеется альтернатива — PaaS. В противовес IaaS хостинг рабочих нагрузок по этой модели менее затратный, к тому же взамен создания статичных ВМ провайдеры предлагают более тонкие инструменты подстройки — доступ к API. Ещё одна сильная сторона PaaS — в расчёт берётся не количество ВМ или объём ОЗУ, а количество запрошенных транзакций (сессий). Но у этой модели есть и слабая сторона: PaaS не позволяет перенести в облако традиционные корпоративные приложения и их потребуется переписывать (специалисты называют такой подход «рожденный в облаке») с нуля. Чтобы облегчить предприятиям миграцию, некоторые SaaS-провайдеры и облачные вендоры начали сдавать готовые PaaS-платформы «под ключ».
По мнению Перлоу, популярность x86 архитектуры напрямую зависит от того, насколько длительным окажется существование IaaS, но с учётом консервативности корпоративной среды, рабочие нагрузки которой обрабатываются Intel-процессорами, говорить о скорой смене архитектуры пока преждевременно.
Контейнеризация инфраструктуры
Тем не менее, в последние годы рынок облаков приобретает новые очертания. Эти изменения связаны с появлением контейнеров — промежуточной технологии, которая связывает IaaS/виртуализацию и PaaS, где контейнеры выступают в качестве строительных блоков для создания PaaS-софта.
Нужно отметить, что контейнеры гораздо эффективнее ВМ, поскольку с их помощью можно более экономно потреблять ресурсы облачных серверов: они позволяют запускать сразу несколько экземпляров приложений, используя однотипные ресурсы и настройки безопасности внутри одного ядра. При этом каждое приложение внутри контейнера «считает», что оно единственное, и работает в полнoценной ОС без каких-либо ограничений. Если необходимо изменить существующий файл или создать новый, контейнер получает копии с основной ОС хоста, сохраняя только изменённые участки.
Другим немаловажным преимуществом контейнеров является то, что запакованные в них приложения могут храниться в виде архивов. Подобная технология применяется для сжатия файлов в форматы .zip или .jar. Отличие контейнeров от виртуальных машин заключается в том, что контейнеры не загружают собствeнные копии ОС, библиотеки, системные файлы и прочее. В результате контейнер стартует в считанные секунды и меньше нагружает систему, чем в случае применения ВМ. Распределенный запуск контейнеров позволяет создать в облаке многоарендную архитектуру (multi-tenancy) из изолированных контейнеров под разными учетными записями без создания отдельных ВМ.
Из минусов контейнеров можно назвать их зависимость от ядра ОС. То есть, если упакованные в контейнеры приложения написаны для Linux, то в другой ОС они работать не будут. Кроме того, несмотря на то, что контейнеры приложений гарантируют высокую скорость работы и утилизацию ресурсов, им не хватает той безопасности, которую обеспечивают ВМ. Проблема заключается в том, что пока что Docker является очень молодым решением и не все «детские проблемы» решены. При запуске на одной машине множества Docker-сред злоумышленник может получить доступ к ресурсам одного пользователя через взлом другого, поэтому работа контейнеров внутри ВМ обеспечивает дополнительный слой безопасности. Для запуска Docker в виртуальной среде часто применяется Open Source-решение QEMU/KVM. О популярности контейнеров говорит тот факт, что сервисы контейнеризации в виде ВМ, которые обеспечены соответствующими службами и движками оркестровки предлагают облачные сервисы Google Compute, Microsoft Azure и Amazon Web Services.
Помимо программной виртуализации существует и аппаратная. В отличие от программной виртуализации, с помощью данной техники возможно использование изолированных гостевых систем, управляемых гипервизором напрямую. Гостевая система не зависит от архитектуры хостовой платформы и реализации платформы виртуализации. Что касается Docker, выгода от применения аппаратной виртуализации заключается в том, что для работы контейнеров не требуется запускать полноценный образ ОС — вся инфраструктура предоставляется облачным провайдером.
Как правило, это означает, что используя платформу PaaS — и особенно SaaS — конечный пользователь при наличии подписки получает полностью готовую рабочую среду с автоматически обновляемыми приложениями. Такой подход в корне отличается от среды IaaS — её работа требует вмешательства клиента начиная с выбора и поддержки ОС и заканчивая настройкой сетей и систем хранения данных. В итоге всё сведётся к тому, полагает Перлоу, что SaaS-поставщики или сами предприятия будут хранить код в облаке в виде упакованных в контейнеры приложений, которые будут масштабироваться при помощи движков оркестровки.
Docker и другие технологии контейнеризации уже многие годы поддерживаются и Unix, и Linux. Эти системы могут работать в режиме JeOS (Just enough OS) с настроенным ядром, которое содержит только базовые элементы, требуемые для виртуальных применений. Что касается Microsoft, то до недавнего времени она предлагала две технологии виртуализaции: ВМ и виртуальные приложения Server App-V.
В 2016 г. ассортимент контейнеров стал шире — в Windows Server 2016 появились Windows Server Containers. У этой серверной ОС, кстати, существует урезанная версия Nano Server — ОС, предназначенная для запуска созданных в облаке приложений и контейнеров. Как и у JeOS, у Nano отсутствует графический пользовательский интерфейса и, в отличие от Windows Server Core, нет ни командной строки, ни консоли PowerShell.
Популярность контейнеров — как она повлияет на x86?
Общеизвестно, что подавляющее большинство компаний выстраивают свою деятельность на базе унаследованного софта, который архитектурно зависит от набора инструкций x86, тогда как более современные приложения такой привязки не имеют — для их написания программисты используют высокоуровневые, абстрактные языки программирования, чьи API не зависят от процессорной архитектуры. Такими языками, к примеру, являются .NET, Java и множество скриптовых языков типа Ruby, Python и Javascript.
В свете того, что новые приложения становятся архитектурно независимыми, Перлоу предлагает поразмышлять о будущем архитектуры x86. Оценивая её шансы, он говорит, что пока что ей ничего не угрожает — большинство корпоративных приложений как работало на ней, так и продолжит, а вот шансы x86 обосноваться в гипермасштабируемых контейнерных средах с прицелом на облако не так очевидны. Более того, он считает, что смысл переносить неповоротливое x86-наследие в новую парадигму вычислений не имеет смысла, а ситуация в целом напоминает ему события девятилетней давности.
В то время появилась альтернатива x86, разработанная Intel и HP. Предполагалось, что IA-64 (Itanium) должна одинаково качественно работать начиная с потребительских ПК и заканчивая ЦОДами. На базе IA-64 выпускался самый быстрый процессор для вычислений с плавающей запятой — Itanium 2, в то же время в однопоточных вычислениях он лишь немного превосходил процессоры равной частоты (2,53 ГГц) с системой команд x86. При выполнении неоптимизированного под Itanium программного кода для x86-систем его производительность была в восемь раз меньше, чем у x86-процессоров на той же частоте.
Несмотря на достижение высокого уровня производительности в параллельных вычислениях без увеличения частот, архитектура Itanium не «взлетела» — продажи этих чипов не оправдали ожиданий разработчиков. Помимо неочевидных преимуществ перед x86 добавилась другая проблема — небольшое количество оптимизированного ПО. Учитывая, что портирование Linux на Itanium производилось без активного участия сообщества Open Source, финальной разработке недоставало многих важных деталей, имеющихся в оригинале.
Нужно отметить, что большая часть разработчиков ПО изначально отдала предпочтение x86-64, а не Itanium. Эта архитектура впервые появилась в процессоре AMD Opteron. Немногим позже Intel выпустила свой собственный
ARM и облако
Несмотря на то, что Itanium постепенно уходит с рынка, у x86 есть сильный соперник, который неплохо оптимизирован для работы в малонагруженных облачных средах — ARM Cortex. Разработкой этой архитектуры занимается одноименная британская компания, лицензирующая свои технологии Samsung, TSMC, Apple, Qualcomm, Huawei, Microsoft и даже конкурирующей Intel. Интересно, что Linux уже давно освоил эту архитектуру. Более того, её, пожалуй, можно назвать самой популярной на сегодняшний день — ежегодно в продажу поступает более миллиарда смартфонов на ARM-чипах с ОС Android, которая разрабатывалась Google c привлечением Linux-технологий.
Возможности ARM расширяют портирование Windows 8.1 и NT-ядра, которые работают на планшетах Surface 1 и Surface 2. Среди продуктов Microsoft есть и другие важные ОС, которые она доверила архитектуре британского разработчика, — Windows Mobile/Windows Phone и Windows Server. Последний в связке с чипами Qualcomm сможет работать в среде публичного облака Azure. Впрочем, говорить о чипах ARM как о замене процессоров Intel преждевременно. В плане производительности они существенно уступают чипам линейки i3 и даже Atom, не говоря уже о чипах серверного класса. За последние годы Intel удалось подтянуть параметры энергоэффективности чипсетов, но если сравнивать относительную эффективность и эксплуатационные издержки на x86-серверы с сопоставимыми решениями на базе ARM, то это сравнение будет не в пользу Intel.
Не исключено, что такие компании, как Microsoft, Google или Amazon, в огромных количествах закупающие чипсеты для обустройства серверных ферм, уже сейчас наряду с установкой энергоэкономичных чипов Intel экспериментируют с вариантами ARM-чипсетов, предназначенных для работы в ЦОДах. Нужно заметить, что ARM уже не первый год конкурирует с Intel на серверном рынке, но её доля остается мизерной — ARM-серверы используются для узкоспециализированных задач.
Перлоу считает, что использование блейд-серверов высокой плотности на базе ARM приобретёт для облачных вендоров совершенно новый смысл, если клиенты начнут управлять кодом своих приложений через контейнеры, а не хостовые ОС. «Сегодня облако — это IaaS и x86, но завтра это могут быть контейнеры, PaaS и ARM. Остается только дождаться, когда стоимость развертывания экземпляров контейнеров на ARM снизится и станет в несколько раз дешевле, чем развертывание ВМ. Если это произойдет, то x86 начнет постепенно уходить с рынка, как это происходит с чипсетами IBM System z», — сказал он.
HP стала первым крупным производителем, выпустившим ARM-серверы со стандартной конфигурацией, доступные на заказ любому клиенту. Не менее важным помимо выпуска серверов и SoC является развитие экосистемы программного обеспечения — ОС, прошивок, связующего ПО и приложений. Этим занимается некоммерческая организация Linaro Group. Она же занимается оптимизацией ПО с открытыми исходными кодами для