Применение облачных сервисов для автоматизации бизнеса

Рисунок 1.3- Программное обеспечение SaaS.

SaaS - модель развертывания приложения, которая подразумевает предоставление приложения конечному пользователю как услуги по требованию (ondemand). Доступ к такому приложению осуществляется посредством сети, а чаще всего посредством Интернет-браузера.

В данном случае, основное преимущество модели SaaS для клиента состоит в отсутствии затрат, связанных с установкой, обновлением и поддержкой работоспособности оборудования и программного обеспечения, работающего на нём. Целевая аудитория - конечные потребители.

В модели SaaS:

• приложение приспособлено для удаленного использования;

• одним приложением могут пользоваться несколько клиентов;

• оплата за услугу взимается либо как ежемесячная абонентская плата, либо на основе суммарного объема транзакций;

• поддержка приложения входит уже в состав оплаты;

• модернизация приложения может производиться обслуживающим персоналом плавно и прозрачно для клиентов.

С точки зрения разработчиков программного обеспечения, модель SaaS позволит эффективно бороться с нелицензионным использованием программного обеспечения, благодаря тому, что клиент не может хранить, копировать и устанавливать программное обеспечение.

По-сути, программное обеспечение в рамках SaaS можно рассматривать в качестве более удобной и выгодной альтернативы внутренним информационным системам.

Развитием логики SaaS является концепция WaaS (Workplaceas a Service - рабочее место как услуга). То есть клиент получает в свое распоряжение полностью оснащенное всем необходимым для работы ПО виртуальное рабочее место.

По недавно опубликованным данным SoftCloud спросом пользуются следующие SaaS приложения (в порядке убывания популярности):

• Почта;

• Коммуникации (VoIP);

• Антиспам и антивирус;

• Helpdesk;

• Управление проектами;

• Дистанционное обучение;

• CRM;

• Хранение и резервирование данных.

Весьма схожими являются продукты MobileMe (Apple), Azure (Microsoft) и LotusLive (IBM). Суть данных сервисов в том, что они предоставляют пользователям доступ к хранению своих данных (контакты, почта, файлы), а также для совместной работы нескольких пользователей с документами.

Вопросами хранения пользовательских данных в Интернет озадачена и компания Google, которая разрабатывает проект GDrive, который будет представлять собой виртуальный жесткий диск, который будет определяться ОС как локальный. Также заявлено, что можно будет хранить неограниченное количество данных, что звучит весьма заманчиво.

Хранение файлов без ограничений также предлагает MediaFire.com. Имеется как полностью бесплатное использование (правда, с некоторыми ограничениями, например, на максимальный размер загружаемого файла), так и покупка премиум-аккаунта, расширяющего возможности (например, шифрование файлов, получение прямых ссылок на скачивание).

Еще одним интересным представителем вида SaaS является продукт iCloud, представляющий собой операционную систему, работать с которой можно непосредственно через браузер. Интерфейс операционной системы выполнен в стиле WindowsVista/XP. На сегодняшний день проект находится в стадии беты и в самой ОС реализован минимум приложений.

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

Данную услугу сейчас предоставляют множество компаний, в том числе, такие как Nero и Symantec.

Интересное применение cloud-технологиям нашли и разработчики компьютерных игр: теперь современным компьютерам и игровым приставкам не будут нужны мощные графические адаптеры (видеокарты), ведь вся обработка данных и рендеринг будут производиться cloud- серверами, а игроки будут получать уже обработанное видео. Одним из первых заявил о себе сервис OnLive, и совсем недавно об этом заговорила и компания Sony, которая собирается внедрить данную идею в Playstation 3.

Согласно SaaS-концепции пользователь платит не единовременно, покупая продукт, а как бы берет его в аренду. Причем, использует ровно те функции, которые ему нужны. Например, раз в год вам нужна некая программа. И чаще вы ее использовать не собираетесь. Так зачем же покупать продукт, который будет у вас лежать без дела? И зачем тратить на него место (в квартире, если это коробка с диском, на винчестере, если это файл)?

Конкуренция в облачной сфере привела к появлению бесплатных сервисов. Именно по такому пути пошли два конкурента -- Microsoft и Google. Обе компании выпустили наборы сервисов, позволяющих работать с документами. У Google это GoogleDocs, у Microsoft -- OfficeWebApps.

При этом, оба сервиса тесно взаимосвязаны с почтой (Gmail в первом случае и Hotmail во втором) и файловыми хранилищами. Таким образом, пользователя как бы переводят из привычной ему оффлайн-среды в онлайн. Важно, что и Google, и Microsoft интегрируют поддержку своих онлайн- сервисов во все программные среды -- как настольные, так и мобильные (напомним, что Google создала ОС Android, а Microsoft -- WindowsPhone 7).

