Импортозамещение технологиями – а не продуктами

Идея освобождения пользователя в компьютерных системах от бремени оборудования (hardware) с предоставлением функционала программного обеспечения (software, ПО) в виде чистой услуги не нова. Первоначально это реализовывалось в виде терминальных устройств больших вычислительных машин. Деловой функционал обеспечивался, но вот красочность и удобство интерфейса, к которым мы привыкли сейчас, напрочь отсутствовали. Да и форм-фактор терминальных устройств позволял говорить об освобождении пользователей от оборудования только на фоне больших машин, к которым они подключались. Но, однако, это было первое облако, «машина = сеть».

Появление персональных компьютеров (ПК) и их дешевизна дали пользователям иллюзию автономности и принесли временную радость, связанную с личным сепаратизмом. Ввиду дороговизны и нежелания делить радость обладания ПК с другими про сеть не вспоминали. Стало «машина = ПК». Но ненадолго.

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

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

Остальное доделает идея гиперконвергентности и иерархия SaaS-Cloud-Fog-IoT (ПО как услуга – облачный сервис – вычисляющий туман – Интернет вещей). Когда решительно всё на свете начинает вычислять, хранить и передавать, то классические ЦОДы с серверами, СХД, коммутаторами и периметрами станут нелепы и очень дороги. Классическая инфраструктура умирает, хотя мы из последних сил пытаемся её реанимировать. Многие утверждают, что «Cloud = ЦОД», но уже очевидно, что это простое упрямство особо упёртых реаниматологов.

ПО гиперконвергентной эпохи вынуждено быть гиперпереносимым и способным исполняться полностью и/или частично на всём, что подвернётся, выживать любым способом, чтобы предлагать себя как услугу наибольшему количеству клиентов. Там же, где оказываются услуги, обязательно должны быть клиенты, которые получают эти услуги? Вот оно, ключевое слово: «клиент», клиент-ориентированная инфраструктура.

Обратим внимание на некоторый не систематизированный список требований, который касается ПО и может соответствовать миру, к которому мы идём:

• ПО работает не только инклюзивно относительно hardware, но и эксклюзивно;
• масштабирование любым путём не позволяет рассмотреть, «что там внутри» hardware;
• отдельные части ПО, «подпрограммы», могут работать на разных и сильно удалённых агрегациях оборудования («микросервисы»);
• переносимый транслируемый код. Java уже устарела, ждём новостей;
• переносимый компилируемый (открытый) код, предпочтительный с точки зрения контроля качества и безопасности;
• разработка ПО сообществом, не объединённым в некоторую административную группу, но имеющим общую цель;
• открытые стандарты во всём: от технологий организации труда до технологий производства ПО.

Теперь перефразируем каждый тезис с точки зрения соответствия некоторой другой цели, именуемой «импортозамещением»:

• ввиду того, что мощностей производимого в России аппаратного обеспечения, может быть недостаточно, необходимо, чтобы прикладное ПО было способно работать не внутри одного сервера, а над неоднородной группой серверов;
• из-за возможной ресурсной ограниченности прикладное ПО должно масштабироваться вне зависимости от того, какого рода архитектуры и аппаратную единицу ему для этого предложили;
• для наибольшей устойчивости и надёжности ПО должно быть способно исполняться как на локальных ресурсах, так и на доступных доверенных ресурсах внешних партнёров и операторов;
• разнородность и развитие доступных аппаратных платформ требуют, чтобы ПО легко адаптировалось к новым ресурсам. Первоначально это может быть реализовано при помощи современных средств переноса, например, Java, но ввиду критических недостатков такого подхода следует искать другие пути;
• самый доступный путь переноса ПО – наличие прозрачного качественного кода, который легко проверить на безопасность и скомпилировать для новой аппаратной платформы;
• объём ПО, которое должно быть произведено в короткие сроки, а также требование к открытости и качеству кода, требует привлечение всех, в том числе и независимых, ресурсов производства ПО;
• что диктует необходимость использовать при производстве только открытые промышленные стандарты, не имеющие двусмысленных толкований.

