Поделиться
Новые стандарты создают научную базу для облаков
Начиная использовать облачные решения в своей компании, ИТ-директор или руководитель фирмы должен ответить для себя на ряд вопросов. Что представляет собой облако? Возможно ли передавать конфиденциальные данные стороннему провайдеру? Наконец, есть ли на рынке ИТ-сервисы, полезные для компании? Некоторые из этих вопросов связаны с нехваткой знаний и сложившимися на рынке предрассудками, а другие имеют под собой вполне резонные основания.Существующие сегодня расхождения в понимании терминов «облачные технологии» и «облако» связаны с тем, что сначала это выражение ввели в обиход ИТ-специалисты, просто как некую «метафору» для обозначения сложной, многокомпонентной вычислительной инфраструктуры, потом подхватили журналисты. И только после нескольких лет использования под этот термин стали подводить некую научную базу и вводить определение. На текущий момент завершается разработка международных стандартов по облачным технологиям, поэтому «легкость» использования и многозначность термина «облака» будут постепенно уходить. К ожидаемым стандартам в этой сфере относятся: ISO/IEC CD 17788 «Информационные технологии – Распределенные прикладные платформы и сервисы – Облачные вычисления – Общие положения и словарь»; ISO/IEC WD 17789 «Информационные технологии – Облачные вычисления – Эталонная архитектура» (Information Technology – Cloud Computing – Reference Architecture). Их публикация должна быть завершена уже в 2014 г.
В обозначенных выше стандартах под облачными понимают технологии, обеспечивающие реализацию облачных вычислений (cloud computing), т.е. возможность сетевого доступа по требованию к пулу ИТ-ресурсов, ИТ-сервисов. Например, к отдельным приложениям, к ресурсам хранения данных и др.
При этом облачные технологии, чтобы называться облачными, должны удовлетворять ряду требований. Во-первых, это независимость от клиентского устройства – возможность использования облачного сервиса клиентом с различных устройств\терминалов. Во-вторых, возможность изменения параметров сервиса клиентом (самообслуживание по требованию) – клиент может сам варьировать отдельные параметры сервиса, в рамках соглашения с поставщиком. В-третьих, общий пул ресурсов – возможность перераспределения ресурсов между клиентами в зависимости от фактического потребления сервиса. В-четвертых, учет потребления сервиса – механизмы автоматизированного расчета параметров фактического использования сервиса клиентом (например, объем хранимых данных, трафик и т.п.).
Можно отметить, что далеко не все решения, позиционируемые сегодня как облачные, соответствуют перечисленным выше требованиям. Например, в корпоративных облаках редко реализован учет фактического потребления ресурсов. Многие из предлагаемых на рынке облачных сервисов предъявляют достаточно жесткие требования к клиентским устройствам. Возможность динамического перераспределения ресурсов также редко используется. Чаще ресурсы перераспределяются в ручном режиме и с установленным в договоре интервалом времени.
Предпосылки для развития облачной инфраструктуры
| Предпосылки облаков | Примеры |
|---|---|
| Технологические: | |
| Виртуализация | VMware, Microsoft, Citrix |
| Интернет-сервисы | Amazon, SalesForce, Google |
| Инструменты управления вычислительными ресурсами | Управление мощностями (перераспределение и выделение ресурсов) |
| Технологическое развитие | Каналы связи, сервера, сетевые устройства, устройства хранения данных |
| Методические: | |
| Сервисный подход к управлению ИТ | ITIL, SLA |
| Сервисный подход к созданию ИТ | SOA, веб-сервисы |
Источник: Телеком-Защита, CNews Analytics, 2014
Итак, хотя широкое распространение в течение последнего десятилетия слов «облачный сервис», «облачные технологии» – это заслуга скорей маркетинга, нежели технологий. Тем не менее, на сегодняшний день эти понятия уже определены достаточно четко и за ними стоит ряд как технологических, так и методических предпосылок.
Цена вопроса
Нельзя ответить на вопрос о том, дешевле облака, нежели внутренние системы, или нет, поскольку все зависит от конкретной ситуации и планируемого варианта использования облачных сервисов. Сравнение, как правило, усложняется тем фактом, что далеко не всегда (а точнее, почти никогда) в компаниях не ведется учет фактического использования внутренних ИТ-ресурсов, поэтому возможны варианты, что после миграции в частное или публичное облако ИТ-сервисов, общие затраты на них увеличиваются в связи с существенным увеличением потребления этих ИТ-сервисов. Т.е. увеличивается фактическое использование вычислительных ресурсов, которые раньше использовались меньше, так как их просто не хватало.
Активное использование внешней ИТ-инфраструктуры вместо собственной в первую очередь изменяет структуру затрат и дает дополнительные возможности управления этими затратами. Уменьшаются капитальные затраты, но почти всегда увеличиваются операционные. Если облачные сервисы соответствуют требованиям учета потребляемых ресурсов, то общие затраты на ИТ становятся более прозрачными. Появляются возможности планирования и управления этими затратами. Использование облачных ресурсов выгодно для решения временных задач – среды тестирования, разработки, временных аналитических задач. В этом случае ресурсы арендуются на время и освобождаются после завершения их использования.
Для правильной оценки издержек, связанных с переходом на отдельные облачные сервисы, необходимо, в первую очередь, зафиксировать «базу расчета» – совокупность показателей и характеристик существующих сервисов и поддерживаемых ими бизнес-процессов, которые будут переводиться или заменяться облачными решениями. Это бывает достаточно сложно сделать при модели SaaS, когда происходит смена используемых программных решений. Сложность связана с тем, что меняются функциональные характеристики получаемой услуги – какие-то функции могут отсутствовать, какие-то – стать менее удобными, или наоборот. Из-за этого могут измениться параметры бизнес-процесса, выполняемого сотрудниками с помощью данного сервиса. Если планируемое к использованию облачное решение более функционально и удобно, нежели используемые программные решения в компании, то, несмотря на дополнительные затраты по переходу на новое решение, оно может оказаться экономически оправданным, т.к. влияет непосредственно на достижение бизнес-целей. С другой стороны замена «заточенной» под конкретные процессы заказной информационной системы на некий универсальный облачный сервис, в котором отсутствуют привычные нужные функции, может казаться «выгодным» с точки зрения затрат на ИТ, но привести к существенному замедлению бизнес-процесса.
Сравнение затрат в классической и облачной моделях
| Статья затрат | Сервис 1. Классическая модель | Сервис 2. Облачная модель |
|---|---|---|
| Миграция на облачный сервис | Затраты на миграцию отсутствуют. Но необходимо оценить динамику потребления сервиса. Если предполагается существенное увеличение «потребления» сервиса в оцениваемый период, то необходимо включить затраты на обновление инфраструктуры и, часто, затраты на миграцию в новую инфраструктуру | Затраты существуют и могут быть достаточно велики, особенно при необходимости реализации дополнительных требований к информационной безопасности |
| Проектирование и создание ИТ-инфраструктуры | Присутствуют в случае первичного создания сервиса | Отсутствуют в случае использования уже существующего облачного сервиса |
| Приобретение оборудования\лицензий ПО | Присутствуют | Отсутствуют в случае использования уже существующего облачного сервиса. Присутствуют в случае проектирования и создания собственного (частного) облака |
| Использование сервиса, в год / Сопровождение оборудования и ПО | Данная статья затрат может включать: стоимость приобретения пакетов поддержки на лицензии ПО и оборудование (в случае ПО составляют около 20% от стоимость приобретения лицензий); стоимость сопровождения приложения внешними подрядчиками | Присутствуют (основная составляющая стоимости). Может варьироваться в зависимости от фактического объема потребления сервиса. В эту же статью затрат могут относиться затраты на право использования ПО |
| Контроль предоставления сервиса (соблюдение SLA, фактические параметры потребления) | Присутствуют, но, чаще в ограниченном виде | Увеличение данных издержек в силу дополнительных объектов и параметров контроля |
Источник: Телеком-Зашита, CNews Analytics, 2014
В случае приобретения облачных услуг по моделям IaaS и PaaS есть достаточно простые универсальные характеристики сервисов: процессорная мощность, оперативная память, объем дискового пространства, что упрощает расчет и сравнение издержек. Но и здесь существуют «скрытые» дополнительные показатели, которые нужно учитывать, – параметры уровня надежности инфраструктуры, скорости восстановления после сбоя. Некорректно сравнивать, например, затраты на предоставление облачной услуги в ЦОД с гарантированным временем восстановления не более 30 минут и затраты на приложение, установленное локально на рабочей станции, которое никак не резервируется. Стоимость облачной услуги по сравнению с решением, приобретаемым в собственность, определяется также периодом расчета. Чаще всего используются два горизонта оценки – 3 года или 5 лет. Если речь идет о миграции сервиса, уже реализованного в инфраструктуре компании в облако, появляются дополнительные издержки.
Безопасность конфиденциальных данных
Опасения по поводу уровня информационной безопасности облачных решений возникают из-за отсутствия в настоящее время принятой модели по обеспечению надежности хранения персональных данных, в случае их передачи во внешнее облако. А так как единых требований и понимания нет, то компании не хотят рисковать утечкой этих данных или доказывать внешним органам, что защита их реализована в соответствии с требованиями законодательства.
Объективно, в случае использования корпоративного облака (как для целей IaaS, так и для SaaS) общий уровень безопасности повышается, поскольку используются единые надежные механизмы доступа ко всем сервисам вместо разрозненных решений на уровне каждого отдельного приложения. Но при использовании внешних облаков (или корпоративных облаков на внешней инфраструктуре) сейчас нет возможности однозначно сказать, как именно провайдер должен обеспечить защиту информации, несмотря на то, что провайдеры предлагают своим заказчикам продвинутые инструменты в части контроля утечек данных (DLP), мониторинга трафика. Тем не менее, вопрос унификации требований к безопасности в облачной среде активно прорабатывается и уже появились международные стандарты (ISO/IEC WD TS 27017 – Руководство по мерам информационной безопасности для использования сервисами облачных вычислений, ISO/IEC WD 27018 – Свод практики по мерам защиты персональных данных при оказании публичных облачных услуг). Кроме того, появляется все больше организаций, которые, так или иначе, переводят на внешнюю инфраструктуру часть своих сервисов, в том числе связанных с хранением конфиденциальной информации. Таким образом, опасения по поводу безопасности данных постепенно развеиваются.
Развитие сетевой инфраструктуры
Потенциальная большая надежность публичных облаков может нивелироваться возможными проблемами каналов доступа к облачным решениям. Если говорить о России, то, хотя региональная сетевая инфраструктура развита достаточно хорошо, все еще существует проблема «последней мили». Эта проблема сейчас решается, например, в «Ростелекоме» в рамках комплексного проекта GPON по всей стране.
На практике, сейчас в России все еще заметно цифровое неравенство как в части доступных каналов связи, так и в части их стоимости. Крупные компании с распределенными по стране офисами, планируя использование облачных сервисов, VDI, IP-телефонии, обязательно начинают с проектирования сетей передачи данных, в том числе определения доступных каналов связи, их надежности и пропускной способности. Уровень развития каналов связи все еще является одним из главных ограничений, препятствующих распространению облачных сервисов в России. Недаром, одним из первых операторов, предлагающих облачные сервисы для государственных компаний и крупного бизнеса, стал «Ростелеком» (национальная облачная платформа О7), который может самостоятельно решить проблемы, связанные с обеспечением надежности и нужной ширины каналов связи.
Интеграция и перенос сервисов
Технические и интеграционные проблемы при смене традиционной архитектуры сервисов на облачную модель возникают не чаще и не реже, чем в любом интеграционном проекте. Связаны они, как правило, с проблемами в планировании и контролем исполнения проекта. С технологической точки зрения, сложностей в интеграции инфраструктуры компании с облачными сервисами, в создании гибридных облаков нет. Но есть факторы, связанные с ограниченными сроками и ресурсами на проект, с необходимостью реализации специфических мер по ИБ и др. Могут потребоваться работы по обновлению существующей инфраструктуры в части оборудования, каналов связи, инфраструктурного ПО, без выполнения которых невозможно осуществить проектное решение по интеграции с внешними облачными сервисами.
В общем случае, планируя масштабный проект по использованию облачных сервисов в компании необходимо предусмотреть реализацию следующих мероприятий. Технические мероприятия: виртуализация ИТ-инфраструктуры (если требуется); оптимизация инструментов мониторинга и управления ресурсами; анализ и модернизация структуры информационной безопасности. Методические мероприятия: реорганизация существующих ИТ-процессов; методика вычисления потребляемых ИТ-ресурсов и их тарификации; новый каталог ИТ-услуг; соглашения об уровне сервиса (SLA). Организационные мероприятия: создание новых подразделений (служба заказчика, отдел технического контроля и т.д.); организация деятельности новых подразделений.
Стоимость выполнения этих мероприятий должна быть учтена при оценке стоимости реализации проекта, и может составлять его существенную часть.
Качество SaaS и ожидания бизнеса
Считается, что первые компании, предлагавшие программное обеспечение как услугу, появились в конце 90-ых гг. Это SalesForce, Amazon, Google. Их предложения сейчас уже должны были бы отличаться надежностью и высоким функционалом. Но поскольку требования потребителей к характеристикам облачных услуг растут вместе с самими платформами (эластичность, гибкость, безопасность, надежность), то даже у этих провайдеров сейчас периодически возникают сложности с их коммерческими сервисами.
Для конечного пользователя использование сервисов по модели SaaS уже стало привычным даже в России – это плата за облачные хранилища данных, использование облачных Google Apps и многих других доступных через сеть приложений. Можно сказать, что при условии быстрого безлимитного доступа к интернету пользователь может получить удаленно через веб-сайт любой сервис (особенно, если не ставить ограничения по его гарантированной доступности, производительности, безопасности). Во многом это относится и к сегменту малого бизнеса и индивидуального предпринимательства. Однако для коммерческих приложений и сервисов, когда действительно требуется гарантия соблюдения SLA с жесткими требованиями, большинство внешних SaaS-предложений становится не применимо. И не столько в силу ограничений самой SaaS модели, сколько из-за большого количества дополнительных внешних факторов, за которые не отвечает ни поставщик сервиса, ни его потребитель (надежность каналов связи, требования к безопасности персональных данных и др.).
Исходя из текущего положения дел, облачные технологии по модели SaaS среди крупных компаний в России будут развиваться (и развиваются) в сторону частного облака. Но ситуация может сильно измениться, если в российское законодательство и Налоговый Кодекс будут внесены изменения, подталкивающие к сокращению собственной инфраструктуры, а также будут оперативно приняты дополнения к регламентирующим документам в сфере защиты персональных данных в публичных облаках.
Мария Бартенева,
Директор по консалтингу компании «Телеком-Защита»
Короткая ссылка