Аналогичную концепцию (но с несколько другими акцентами) продвигает и главный конкурент обеих компаний -- Apple. Речь идет об очень любопытном сервисе под названием MobileMe. Сервис включает в себя почтовый клиент, календарь, адресную книгу, файловое хранилище, альбом фотографий и инструмент для обнаружения утерянного iPhone. За возможность пользоваться всем этим Apple берет примерно 65 евро (или 100 долларов) в год. При этом Apple обеспечивает такой уровень взаимодействия своего набора интернет-сервисов и приложений на компьютере (под управлением Mac OS X), телефоне, плеере и iPad, что необходимость в использовании браузера пропадает. Вы пользуетесь привычными программами на своем Mac, iPhone и iPad, однако, все данные хранятся не на них, а в облаке, что позволяет забыть о необходимости синхронизации, а также -- о их доступности.

Если Apple интегрирует веб-сервисы в привычные приложения операционной системы, то Google заходит с противоположной стороны: разрабатываемая интернет-гигантом операционная система Chrome OS представляет собой, фактически, один браузер, через который пользователь взаимодействует с разветвленной сетью веб-сервисов. ОС ориентирована на нетбуки, отмечаются очень низкие системные требования и отсутствие необходимости самостоятельной установки программ (так как все программы работают непосредственно в вебе). То есть Google предоставляет преимущества облачной концепции, обычно декламируемые при работе с корпоративными клиентами, обычным пользователям. Вместе с тем, очевидна невозможность использования таких нетбуков в странах с недостаточно широким проникновением широкополосного интернета.

Потому что без интернета нетбук на базе Chrome OS будет совершенно бесполезен.

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

Помимо различных способов предоставления сервисов различают несколько вариантов развёртывания облачных систем:

Частное облако (privatecloud)- используется для предоставления сервисов внутри одной компании, которая является одновременно и заказчиком и поставщиком услуг. Это вариант реализации «облачной концепции», когда компания создает ее для себя самой, в рамках организации. В первую очередь реализация privatecloud снимает один из важных вопросов, который непременно возникает у заказчиков при ознакомлении с этой концепцией - вопрос о защите данных с точки зрения информационной безопасности. Поскольку «облако» ограничено рамками самой компании, этот вопрос решается стандартными существующими методами. Для privatecloud характерно снижение стоимости оборудования за счет использования простаивающих или неэффективно используемых ресурсов. А также, снижение затрат на закупки оборудования за счет сокращения логистики (не думаем, какие сервера закупать, в каких конфигурациях, какие производительные мощности, сколько места каждый раз резервировать и т.д.

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

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

Смешанное (гибридное) облако - совместное использование двух вышеперечисленных моделей развёртывания

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

Рисунок 1.4- Взаимосвязь облаков разных типов.

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

Достоинства и недостатки облачных сервисов

Как и у любой технологии, облачные технологии имеют свои достоинства и недостатки.

К основным достоинствам можно отнести следующие:

-Доступность - «облака» доступны всем и везде, где есть Интернет и с любого устройства, где есть браузер;

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

-Гибкость - неограниченность вычислительных ресурсов (виртуализация). Надежность - специально оборудованные ЦОД имеют дополнительные источники питания, регулярное резервирование данных, высокая пропускная способность Интернет канала, устойчивость к DDOS атакам;

-Не требуются большие вычислительные мощности ПК- по сути любой смартфон, планшет и т.д., при открытии окна браузера получает огромные потенциал;

-Отказоустойчивость;

-Высокая скорость обработки данных;

-Экономия на покупке софта - все необходимые программы уже есть в сервисе. Где будут работать сети;

-Ваш собственный винчестер не переполняется - все данные хранятся в

-Безопасность - "облачные" сервисы имеют достаточно высокую безопасность при должном её обеспечении, однако при халатном отношении эффект может быть полностью противоположным;

-Конфиденциальность "облаков", особенно находящихся в специально оборудованных ЦОД (Центр Обработки Данных), очень высокая, так как такие ЦОД имеют резервные источники питания, охрану, профессиональных работников, регулярное резервирование данных, высокую пропускную способность Интернета-канала, высокая устойчивость к DDOS-атакам.

Недостатки же можно выделить следующие:

-Постоянное соединение с сетью - для работы с «облаком» необходимо постоянное подключение к сети;

-Программное обеспечение - пользователю доступно только то программное обеспечение, которое есть в «облаке», а также пользователь не может настраивать приложения под себя;

-Потеря информации в «облаке» означает невозможность ее восстановления;

-Хотя «облако» является достаточно надежной системой, но в случае проникновения злоумышленника, ему будет доступен огромный объем данных;

-Облачная услуга предоставляется всегда какой-либо компанией, соответственно, сохранности пользовательских данных зависит от этой компании;

-Появление облачных монополистов;

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

Как мы видим, преимуществ у облачных сервисов всё же больше, чем недостатков. Но недостатки всё-таки есть, и некоторые из них довольно-таки серьёзные. Как например, при проникновении злоумышленника, можно потерять засекреченные данные. И мало ли что он ещё с ними сделает. Фирма может «потерять своё лицо» или понести значительные траты.

Планирование перехода на облачную обработку данных

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

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

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

1) Пользователю не нужно заботиться о производительности своего ПК, не нужно переживать о свободном месте на дисковом пространстве. С облачными технологиями этот вопрос автоматически снимается сразу же, на первых этапах.