Как легко понять, приведённая перефразировка определяется одним словом – «импортозамещение». Получается, что мы находимся в уникальной ситуации, когда наша локальная прикладная задача стала синонимом идущей и предстоящей технологической революции. При этом мы не имеем отягощения в виде наработок прошлого: гигантской индустрии, производящие сейчас вычислительные средства классической формации и диктующей устаревшие правила производителям ПО. В неё были вложены огромные средства и силы, разрушать её страшно. У нас её нет, разрушать нечего, можно начинать с чистого листа, взяв всё самое лучшее из созданного в мире.

Даже когда ПК захватили мир, исходная идея освобождения пользователя от бремени оборудования оставалась жива. Она реализовалось в так называемых тонких клиентах (ТК) или системах виртуализации рабочих мест (VDI). Это то же самое, что и в изначальной истории с «большими» машинами: всё делает некоторое сообщество серверов, а обращение к ним происходит с устройств, которые сами почти ничего не делают, кроме как позволяют обратиться к ПО, работающему на серверах. К тому же происходит это таким образом, как будто работаешь на собственном ПК, но вот только заботится о его эксплуатации и наполнении нет необходимости. К этому прилагался ещё целый ряд приятных мелочей: относительная свобода перемещения пользователя, малое энергопотребление на рабочем месте, централизованное управление, безопасность, надёжность, гибкость и др.

Но как только дело касалось реальной реализации и желания приблизить виртуальное рабочее место по функционалу к ПК, то всё рушилось: более-менее функциональный ТК стоил дороже соответствующего ПК, требовал более мощной сетевой инфраструктуры, избыточного количества серверов и сопутствующего оборудования поддержки, а также более квалифицированных, дорогостоящих кадров для обслуживания и поддержки. Никакие последующие бонусы не оправдывали объём первоначальных вложений и последующего содержания. Таким образом продвижение ТК/VDI являлось одним из самых очевидных маркетинговых надувательств компьютерного мира.

Но теперь всё изменилось. Разберёмся подробнее.

VDI подразумевает наличие следующих компонентов:

• клиент, который мы по привычке будем называть ТК;
• гипервизор виртуализации;
• операционная система (ОС), которая способна адекватно работать в среде виртуализованного рабочего места.

На данный момент, к счастью, клиентом может быть практически любое вычисляющее устройство: ПК, классический ТК, телефон или микрокомпьютер на ARM/MIPS. Последние особенно интересны, так как малы по размерам, имеют малую стоимость и энергопотребление, надёжны. Самое интересное, что их производительности, как показывает практика, хватает даже для того, чтобы воспроизводить видео в формате 4K без потери качества изображения и звука.

Особые требования предъявляются к ПО для клиента, то есть к операционной системе, которую также можно обозначит термином «прошивка» (firmware). С одной стороны, функционально оно достаточно просто, ибо исполняет только соединение и обмен данными с виртуальным рабочим местом. С другой стороны, оно должно быть очень быстро и просто переносимо, лучше всего в исходном коде, чтобы без особых усилий осваивать новые типы клиентов. А также использовать открытые стандарты для обеспечения максимальной совместимости с прикладным ПО, работающим внутри виртуальной машины, например, HTML 5. С третьей стороны, необходимо, чтобы firmware было дёшево. Только в таком случае реализуется идея клиента, стоимость которого стремиться к нулю.

Этим требованиям удовлетворяют ОС семейства Linux.

Вот один из возможных сценариев нового мира. Такого клиента операторы связи могут выдавать абонентам бесплатно при покупке/аренде у оператора виртуального рабочего места. Пользователь или абонент при этом может даже считать, что внутри клиента вообще нет никакого ПО, либо думать, что это просто носитель для ПО, как раньше CD-диски. Естественно, что к купленной услуге абонент может получить доступ откуда угодно и с любого адекватного устройства.

Места для стационарного ПК или ноутбука в этой схеме не остаётся.

Гипервизоров нам известно шесть. Так как пятый очень слабо распространён и не совсем гипервизор даже, а шестой, Virtuozzo от Parallels, нами слабо изучен (но можно посмотреть тут), то рассматривать будем только четыре:

• Microsoft HyperV (протокол RDP);
• VMWare Horizon (протокол Blast);
• Citrix XenDesktop (протокол HDX);
• Linux KVM (протокол Spice).

