`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Арсен Бандурян

Мысли об Amazon AppStream и облачном Remote Desktop

+66
голосов

В прошлом месяце Amazon представила AppStream, позволяющий выполнять и рендерить приложения в облаке AWS и отображать результат на обычных потребительских устройствах. Вскоре после анонса в Сети появилось немало статей, как бы подразумевающих, что теперь можно решить все вопросы просто накупив планшетов и используя AppStream в качестве некоего облачного Remote Desktop. Идея, безусловно отличная, но всё так просто...

Во-первых, многие (в т.ч. автор) после анонса пропустили тот факт что для работы AppStream необходимо еще написать клиентское приложение... Давайте посмотрим насколько просто запустить саму идею "облачного Remote Desktop" в качестве замены парку ПК, решения вопросов Desktop Support и мобилизации в целом. Равно как и с BYOD, здесь нужно хорошо понимать все детали при внедрении проекта и требования к клиентской части.

1. Безопасность. Как ни крути - вопрос номер 1 для Enterprise (после стоимости, конечно). Опустив аспект "доверия облакам" в целом, сосредоточимся на мобильности. Да, я теперь могу стримить свое жутко древнее HR-приложение прямо из облака на телефон/планшет HRов. Но как убедиться, кто данные этого приложения не утекут, когда этот телефон/планшет забудут в такси? Помнится, было немало опросов, показавших, что большинство пользователей даже не ставят блокировку экрана, т.к. это неудобно (я, кстати, один из них, в определенных случаях).

Не то, чтобы мы имеем дело с неразрешимой проблемой, но уже, получается, что для решения этого и других вопросов безопасности (шифрование данных, VPN, управление ключами и сертификатами и т.д.) в дополнение к подобному сервису нужно разрворачивать MDM. И разворачивать грамотно: с грамотной политикой, убедившись, что мобильные устройства полноценно поддерживаются MDM-системой (что требует авторизации производителя MDM производителем устройства для получаения root-прав MDM-агентом). В общем, вместо одного проекта на руках уже два. А на самом деле - три: кто еще должен написать политику безопасности в области мобильности. Причем политику, которая балансирует между интересами организации (безопасности) и пользователя (удобство), которую потом нужно утвердить, продвигать в массы ("и с чего это я должен считаться с глупыми правилами конторы?"), и следить за исполнением (причем и в части monitoring и в части enforcement). Как по мне, этот третий проект по сложности будет равен двум первым вместе взятым, если честно.

2. Продуктивность. Большинство старых приложений писались под клавиатуру и мышь, с комбинациями типа "Ctrl-Click" и "Alt-Shift-PgUp". Стримить такое на планшет возможно, а вот работать с ним - не очень :) Получается, нужно вкладывать в интерфейс клиенского приложения функции ремаппинга клавиш, переформатирования экрана, настраиваемой экранной клавиатуры с макросами и прочими "прокладками" для адаптации десктопных приложений к мобильному миру.

Тут тоже ничего страшного в принципе нет большинство из этих прокладок даже не надо изобретать - они уже реализованы в той или иной мере в специализированных продуктах. Так что если подойти к вопросу с умом можно значительно продлить срок жизни того самого "древнего HR-приложения". Но вот вам еще один проект впридачу, со своими проблемами и затратами (на внедрение и поддержку).

3. Потеря работоспособности. Та же давно известная проблема из разряда "модное против защищенного", "консумерское против корпоративного" и т.д: когда пользователь напортачит со своим устройством и из-за этого не сможет выполнить работу к заданному сроку - что делать? А что делать, если устройство глюкануло посреди какой-нибудь запутанной транзакции? Может AppStream держать сеанс открытым до возвращения пользователя? Возможно ли доработать клиентское ПО, чтобы по возвращении пользователь подключился именно в тот самй прерванный сеанс (в случае многосессионности)? Или придется привлекать админов, откатывать транзакцию, подчищать всё (и надеяться, что это не затронуло других работников) каждый раз, когда кто-то выпадает из зоны покрытия? Тут уже никакие доработки клиентского ПО не помогут.

Подводя итоги: AppStream - отличная идея с огромным потенциалом в целом (стриминг игр) и для корпоративного ИТ (и по разгрузке поддержки, и по мобилизации и повышению работоспособности сотрудников). Главное - не перевозбуждаться от маркетинга и трезво оценивать все нюансы при проектировании внедрении. А то получится как с BYOD :)

+66
голосов

Напечатать Отправить другу

Читайте также

Автору рекомендую прочитать FAQ по AppStream. Если его прочитать, то "Мысли об Amazon AppStream" переосмыслятся.

Изначально неправильное представление "вкратце - некий облачный Remote Desktop на базе AWS, позволяющий стримить десктопные приложения через веб в корпоративных масштабах".

В общем http://aws.amazon.com/appstream/faqs/ - рекомендую.

Согласен, немного промахнулся.. Подправил текст.

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT