Концепция облачных технологий существует уже порядка 10 лет и все это время активно обсуждается, что не мешает сохранению различного рода заблуждений относительно нее.

Удивительно, но до сих пор не все понимают, что означает сам термин «облако» и что такое «облачные технологии». Нередко к последним относят технологии, которые ничего общего с облаком не имеют, а облачный хостинг преподносится как решение всех ИТ-проблем, с которыми сталкиваются владельцы бизнеса.

Поэтому, прежде чем обсуждать достоинства и недостатки облачных вычислений, важно определить, что этот термин действительно значит.

Итак, определяющими характеристиками облака являются:

  • предоставление ресурсов по требованию;
  • самообслуживание;
  • масштабируемость и измеримость.

То есть, используя облачные сервисы, пользователи могут в любое время выбрать или скорректировать тип и объем предоставляемых ресурсов, оплачивая при этом только заказанные ресурсы.

Почему я так подробно на этом останавливаюсь? Потому что приведенные характеристики определяют и главные преимущества облачных технологий, а именно:

  • доступ к простым в использовании панелям управления и API, с помощью которых можно оперативно самостоятельно настроить решение;
  • снижение затрат на администрирование и поддержку системы;
  • возможность масштабирования ресурсов, что можно эффективно использовать в случаях резкого роста и спада потребности в них;
  • легко достигаемую высокую доступность приложений и продуктов.

Несмотря на эти очевидные преимущества облачных технологий, важно помнить, что не любое приложение, перенесенное в облако, будет работать быстрее или обойдется дешевле. На практике, если вы перенесете веб-сайт с физического на виртуальный сервер, купив услугу IaaS у одного из облачных провайдеров, скорее всего, это только увеличит стоимость хостинга.

Кто-то может спросить: «Как же так? Разве облачные сервисы не должны быть дешевле?» Ответ — могут быть дешевле, но только в том случае, если эти сервисы используются соответствующим образом. Давайте разберемся на примере: если вы покупаете мощный автомобиль Toyota Tundra вместо старого Volkswagen Golf и продолжаете ездить по тем же дорогам и с теми же грузами, то в конечном счете заплатите за топливо куда больше, не получив никакой дополнительной выгоды (за исключением удовольствия от езды на новой большой машине, но ведь изначальная цель ее приобретения заключалась не в этом). То же самое относится и к облаку — чтобы получить экономическую выгоду, нужно постараться максимально использовать их возможности и всегда ставить эффективность во главу угла.

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

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

Рассмотрим некоторые другие примеры из реальной практики, когда изначально выбранный подход оказался ошибочным.

Пример 1. Инфраструктура проекта в облаке

Для разработки нового сложного продукта компании требовалось решение для управления проектом (отслеживания дефектов в продукте, контроля исходного кода, непрерывной интеграции и управления требованиями). В конечном счете было выбрано решение Microsoft Team Foundation Server (TFS), которое установили на виртуальной машине в облаке, что было обусловлено следующими причинами:

  • наличием лицензии для TFS в рамках подписки на MSDN;
  • нежеланием инвестировать средства в собственную инфраструктуру и создавать новое рабочее место для системного администратора;
  • возможностью для разработчиков установить систему самостоятельно.

Сработал ли такой подход? Не совсем. После того, как было потрачено много времени и усилий команды разработчиков, руководители проекта задумались о том, чтобы перейти на Visual Studio Team Services (SaaS-решение). Разберемся, почему так получилось.

Администрирование TFS. И после успешной установки решение TFS нуждалось в администрировании. Когда база данных TFS начала быстро разрастаться, один из разработчиков был вынужден отказаться от своих текущих проектов и переключиться на эту проблему для изменения настроек и проведения регулярной очистки системы.

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

Выбор облачной инфраструктуры для выполнения проекта не способствовал экономии, а привел только к потере денежных средств. В таких ситуациях лучше выбирать из двух вариантов: размещать программное обеспечение на выделенных физических серверах или использовать SaaS-решение вроде Visual Studio Online. Давайте рассмотрим оба варианта подробнее.

