Проблемы облачных вычислений

В предыдущей статье мы рассказали о некоторых отличительных особенностях облачных вычислений и трёх китах cloud computing – IaaS, PaaS и SaaS. В этот раз речь пойдёт о проблемах, которые стоят на пути повсеместного использования “облаков”.

Все проблемы облачных вычислений напрямую связаны с их особенностями: удалённостью, распределённостью, параллелизмом, абстрагированностью и так далее. На самом деле, ничего плохого в этом нет. Любое явление или предмет имеет как положительные, так и отрицательные стороны. Приходится либо мириться с недостатками, либо вообще отказываться от использования конкретного продукта. И облачные вычисления исключением не являются. Давайте рассмотрим их проблемы и претензии, которые предъявляются к ним сейчас.

Итак, одна из основных проблем – это перенос существующих приложений в “облако”. Во-первых, это не всегда возможно сделать из-за особенностей архитектуры конкретного приложения, его привязок к другим системам или сервисам, которые ещё/уже не будут перенесены в “облака”. Зачастую переход к облачным вычислениям невозможен из-за использования специфических API ОС или вызова низкоуровневых функций для оптимизации работы. Таких приложений, может быть, не очень много, но они есть. Бывают и такие случаи, когда перенос теоретически возможен, но это требует либо значительной переработки кода, либо переписывания всего набора ПО с нуля. Очень часто это экономически невыгодно. На самом-то деле совершенно аналогичную ситуацию мы наблюдаем уже лет пять. Ключевые понятия – 64-разрядность и многоядерность. Особенно “хорошо” обстоят дела с последним пунктом. Много ли вам известно программ, которые оптимизированы для работы с несколькими ядрами или потоками? Считанные проценты от всего разнообразия мирового софта при том, что “самые простые” 2-ядерные CPU существуют на рынке, мягко говоря, не первый год. Что уж тогда говорить про “облака”, в которых можно запускать тысячи потоков одновременно? Наконец, есть целый класс тяжелых приложений, которые вообще трудно куда-то перенести – видеоредакторы и конвертеры, 3D-игры, CAD-системы и трехмёрные редакторы, приложения реального времени и много что ещё. Впрочем, все эти проблемы отчасти решаемы. Для разработчиков создаётся богатый набор API, предлагаются новые модели и парадигмы программирования, разрабатываются инструменты для упрощения работы с многопоточностью и так далее. Даже идея переноса современных 3D-игр не так фантастична – сейчас как раз разрабатывается такой сервис. Идея, на самом деле, достаточно проста – игра запускается и рендерится на удалённом сервере, а клиенту передаётся только видеопоток. (Мечта любого правообладателя!) Требование только одно – качественный интернет-канал.

И это ещё одна проблема cloud computing – необходимость в постоянном подключении к Сети. Пропадает доступ в Интернет, и вы автоматически лишаетесь возможности работать. С учётом российских реалий эту проблему можно назвать первостепенной. Частичные решения уже давно есть. Например, GoogleGears позволяет работать с GoogleDocs или Gmail в оффлайн-режиме, а при первом же подключении синхронизирует всё с сервером. Правда, в Google неделю назад официально отказались от дальнейшей поддержки этой технологии и уповают на расширенные возможности HTML5 по работе с локальными данными. Microsoft в рамках парадигмы Software + Services (об этом уже говорилось в предыдущей статье) предлагает комбинированный подход – часть данных хранится и обрабатывается локально, а остальное отдаётся “облаку”. Но в данном случае упор всё же делается на решение другой проблемы – безопасности.