2) Пользователю не нужно тратиться полностью на весь нужный ему продукт. Тем более что в дальнейшем большая его часть может и не понадобиться ему вообще. Он платит только за услугу, предоставленные возможности и только за конкретные функции.

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

Рисунок 1.5- Облачные технологии в бизнесе

Далее рассмотрим вопросы лицензирования программного обеспечения.

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

Во многих современных облачных средах вы платите за ресурсы, используя такие единицы измерения ресурсов, как CPU-час. Например, самая дешевая из виртуальных машин в облаке Amazon стоит $0,10 за каждый час пользования экземпляром. Если эта виртуальная машина проработает 10 часов, а затем будет остановлена, вам потребуется заплатить за ее использование всего $1,00 -- даже если это будет единственным фактом вашего пользования облаком Amazon в течение месяца.

В реальной жизни вы можете пользоваться, например, таким рабочим сценарием:

- начиная с полуночи и до 9 часов утра ваше приложение работает на двух серверах приложений (два сервера приложений используются для обеспечения избыточности);

- с 9 часов утра и до 17:00 вы запускаете еще 6 дополнительных серверов приложений, чтобы удовлетворить требованиям по нагрузке в рабочие часы;

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

Если все это просуммировать, вам понадобится оплачивать 110 часов машинного времени в сутки. Если бы вы использовали традиционную инфраструктуру, вам бы потребовалось купить восемь серверов, которые работали бы все время.

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

Таким образом, при переходе на облачные вычисления вам необходимо прояснить условия лицензирования вашего ПО, в частности:

-поддерживает ли ваша лицензия расчет затрат на основе времени использования (CPU-час, количество пользователей и т. д.)?

- поддерживает ли само ПО работу в виртуальных средах?

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

С точки зрения модели лицензирования, идеальным для использования в облачной среде является ПО на основе открытого кода (OpenSource). Фактически именно гибкость модели лицензирования OpenSource и сделала возможной реализацию облака Amazon. Если вы сможете полностью ликвидировать вопросы лицензирования при развертывании ваших приложений в облачной инфраструктуре, вы можете сконцентрироваться на других вопросах перехода на использование облачной обработки данных. Хотя большинство решений на основе открытого кода (например, Apache и большинство дистрибутивов Linux) предоставляют вам полную свободу действий, с вопросами лицензирования вам все же придется столкнуться, если вы приобретаете поддерживаемые версии программного обеспечения OpenSource, например RedHatEnterpriseLinux или MySQLEnterprise. К счастью, схемы лицензирования такого ПО вполне дружественны по отношению к использованию в облачной инфраструктуре.

Если не брать в расчет модель лицензирования OpenSource, которая наилучшим образом подходит для облачных вычислений, то второй будет модель, в соответствии с которой плата взимается за CPU в час. По мере того как облачная модель входит в обиход, все большее и большее количество поставщиков предлагают услуги с почасовой оплатой. Например, Microsoft, Valtira, RedHat, Vertica, Sun, а также многие другие компании уже приняли условия почасовой оплаты за CPU и довольно неплохо поддерживают облачную обработку данных. Oracle тоже рекламирует свою доступность в облачных вычислениях, но вот, к сожалению, они все равно придерживаются своей устаревшей модели лицензирования, которая направлена на поддержание традиционных условий.

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

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