Выделенные физические серверы

Преимущества:

  • низкая стоимость ресурсов (к ней для справедливого сравнения нужно прибавить заработную плату системного администратора);
  • полный контроль над аппаратными средствами.

Недостатки:

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

SaaS-решения

Преимущества:

  • моментальная доступность рабочей системы;
  • нет необходимости нанимать новых специалистов;
  • доступность системы с вероятностью 99,9% гарантирована официальным соглашением об уровне услуг;
  • прямая зависимость стоимости от количества пользователей и времени, потраченного агентом сборки.

Недостатки:

  • высокая стоимость.

Как оказалось, в данном случае выбор в пользу IaaS-решения был не лучшим. Имело смысл по максимуму использовать возможности облака (SaaS-решение) или остановиться на прямо противоположном подходе — использовании собственных выделенных и самостоятельно конфигурируемых серверов.

Пример 2. Тестирование вне облака

В данном случае главной целью была экономия средств на организации тестовой среды. Основная система была размещена на Azure Cloud Services (PaaS), а для ее тестирования использовались традиционные виртуальные серверы (IaaS). Это было сделано для того, чтобы:

  • сэкономить средства (традиционные виртуальные машины дешевле и требуют меньше ресурсов, так как доступность тестовой среды не так критична, как доступность бизнес-приложений);
  • избежать зависимости от провайдера (предполагалось, что организованное таким образом тестирование подтвердит работоспособность системы не только в Azure).

Год спустя было решено полностью перенести тестирование в Azure Cloud Services. Ниже перечислены факторы, которые повлияли на смену стратегии:

  • специфика PaaS не учитывалась во время ежедневного тестирования, некоторые проблемы всплывали только в момент доставки бета-версии системы;
  • поддержка двух параллельных реализаций (для PaaS и для IaaS) требовала дополнительных затрат на разработку;
  • реализации, специфичные для IaaS, воспринимались как тестовые (никто не задумывался всерьез об их надежности), а значит и независимость от поставщика была скорее иллюзией.

На первый взгляд, экономия средств на тестовой среде может показаться хорошей идеей, но обратная сторона этого вопроса важнее: тестовая среда должна быть как можно более похожа на среду разработки. В противном случае можно упустить множество важных моментов. Существуют другие способы снизить стоимость тестирования: отключение тестовой среды на ночь или сокращение количества и/или размера виртуальных машин.

Зависимость от одного провайдера. Плохо vs. Хорошо.

Опасаясь оказаться в зависимости от одного провайдера, следует принять во внимание следующее:

  • такие провайдеры, как Azure, Google и Amazon, уже доказали свою надежность (за многие годы успешной работы было всего несколько громких случаев массового отказа веб-сайтов их клиентов);
  • решения, предлагаемые провайдерами такого уровня, протестированы большим количеством пользователей в разных сценариях и ситуациях. Поэтому они заведомо гораздо более надежны, нежели заново разработанные «домашние» решения;
  • поддержка двух альтернативных решений предполагает равный объем тестирования для каждого из них, удваивая таким образом стоимость тестирования, что вряд ли приемлемо;
  • отказ от использования предлагаемых провайдером подходов в пользу «независимых» приводит к тому, что игнорируются наиболее оптимальные решения (и потенциал предоставляемых технологий не используется полностью).

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

Не стоит также совсем отказывать от эмуляции некоторых ресурсов во время разработки. Если возникают сложности с использованием ресурса разработчиками, эмулятор может значительно упростить их работу и повысить производительность. Важным моментом является то, что эмулятор рассматривается только как средство разработки, а не как способ обеспечения независимости от сервисов провайдера.

Заключение

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

В подавляющем большинстве случаев экономически целесообразно выбирать именно облачные технологии, но для получения выигрыша их возможности нужно использовать наиболее эффективным образом. Зачастую это означает, что лучше ориентироваться на высокоуровневые SaaS- или PaaS-решения, а не на базовые сервисы IaaS.

Автор статьи — старший разработчик программного обеспечения в компании Itransition.