И первый вопрос, который волнует очень многих, звучит так: “Насколько надёжно хранить все свои данные в облаке?” По идее, облачные вычисления тем и хороши, что данные хранятся в распределённом виде и периодически архивируются. Однако никто не застрахован от сбоев. Подобные прецеденты уже были, например, с Gmail. Тогда удалось восстановить информацию большинства аккаунтов, но часть всё-таки пропала навсегда. Одно дело – любовная переписка, совсем другое – бизнес-информация. В первом случае можно немножко погоревать и забыть, а вот второй может грозить как минимум вынужденным простоем и потерей прибыли. Не случайно многие бизнес-пользователи предпочитают хранить всё на собственных серверах с настроенной системой бэкапов. В конце концов, даже если произойдёт сбой, и накопители повредятся, то их хотя бы можно будет достать и отнести на восстановление в соответствующую контору. А если такое произойдёт где-то в облаке, то всё будет зависеть уже от совести cloud-провайдера. Особенно “приятно” видеть в EULA пресловутый отказ от ответственности – мол, ничто в мире не надёжно. Выходом может стать только поддержание актуальной копии всех данных вне “облака”.

Если смотреть глубже, то проблема заключается скорее в доверии к облачным вычислениям. Точнее, в боязни многих пользователей потерять контроль над ИТ-инфраструктурой. Дело в том, что культура аутсорсинга на данный момент слабо развита, особенно в России. Для многих дата-центры являются всего лишь площадками для размещения своего оборудования, но не более того. Однако всё это цветочки в сравнении с ещё одной проблемой облачных вычислений –конфиденциальностью хранимой информации. Здесь есть два момента. Во-первых, никто не гарантирует, что ваши данные не будут просматриваться и анализироваться компанией, которая предоставляет облачные услуги. Мало ли, что там написано в соглашениях о конфиденциальности. В том же Gmail реклама “удивительным” образом соотносится с текстом просматриваемого письма. Во-вторых, многие забывают, что дата-центры располагаются на территории других стран и подпадают под их юрисдикцию. Например, в США (лидер по количеству ЦОД) ваши данные совершенно спокойно могут изъять под различными миловидными предлогами вроде борьбы с терроризмом. Более того, вас даже не обязаны уведомлять о самом факте изъятия! А уж о том, куда потом попадут данные, тем более. В качестве решения предлагается шифровать всю информацию, которая передаётся и хранится в “облаке”. Альтернативный вариант – наиболее критические данные хранить и обрабатывать локально, а всё остальное переложить на облачные вычисления.

Впрочем, есть ещё некоторые проблемы облачных вычислений, которые носят в большей степени философский или морально-этический характер. Например, некоторые считают, что скоро нас ждёт эра вездесущих монополий. Google, Microsoft, социальные сети и тому подобное всё крепче привязывают пользователей к своим сервисам. Возможно, что через некоторое время сложится такая ситуация, что отказаться от конкретного продукта станет либо очень сложно, либо вообще невозможно. Основатель Free Software Foundation Ричард Столлман (Richard Matthew Stallman) говорит об облачных вычислениях так: "Это глупость. Точнее, это даже хуже глупости – это маркетинговая программа, основанная на обмане". Он искренне считает, что каждый должен хранить данные на собственном компьютере и на нём же работать с ними. Он полагает, что cloud computing и сервисы подобные Gmail являются ловушкой для пользователя, которая прочно привязывает его к проприетарному ПО и отбирает контроль над информацией. Не исключено, что в будущем все эти сервисы в один момент потребуют оплаты, а у человека уже не будет возможности перехода. Глава Oracle Ларри Эллисон (Larry Ellison) вообще полагает, что сам термин cloud computing является только маркетинговой приманкой и часто не несёт особого смысла. Некоторые компании просто “обманывают” своих пользователей – чуть видоизменяют свой старый продукт, навешивают ярлычок “Основано на суперсовременных революционных технологиях облачных вычислений” и продают за большую цену.

Итак, мы рассмотрели основные проблемы облачных вычислений. На самом деле, список проблем на этом не заканчивается. Некоторые аспекты cloud computing изучены не до конца, поэтому в будущем может появиться ещё что-то. Трудно сказать, какая из вышеперечисленных проблем - наиболее важная. Всё зависит от конкретной ситуации. Надо понимать, что облачные вычисления это не панацея от всех проблем – у них тоже есть негативные аспекты. Также надо осторожно относиться к громким заявлениям о революционности новых продуктов.