Некоторые программы, схемы лицензирования которых основаны на количестве процессоров, требуют проверки (валидизации) на специальном сервере лицензирования. Любое ПО, в котором налагается такое требование, в облачной среде может оказаться неработоспособным, если оно не является достаточно интеллектуальным, чтобы "на лету" распознать замену физического сервера лицензирования на виртуальный. Даже если такое ПО и может распознать замену, вам все равно потребуется убедиться в том, что сервер лицензирования позволит вам запустить то количество серверов, которое вам требуется.

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

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

Рассмотрим также, чего будет стоить переход к модели затрат на облачную среду.

Как уже было рассмотрено ранее, плата за облачные ресурсы взимается по факту их использования. Для Amazon эта модель основана на такой единице, как CPU-час. Для некоторых других облаков, например, GoGrid, применяется оценка в RAM-час. Рассмотрим пример оценки затрат, которые придется понести с учетом потребности в ресурсах, описанной чуть ранее (два сервера приложений в течение интервала от полуночи до 9:00, восемь серверов в течение интервала от 9:00 до 17:00 и четыре -- с 17:00 до полуночи).

Предположим, что вы имеете такую основную инфраструктуру: 6/CPU-час: один балансировщик нагрузки 23/CPU-час: два сервера приложений 46/CPU-час: два сервера баз данных

В этом случае ваша ежедневная плата составит: 137+2509+2190=4836.

Ваши ежегодные затраты на хостинг составят 1765140 рублей без учёта лицензионных отчислений за ПО, инструменты управления облачной инфраструктурой и заработной платы сотрудникам.

Подходы к сравнению расценок

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

- оценочные затраты на использование виртуального сервера в течение трех лет;

- оценочные затраты на лицензионные выплаты на поддержку использования виртуального сервера в течение трех лет;

- оценочные затраты на инструменты управления облачной инфраструктурой (в случае их применения) в течение трех лет;

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

- затраты на использование любых сторонних инструментов для работы с облачной средой.

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

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

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

При выполнении сравнения вам необходимо исследовать следующие аспекты имеющихся альтернативных вариантов.

- Каковы будут ваши затраты на предоплату (плата за установку, капиталовложения в физическое пространство, затраты на аппаратные средства, покупку лицензий)?

- Каковы предполагаемые трудозатраты на установку инфраструктуры?

- Каковы затраты, ассоциированные с работой инфраструктуры (хостинг, арендная плата за помещение, затраты на электроэнергию, страхование)?

- Каковы трудозатраты, ассоциированные с поддержкой аппаратных средств и сетевой инфраструктуры?

- Каковы предстоящие затраты на лицензирование и/или апгрейд?

Каковы будут затраты на поддержку программного обеспечения?

Пример анализа прибыли на инвестированный капитал

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

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

Данный конкретный пример подразумевает, что два сервера приложений без особых проблем поддерживают стандартные требования к ресурсам и производительности. Кроме того, в рассматриваемом примере предполагается, что период пиковых нагрузок наступает на 15-й день каждого месяца и продолжается 24 часа. Обслуживание этой пиковой нагрузки при обеспечении определенного уровня производительности в соответствии с требованиями стандарта требует подключения четырех дополнительных серверов. Если ограничиться всего двумя дополнительными серверами приложений, то рассматриваемая система все же может функционировать при пиковых нагрузках, но ее производительность существенно упадет.

Если вы начинаете вести бизнес "с нуля", то для организации минимально необходимой инфраструктуры вам понадобится приобрести следующее оборудование:

-полустойку у надежного ISP с полосой пропускания, достаточной для поддержания ваших требований;

- два надежных брандмауэра (firewall);

- один надежный аппаратный балансировщик нагрузки;

- два хороших коммутатора гигабитного Ethernet;

-шесть надежных серверов бизнес-класса (для работы в условиях пиковых нагрузок на 15-й день).

Если вы сделаете выбор в пользу облачной инфраструктуры, вам потребуются несколько виртуальных экземпляров:

- один 32-битный экземпляр умеренной производительности (модель medium);

- четыре 64-битных экземпляра (модель large) для работы в стандартных условиях, с увеличением их количества до 8 для работы в условиях пиковой нагрузки.

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

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

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

Как правило, вычислению приведенной стоимости (presentvalue) обычно посвящается целая глава в учебниках по финансовым вычислениям, и эта тема, безусловно, выходит далеко за рамки круга вопросов, обсуждаемых в этой книге. К счастью, в большинстве финансовых калькуляторов, а также в таких программах, как Microsoft Excel или Apple Numbers, уже имеются готовые функции, с помощью которых вы легко сможете выполнить данные расчеты.

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

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

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

На чем еще позволяет экономить облачная инфраструктура?

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