Первые два наиболее ориентированы на пользователя. Однако и HyperV, и, казалось бы, независимый от Microsoft Horizon влекут за собой неизбежное погружение в пучину продуктов Microsoft с последующим ношением крупных сумм денег в одну кассу. При этом размер сумм определяет кассир, спорить с которым бесполезно и небезопасно.

Citrix добился выдающих успехов в области виртуализации рабочих мест. В решение XenDesktop предлагается установить агента внутрь ОС, которую использует виртуальное рабочее мест, что позволяет работать в виртуальной среде практически как на отдельном физическом ПК (включая всевозможные мультимедиа-приложения и игры). Достаточно клиента на ARM, чтобы смотреть видео 4K и полноценно выполнять офисные задачи. Однако список ОС, которые позволяют сделать корректную установку агента, ограничен: конечно, Windows и те Linux-ы, которые в качестве графической оболочки используют GNOME. «Плюсом» также является и стоимость одного подключения: 182 доллара, хотя гипервизор при этом даётся бесплатно. У продукта, заметим, имеется сертификации ФСТЭК.

Взвесив все «за» и «против», можем сказать, что Citrix XenDesktop можно принять как временное решение в переходный период: и задаче уменьшения совокупной стоимости рабочего места соответствует, и критериям современной технологичности, которые, как мы считаем, равны импортозамещению (если взять клиенты российского производства и в качестве ОС для виртуального рабочего места использовать «наш» Linux). Добавляет оптимизма наличие всевозможных гибридных вариантов реализации, например, с существующего ПК под Windows можно запускать приложения в виртуальной среде под Linux, но какую-то часть использовать и на самом ПК под Windows.

Мы упомянули «переходный период». Переходный к чему? Необходим выбор, который позволял бы взять какой-то коммерческий гипервизор, желательно из списка, либо свободно распространяемое решение с открытым кодом. А может быть, и коммерческую реализацию на базе свободно распространяемого решения, как это часто делает, например,RedHat. При этом необходим открытый промышленный стандарт на протокол доставки виртуального рабочего места. Ни один из ныне существующих (RDP, Blast, HDX) для этого не подходит. Это проприетарные протоколы, применение которых предполагает существенные отчисления правообладателям.

А как же Spice и KVM? Многие отечественные производители ОС утверждают, что у них реализована VDI на базе этой пары. Трудно возразить на это утверждение, если выбирать между «да – есть VDI» и «нет – VDI не реализован». Но при рассмотрении функционала VDI на Spice и KVM для реального использования мгновенно выявляется незаконченность реализации, особенно в части мультимедиа. Изображение получается статичное и сильно «подвисает» при интенсивном изменении (например, перемещении/переключении окон), уже не говоря о полноценном видео. Звук при этом стремится отстать от картинки, либо пропасть вообще. Возможно, и такое решение применимо в каких-то урезанных терминальных приложениях, где одно окно на весь экран. Однако применить к такой схеме термин «VDI» невозможно.

Получается, что выбора нет: только XenDesktop. На данный момент – да, но выбор может появиться в ближайшем будущем. Фактически функционально решение Citrixотличается наличием агента, о котором упоминалось ранее. Если доработать пару Spice и KVM таким образом, чтобы использовать соответствующего агента для ОС рабочего места, то, возможно, функционал этой пары стал бы более приемлем. Видится даже более законченная схема: отечественный разработчик ОС, который уже производит Linux-подобную ОС для многих аппаратных платформ (x86, ARM, в перспективе – «Эльбрус», и т. д.), разработал бы Агента для своих ОС, реализующего цепочку: ТК (ARM, поддержка Агента со стороны клиента) -> Spice и KVM (поддержка Агента по доставке от клиента к ОС виртуального рабочего места) -> виртуальная машина рабочего места с интегрированным Агентом. Это был бы революционно новый шаг, реализующий VDI и освобождающий пользователя от бремени оборудования на рабочем месте. Можно с уверенность сказать, что Агент подойдёт (или потребует для этого минимальных доработок) для всех ОС отечественного производства, базирующихся на Linux. Т. е. будет возможен выбор и/или простая адаптация уже работающих систем.

Положительные последствия очевидны и многообразны. Нужен разработчик! Пока ещё есть время…

Об авторе: Александр Семинихин, директор департамента компании «РедСис Сибирь».

Сообщение Импортозамещение технологиями – а не продуктами появились сначала на Экспертный центр электронного государства.