В реальной жизни вы можете пользоваться, например, таким рабочим сценарием:
- начиная с полуночи и до 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-инфра-структурой за счет экономии трудозатрат, но в некоторых ситуациях облако может обойтись даже дороже, чем управляемые сервисы, особенно если вам требуется среда, обладающая по-настоящему высокой отказоустойчивостью и высокой степенью доступности.