Экономия за счет использования облачной среды становится значительной, а иногда достигает и просто немыслимых уровней, если ваша среда динамична и между пиковыми нагрузками и средним уровнем нагрузки наблюдается существенная разница. Например, у моей компании есть один заказчик, чей пример может быть очень показательным. Обычно в течение целого года сайт этой компании посещает всего лишь несколько пользователей за день. Однако в конце квартала картина резко меняется и за 15 минут их сайт может посетить более 10 миллионов разных пользователей. Очевидно, что приобретение аппаратных средств для поддержания этих пиковых нагрузок -- это чудовищное расточительство (фактически с полной нагрузкой это оборудование будет работать всего лишь 1 час в году). Тем не менее, они не могут позволить себе снижения производительности даже на 1 час в году. Для них облачная инфраструктура будет идеальным решением, потому что большую часть времени они смогут работать с минимальным потреблением ресурсов, и мгновенно наращивать вычислительные мощности в те минуты, когда им необходимо поддерживать пиковые нагрузки.

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

Когда предприятие предоставляет клиентам некий сервис -- не важно, какой именно, облачный или традиционный на основе собственного центра обработки данных -- то эта компания, как правило, предоставляет клиентам соглашение об уровне сервиса (servicelevelagreement, SLA), где указываются ключевые параметры (уровни сервиса), которых клиент вправе ожидать от данного сервиса. Прежде, чем вы примете решение о переходе на облачные технологии, вам необходимо понять на концептуальном уровне, что представляют собой доступность (availability), надежность (reliability) и производительность (performance) облачных сервисов.

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

Доступность -- это показатель, который указывает, насколько часто может использоваться сервис в течение предопределенного периода времени. Например, если Web-сайт доступен широкой публике в течение 710 часов из 720-часового периода (1 месяц), то можно сказать, что в течение этого месяца доступность сервера составляла 98,6 %.

Хотя показатель 98,6 % на первый взгляд кажется очень хорошим, приемлемость этого значения в действительности сильно зависит от того, для какого приложения замеряется этот показатель, а иногда и от того, какие отдельные функции приложения были доступными. Например, если Googlespider не будет работать в течение 24 часов, но при этом вы все равно сможете выполнять поиск и получать результаты, сочтете ли вы, что "Google не работает"?

Большинство людей считают, что система обладает высокой доступностью, если объявленное ожидаемое значение показателя доступности составляет от 99,99 до 99,999 %. При доступности 99,999 % система может оказаться недоступной только 5 минут 15 секунд за год.

Когда о системе говорится, что она является системой высокой доступности, имеется в виду то, на что вы можете рассчитывать в будущем, а не то, что произошло в течение предыдущего года, который прошел удачно для вас. Например, то, что ваш Web-сайт, размещенный на старом сервере на базе процессора Intel 486, в течение прошлого года работал без перебоев, еще не значит, что вы имеете систему высокой доступности. Если вероятность отказа этого старого сервера в течение календарного года составляет примерно 40 %, у вас нет никакого основания считать его системой высокой доступности, несмотря на его производительность в течение прошлых лет.

Как оценить доступность вашей системы?

Большинство перебоев в работе сервисов представляют собой результат неполадок в работе оборудования. Эти перерывы в работе могут оказаться длительными, если администраторы сервиса неправильно диагностируют причину сбоя или допустят другие ошибки в устранении возникшей проблемы. Таким образом, для оценки ожидаемой доступности должны использоваться две переменные:

-вероятность возникновения сбоев или неполадок системы в течение оценочного периода;

-ожидаемое время простоя в случае возникновения сбоев и неполадок.

Ожидаемая доступность компонента выражается следующей математической формулой:

a = (p - (c Ч d)) / p. (1)

Здесь:

a -- ожидаемая доступность;

c -- вероятность (в %) отказа сервера в течение заданного периода;

d -- ожидаемое время простоя вследствие отказа сервера; p -- оцениваемый период.

Таким образом, если ваш старый компьютер на базе процессора i486 имеет вероятность отказа, которая составляет 40 %, и в этом случае вы предполагаете, что время простоя составит 24 часа, то его ожидаемая доступность составит:

(8760 - (40 % Ч 24)) / 8760, или 99,9 %. (2)

Показатель доступности 99,9 % выглядит довольно неплохо, особенно для старого компьютера на базе процессора i486, не так ли? В данном случае ситуация чрезмерно упрощена. На самом деле ваше кабельное или DSL- соединение не будет работать бесперебойно и никогда не будет разрываться. За 24 часа вы не успеете заменить сервер, сконфигурировать его и восстановить данные с резервной копии.