Облачные технологии уже прошли относительно большой путь. Когда компания Amazon в 2006 году впервые представила сервисы Simple Storage Service (S3) и Elastic Compute Cloud (EC2), облака были еще в новинку, а сегодня облачные сервисы реализуют широкий круг функций — от хранения и вычислений до обслуживания баз данных и приложений. По впечатляющему росту клиентуры Amazon S3 можно судить о темпах расширения облачного рынка в целом — всего за шесть последних лет количество объектов (массивов двоичных данных), размещенных в Amazon S3, выросло с 200 тыс. до триллиона с лишним.
Впечатляющий рост применения облаков за столь короткое время произошел в основном благодаря новым технологическим компаниям, для которых ценность новшества оказалась очевидной. У стартапов вначале обычно мало или совсем нет заказчиков, они не знают, насколько успешным окажется их продукт или сервис, поэтому руководству трудно решиться на закупку инфраструктуры ИТ заранее. Гораздо разумнее выглядит аренда мощностей серверов и пространства хранения в нужном объеме с возможностью быстрого расширения в случае, когда компания добивается успеха. Благодаря только этому очевидному экономическому преимуществу, во многих начинающих компаниях вся инфраструктура ИТ работает в облаке.
Между тем в крупных корпорациях облачные технологии внедряются лишь местами. Если проект разовый, требует минимума интеграции с существующими системами и не создает угроз для корпоративной безопасности, то для использования облака есть убедительное экономическое обоснование, однако во многих других случаях владельцам приложений приходится преодолевать массу препятствий, чтобы воспользоваться облачными сервисами.
В рамках исследовательской программы Accenture Technology Labs по облачным вычислениям, впоследствии приведшей к созданию подразделения соответствующей специализации, было выяснено, какие опасения и препятствия мешают инициативам заказчиков по внедрению облачных технологий.
Помехи
Какие препятствия мешают предприятиям брать на вооружение облачные технологии? Перечислим основные — лишь те, что возникают практически на любом проекте и чаще всего занимают умы руководства.
Трудности с демонстрацией экономии
Многие корпоративные заказчики рассматривают облако как средство экономии затрат, поэтому операторы, как правило, именно в этом качестве рекламируют свои сервисы — чтобы оправдать использование облака, нужно доказать, что это принесет существенную экономию. Многие корпоративные заказчики признают, что благодаря эффекту масштаба облако позволяет получить инфраструктурные компоненты — серверы или хранение — дешевле, чем обошлись бы локальные системы. Увы, продемонстрировать эту экономию гораздо сложнее, чем это может показаться.
Расходы сложно подсчитать. Хотя любой провайдер четко указывает стоимость каждого своего сервиса, сравнить эти тарифы с затратами собственного ИТ-отдела непросто: облачные модели ценообразования сильно отличаются от привычных. Расходы на облако — это операционные затраты, и зависят они от объема потребленных сервисов. А покупка серверов и систем хранения — это капитальные затраты независимо от того, размещены ли на этих серверах какие-либо приложения. Чтобы сопоставить несопоставимое, придется расписать все затраты (стоимость серверов, расходы на электроэнергию, оплата труда администраторов и т. д.), отделить фиксированные от переменных, вычесть первые и распределить вторые по соответствующим приложениям. Ни один из этих шагов не будет простым.
Помимо всего этого, подбор самого недорогого оператора, сравнение их между собой тоже будут непростыми — у каждого оператора своя схема тарификации. Например, кто-то назначает расценки в зависимости от объема памяти, а другие — на основе количества процессорных ядер либо на базе каких-то внутренних мерок (как, например, Elastic Compute Unit компании Amazon). Чтобы сравнить вычислительные облачные сервисы (скажем, EC2 и GoGrid), придется разрабатывать сложные модели и разбивать затраты между процессором, памятью и дисковым пространством. Подсчет будет еще сложнее, если в сравнении участвуют хранение, СУБД или платформа в виде сервиса.
Высокая цена миграции. Затраты на сами облачные сервисы — это только часть головоломки, ведь львиная доля расходов может прийтись на перенос приложения в облако. Как показал опрос, проведенный Forrester Research, только 18,8% корпоративных бюджетов ИТ уходит на инфраструктурное оборудование, это подтверждают многие заказчики Accenture, сообщая, что лишь 20% их бюджетов ИТ расходуется на оборудование, а остальное идет на программное обеспечение и разработку приложений. При этом разработка может обойтись втрое дороже, чем ПО. Этих расходов часто не избежать при переносе существующего приложения в облако, так как облачная архитектура сильно отличается от привычной.
Предприятия, как правило, полагаются на вертикально масштабируемую архитектуру. Чтобы гарантировать достаточную производительность приложения, для него обычно приобретают сервер старшего класса. Например, хранилище данных одного из клиентов Accenture требует мощнейшего оборудования, не только чтобы быстро выдавать отчеты, но и просто потому, что сам объем данных очень велик. Чтобы обеспечить адекватное быстродействие, этот клиент купил сервер старшего класса с твердотельными накопителями (Solid State Drive, SSD) на сотни терабайтов. Так как это было задолго до распространения SSD, система обошлась в несколько миллионов долларов. Облака же строятся по иной, горизонтально масштабируемой архитектуре — облачные серверы обычно построены на стандартном оборудовании, а быстродействие каждого по отдельности далеко не самое высокое. Когда приложению нужно больше мощности, ему просто выделяется больше серверов.
Чтобы переключить приложение с корпоративной на облачную инфраструктуру, его, возможно, придется переписать. При этом изменения будут серьезными, поскольку нужно учесть, что разные фрагменты рабочей задачи могут исполняться на различных серверах. Чтобы полностью задействовать возможности облака, приложение должно динамически масштабироваться вверх и вниз по мере необходимости. Реализация такого механизма масштабирования — отдельная непростая задача.
Придется заплатить и за обучение. На крупных предприятиях может не оказаться специалистов с нужным набором навыков. Нередко разработчики обучены определенным технологиям, и освоение новых будет недешевым — например, многие программисты знают только Microsoft .NET, SharePoint и т. п., а если надо разместить приложение на Google App Engine,то программисту придется осваивать Java или Python, на что может уйти несколько месяцев. Доступность разных вариантов облаков для предприятия нередко определяется тем, готово ли оно переобучать разработчиков.
Безопасность
Вопросы безопасности волнуют любого руководителя любого облачного проекта. У многих вызывает обеспокоенность перспектива переноса одного из самых ценных активов организации — ее данных — в чужой ЦОД. Мало ли что случится, учитывая, что облако, например, может оказаться уязвимым для новых видов хакерских атак. Когда данные размещены локально, за их сохранностью следит команда инженеров по сетям и безопасности. Но когда данные выходят за корпоративный межсетевой экран, компании придется довериться облачному провайдеру, и смириться с этим непросто.
На первый взгляд это странно, ведь предприятия пользуются услугами колокации уже много лет — серверы могут находиться в чужом ЦОД или арендоваться. Ключевое отличие — в возмещении убытков. Облачные провайдеры обычно не возмещают заказчикам убытки за ущерб, возникший из-за невыполнения сервисного соглашения, — это было бы попросту несовместимо с бизнес-моделью, когда тысячи клиентов платят небольшие деньги в зависимости от объемов использования. Без возмещения предприятия не хотят брать на себя риск использования чего-то, что нельзя контролировать. Соответственно, заказчики не желают переносить в облако приложения, которым нужна надежная защита.
Но даже для приложений, менее требовательных к защищенности, путь в облако не будет гладким. На многих крупных предприятиях за безопасностью внутри межсетевого экрана следит отдельная команда специалистов, и когда их вызывают, чтобы подписать решение о переносе приложения в облако, они могут составить длинный перечень требований, в том числе таких, которые бы они сами не смогли выполнить для внутренних приложений. Так как облако вне их контроля, перечень требований будет максимально пространным, чтобы избавить себя от какой-либо ответственности. Защита данных нужна для многих приложений, например, в финансовых учреждениях практически каждый документ помечен грифом «конфиденциально» — в таких организациях практически ни одно приложение не пройдет проверку отдела по безопасности.
Соответствие нормативным требованиям
Нарушение предприятием нормативных требований чревато разрушительными последствиями. Во многих странах приняты строгие законы о том, что данные не могут покинуть пределов государства и должны храниться на серверах на его территории. Некоторые облачные провайдеры, например Google, не раскрывают, где хранят данные, поэтому подобный закон для этого провайдера выполнить нельзя. С недавнего времени Google позволяет заказчику выбрать в качестве региона хранения Европу, но не конкретную страну.
Кроме того, некоторые регуляторы ограничивают полномочия на доступ к данным и принципы их хранения. Например, американский закон HIPAA регламентирует защиту электронных медицинских карт и круг лиц, которые имеют право на доступ к ним. Проверка приложения на соответствие законам о конфиденциальности — болезненный и отнимающий немало времени процесс.
Факторы в пользу перехода в облако
Несмотря на все препятствия, организации берут облака на вооружение по целому ряду причин. Для корпоративных заказчиков важнее всего даже не возможность снижения расходов, а возможность улучшения адаптируемости бизнеса.
Очевидно, что предприятия будут все шире использовать облака. Приложения, легко интегрируемые и не требующие переработки, а также не хранящие конфиденциальных данных, — главные кандидаты на перенос в облако. Но судя по клиентуре Accenture, главной движущей силой массового перехода в облако станут системы работы с Большими Данными, которые способны больше всего выиграть от преимуществ облаков, к тому же подготовить экономическое обоснование, основываясь на улучшении адаптируемости бизнеса или высокой окупаемости, проще, чем говорить об абстрактном «снижении расходов». Перечислим ключевые преимущества, важные для приложений Больших Данных.
Быстрое выделение ресурсов
Облачные сервисы быстро доступны — поскольку ресурсы выделяются автоматически, заказчики могут получить необходимый им объем практически мгновенно. На предприятиях ситуация совершенно иная — там на получение дополнительных ресурсов могут уйти месяцы: владелец корпоративного приложения должен подготовить экономическое обоснование, заручиться разрешением от руководства, получить добро на финансирование от бухгалтерии и провести закупки по заранее согласованным каналам. Для приложений Больших Данных процесс получения ресурсов еще более долгий — они требуют больше денег как на аппаратную инфраструктуру, так и на программный стек, поэтому экономическая целесообразность проекта будет изучаться тщательнее.
Для приложений Больших Данных готовить аргументы, исходя из окупаемости, проще. Очевидно, что для таких приложений возможность быстрого выделения ресурсов критически важна, поскольку ценность данных с течением времени стремительно падает. Например, когда речь идет о сделанных клиентами покупках, то через несколько месяцев прогнозировать по ним вероятные будущие покупки станет бесполезно.
Облако упрощает не только своевременное выделение ресурсов, но и их расширение без отключения приложения, что важно для многих систем, обрабатывающих Большие Данные в режиме реального времени. Когда нужно обработать мощный поток входной информации, приложение может оперативно задействовать дополнительные серверы, чтобы справиться с нагрузкой. Без возможности динамического масштабирования качество обслуживания клиентов будет страдать.
С одной стороны, у облаков высокая окупаемость, с другой — затраты на них ниже, чем на локальные системы. В облачной среде вы платите только за потребленный объем ресурсов. При анализе Больших Данных нужно много ресурсов, но как только отчет сгенерирован, расходы прекращаются до следующего отчета (на сутки, неделю или квартал). Благодаря огромному разбросу в уровнях требуемых ресурсов для разных приложений их владельцы могут добиться максимальной экономии.
Снижение накладных расходов
Многие задачи, решаемые при внедрении приложения, не имеют отношения к бизнес-логике: например, создание аппаратной инфраструктуры, разработка политики безопасности и конфигурирование базы данных — все это обязательные работы, не приносящие дохода. Предлагая их в виде сервиса, облако прячет всю сложность за интерфейсом, позволяя повысить продуктивность труда корпоративных разработчиков. Например, сервис Microsoft Azure SQL Database маскирует детали конфигурирования, масштабирования и администрирования сервера баз данных, позволяя быстро ввести в действие корпоративное приложение без найма администратора СУБД.
Кроме того, облако позволяет повысить степень автоматизации. Например, в Amazon EC2 есть механизм под названием User-Data, позволяющий передать произвольные конфигурационные данные каждой запускаемой пользователем виртуальной машине. С его помощью можно, в частности, одновременно запустить несколько виртуальных машин, заставить их объединиться в кластер и автоматически начать обработку задачи MapReduce. При подобном уровне автоматизации не только снижаются расходы (нет нужды держать виртуальные машины работающими только для сохранения своих состояний), но и упрощается тиражирование — аналитик может быстро организовать отдельный кластер для проверки новой гипотезы, и ему предварительно не понадобится согласовывать с коллегами использование общей инфраструктуры.
Разнообразие сервисов
Масштаб и разнообразие задач, связанных с Большими Данными, породили в последние годы немало новаций — например, появились всевозможные базы данных NoSQL для различных потребностей. MongoDB, в частности, построена на документо-ориентированной модели данных, оптимально подходящей для хранения данных, связанных отношениями «один ко многим», и, например, при создании сервиса блогов не нужно идти на ухищрения, привязывая модель данных к табличной структуре реляционной базы.
Хотя многие из систем NoSQL доступны в открытых кодах, экспериментировать с ними в облачной среде гораздо проще, чем тестировать на внутренних системах. Более того, несколько таких систем доступны только в виде облачных сервисов — например, сервис Google BigQuery позволяет предприятиям гораздо быстрее строить новые приложения с гарантированно высокой производительностью.
Кроме того, благодаря разнообразию сервисов проще быстро создавать сложные приложения, особенно при работе с системами, в которых требуется, чтобы старая информация архивировалась, а не уничтожалась. Скорее всего, здесь понадобится многоуровневая среда хранения, в которой более свежие данные содержатся на быстрых и дорогостоящих накопителях для возможности быстрого извлечения, а старая информация — на архивных носителях для снижения затрат. Локально такое решение построить непросто, поскольку нужно создавать две раздельные инфраструктуры, а при использовании облака нужная среда уже доступна. Например, как вариант можно использовать Amazon S3 для хранения данных частого доступа, а Amazon Glacier — для архивного.
***
Для того чтобы у предприятий были стимулы к внедрению облаков, недостаточно фактора снижения расходов, и не только из-за сложности расчета затрат, но также в связи со значительными издержками на переход в облако и интеграцию. Поэтому аргументация в пользу облачных сервисов должна базироваться на повышении адаптируемости бизнеса. Если корпоративный разработчик сможет перенести функции, не касающиеся бизнес-логики, на плечи облачных провайдеров, предприятие сумеет ускорить процесс вывода новшеств на рынок, отказаться от лишних задач и быстрее реагировать на рыночные изменения.
Чтобы стимулировать предприятия к применению облаков, операторы должны создавать больше высокоуровневых облачных сервисов, способных помочь в улучшении адаптируемости бизнеса. Ориентироваться при этом надо прежде всего на приложения Больших Данных. Когда сложность администрирования и масштабирования систем обработки Больших Данных скрыта, предприятия получают важное преимущество в виде повышения продуктивности. В соответствующем направлении уже двигаются крупные операторы облаков, такие как Amazon и Google, однако, к сожалению, многие другие облачные провайдеры «застряли», ограничиваясь предложением серверов и средств хранения.
Хуань Лю (huan.liu@accenture.com) — директор по исследованиям Accenture Technology Labs.
