Сравнение затрат облачных вычислений

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

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

Таблица 1.3. Сравнительный анализ затрат на организацию IT-инфраструктур различных типов

Внутренняя инфраструктура IT

Управляемый сервис

Облачная инфраструктура

Капитальные затраты

$40 000

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

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

Таблица 1.3. Сравнительный анализ затрат на организацию IT-инфраструктур различных типов

Внутренняя инфраструктура IT

Управляемый сервис

Облачная инфраструктура

Капитальные затраты

$40 000

$0

$0

Затраты на установку

$10 000

$5000

$1000

Ежемесячная плата за обслуживание

$0

$4000

$2400

Ежемесячная зарплата персоналу

$3200

$0

$1000

Чистая себестоимость за три года

$149 000

$129 000

$106 000

Данные табл. 1.3 приведены с учетом следующих предположений1.

± Используются совершенно стандартные серверные системы 1u1, например, такие как Dell 2950 или элитные экземпляры Amazon.

1 В главе 3 о методике расчетов будет рассказано чуть более подробно. — Прим. перев.

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

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

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

± Чистая себестоимость деноминирована в современные доллары (иными словами, не следует беспокоиться об инфляции).

± В расчеты заложены проценты на капитал 10 % (проценты на капитал — это то, что мог бы принести вам вложенный капитал, если бы вы не потратили его на покупку сервера и установочные затраты — в основном, это значение складывается из процентной ставки плюс издержки неиспользованных возможностей).

± Использование инструментов управления облачной инфраструктурой от сторонних поставщиков, таких как enStratus или RightScale, включено в затраты на облачные вычисления.

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

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

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

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

1 Серверы 19" монтируются в специально предназначенные для этого шкафы и стойки. Высота таких серверов измеряется в юнитах (1 unit = 1u = 43,5 мм). Минимальная высота для сервера — 1U (юнит), максимальная — 8U. Подробнее см. http://en.wikipedia.org/wiki/Rack_unit, http://tinyurl.com/325zrnx Прим. перев.

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

Кроме того, некоторые провайдеры, предоставляющие сервис облачных вычислений (например, GoGrid), бесплатно включают аппаратный балансировщик нагрузки, что делает всю дискуссию о том, какой балансировщик нагрузки следует предпочесть (программный или аппаратный) попросту неактуальной.  Далее, Amazon планирует начать предоставление собственного решения по балансировке нагрузки в 2009 г1. Тем не менее, если вы не доверяете моим рассуждениям по сравнению аппаратных балансировщиков нагрузки с программными, вот стоимость использования программных балансировщиков для всех вариантов инфраструктуры: $134K для внутренней IT-инфраструктуры, $92K — для среды, управляемой сторонним сервис-провайдером, и $106K — для облачной инфраструктуры.

Нижняя граница

Если мы отбросим пониженные затраты, то управляемый сервис от правильно выбранного удаленного сервис-провайдера и облачные вычисления всегда будут финансово более привлекательны, чем поддержание собственной инфраструктуры IT. По всем финансовым показателям — капитальным затратам, совокупной стоимости владения (Total Cost of Ownership, TCO), сопутствующим затратам — внутренняя инфраструктура IT всегда оказывается аутсайдером.

По мере того, как ваша инфраструктура усложняется, определение того, какое решение будет более экономичным — удаленно управляемая среда, смешанная инфраструктура или облачные вычисления, становится все более сложным.

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

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

1 Фактически к моменту подготовки русского издания этой книги данный сервис уже предоставляется, см. http://blog.rightscale.com/2009/05/18/amazon-load-balancing-monitoring-auto-scaling/. — Прим. перев.

УРКХАРТ О ПРЕПЯТСТВИЯХ ДЛЯ ОТКАЗА ОТ СОБСТВЕННОЙ ИНФРАСТРУКТУРЫ IT

В ноябре 2008 года Джеймс Уркхарт (James Urquhart) и я начали дискуссию в Twitter1, где обсуждали вопрос совокупной стоимости владения облачной инфраструктурой (Джеймс является рыночным аналитиком, определяющим стратегию Data Center 3 для Cisco Systems и членом сообщества блогеров CNET). В ходе этой дискуссии мы поняли, что я смотрел на проблему с точки зрения того, как начать новый бизнес "с нуля", в то время как Джеймс имел другой взгляд на проблему: с позиций реальности и входя в положение организации, которая уже сделала крупные капиталовложения в существующую инфраструктуру IT. В этом примечании приводится краткое обобщение результатов нашей дискуссии, которые Джеймс собрал вместе и кратко пересказал специально для этой книги.

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

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

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

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

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

    приложения, при работе которых от случая к случаю или периодически возникают пиковые нагрузки. Например, к такому классу приложений относятся приложения для расчета налогов или системы расчета прибылей перед длительными праздниками. Облачная обработка данных может обеспечить поддержку работы приложения, динамически предоставив дополнительные мощности в момент пиковых нагрузок, с помощью технологии, которая называется "cloudbursting"2;

1 http://blog.jamesurquhart.com/2008/12/enterprise-barrier-to-exit-to-cloud.html.

2 Cloud bursting (англ. "ливень, проливной дождь") — в облачных вычислениях этот термин может использоваться двояко, причем значение его может быть как положительным, так и отрицательным. В отрицательном смысле это означает крах всей облачной среды в момент пиковой нагрузки вследствие неспособности сбалансировать нагрузку между различными компаниями, пользующимися облаком.

Описание такой ситуации см. здесь: http://www.roughtype.com/archives/2007/04/intuits_cloudbu.php. В положительном же смысле этот термин обозначает технологию динамического развертывания ПО, которое работает, используя внутренние вычислительные ресурсы организации, в общественную облачную инфраструктуру в момент возникновения пиковых нагрузок. Источник: http://sites.google.com/site/cloudcomputingwiki/Home/cloud-computing-vocabulary. — Прим. перев.

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

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

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

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

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

Таблица 1.3. Сравнительный анализ затрат на организацию IT-инфраструктур различных типов

Внутренняя инфраструктура IT

Управляемый сервис

Облачная инфраструктура

Капитальные затраты

$40 000

$0

$0

Затраты на установку

$10 000

$5000

$1000

Ежемесячная плата за обслуживание

$0

$4000

$2400

Ежемесячная зарплата персоналу

$3200

$0

$1000

Чистая себестоимость за три года

$149 000

$129 000

$106 000

Данные табл. 1.3 приведены с учетом следующих предположений1.

± Используются совершенно стандартные серверные системы 1u1, например, такие как Dell 2950 или элитные экземпляры Amazon.

1 В главе 3 о методике расчетов будет рассказано чуть более подробно. — Прим. перев.

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

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

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

± Чистая себестоимость деноминирована в современные доллары (иными словами, не следует беспокоиться об инфляции).

± В расчеты заложены проценты на капитал 10 % (проценты на капитал — это то, что мог бы принести вам вложенный капитал, если бы вы не потратили его на покупку сервера и установочные затраты — в основном, это значение складывается из процентной ставки плюс издержки неиспользованных возможностей).

± Использование инструментов управления облачной инфраструктурой от сторонних поставщиков, таких как enStratus или RightScale, включено в затраты на облачные вычисления.

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

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

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

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

1 Серверы 19" монтируются в специально предназначенные для этого шкафы и стойки. Высота таких серверов измеряется в юнитах (1 unit = 1u = 43,5 мм). Минимальная высота для сервера — 1U (юнит), максимальная — 8U. Подробнее см. http://en.wikipedia.org/wiki/Rack_unit, http://tinyurl.com/325zrnx Прим. перев.

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

Кроме того, некоторые провайдеры, предоставляющие сервис облачных вычислений (например, GoGrid), бесплатно включают аппаратный балансировщик нагрузки, что делает всю дискуссию о том, какой балансировщик нагрузки следует предпочесть (программный или аппаратный) попросту неактуальной.  Далее, Amazon планирует начать предоставление собственного решения по балансировке нагрузки в 2009 г1. Тем не менее, если вы не доверяете моим рассуждениям по сравнению аппаратных балансировщиков нагрузки с программными, вот стоимость использования программных балансировщиков для всех вариантов инфраструктуры: $134K для внутренней IT-инфраструктуры, $92K — для среды, управляемой сторонним сервис-провайдером, и $106K — для облачной инфраструктуры.

Нижняя граница

Если мы отбросим пониженные затраты, то управляемый сервис от правильно выбранного удаленного сервис-провайдера и облачные вычисления всегда будут финансово более привлекательны, чем поддержание собственной инфраструктуры IT. По всем финансовым показателям — капитальным затратам, совокупной стоимости владения (Total Cost of Ownership, TCO), сопутствующим затратам — внутренняя инфраструктура IT всегда оказывается аутсайдером.

По мере того, как ваша инфраструктура усложняется, определение того, какое решение будет более экономичным — удаленно управляемая среда, смешанная инфраструктура или облачные вычисления, становится все более сложным.

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

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

1 Фактически к моменту подготовки русского издания этой книги данный сервис уже предоставляется, см. http://blog.rightscale.com/2009/05/18/amazon-load-balancing-monitoring-auto-scaling/. — Прим. перев.

УРКХАРТ О ПРЕПЯТСТВИЯХ ДЛЯ ОТКАЗА ОТ СОБСТВЕННОЙ ИНФРАСТРУКТУРЫ IT

В ноябре 2008 года Джеймс Уркхарт (James Urquhart) и я начали дискуссию в Twitter1, где обсуждали вопрос совокупной стоимости владения облачной инфраструктурой (Джеймс является рыночным аналитиком, определяющим стратегию Data Center 3 для Cisco Systems и членом сообщества блогеров CNET). В ходе этой дискуссии мы поняли, что я смотрел на проблему с точки зрения того, как начать новый бизнес "с нуля", в то время как Джеймс имел другой взгляд на проблему: с позиций реальности и входя в положение организации, которая уже сделала крупные капиталовложения в существующую инфраструктуру IT. В этом примечании приводится краткое обобщение результатов нашей дискуссии, которые Джеймс собрал вместе и кратко пересказал специально для этой книги.

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

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

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

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

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

    приложения, при работе которых от случая к случаю или периодически возникают пиковые нагрузки. Например, к такому классу приложений относятся приложения для расчета налогов или системы расчета прибылей перед длительными праздниками. Облачная обработка данных может обеспечить поддержку работы приложения, динамически предоставив дополнительные мощности в момент пиковых нагрузок, с помощью технологии, которая называется "cloudbursting"2;

1 http://blog.jamesurquhart.com/2008/12/enterprise-barrier-to-exit-to-cloud.html.

2 Cloud bursting (англ. "ливень, проливной дождь") — в облачных вычислениях этот термин может использоваться двояко, причем значение его может быть как положительным, так и отрицательным. В отрицательном смысле это означает крах всей облачной среды в момент пиковой нагрузки вследствие неспособности сбалансировать нагрузку между различными компаниями, пользующимися облаком.

Описание такой ситуации см. здесь: http://www.roughtype.com/archives/2007/04/intuits_cloudbu.php. В положительном же смысле этот термин обозначает технологию динамического развертывания ПО, которое работает, используя внутренние вычислительные ресурсы организации, в общественную облачную инфраструктуру в момент возникновения пиковых нагрузок. Источник: http://sites.google.com/site/cloudcomputingwiki/Home/cloud-computing-vocabulary. — Прим. перев.

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

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

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

Затраты на установку

$10 000

$5000

$1000

Ежемесячная плата за обслуживание

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

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

Таблица 1.3. Сравнительный анализ затрат на организацию IT-инфраструктур различных типов

Внутренняя инфраструктура IT

Управляемый сервис

Облачная инфраструктура

Капитальные затраты

$40 000

$0

$0

Затраты на установку

$10 000

$5000

$1000

Ежемесячная плата за обслуживание

$0

$4000

$2400

Ежемесячная зарплата персоналу

$3200

$0

$1000

Чистая себестоимость за три года

$149 000

$129 000

$106 000

Данные табл. 1.3 приведены с учетом следующих предположений1.

± Используются совершенно стандартные серверные системы 1u1, например, такие как Dell 2950 или элитные экземпляры Amazon.

1 В главе 3 о методике расчетов будет рассказано чуть более подробно. — Прим. перев.

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

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

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

± Чистая себестоимость деноминирована в современные доллары (иными словами, не следует беспокоиться об инфляции).

± В расчеты заложены проценты на капитал 10 % (проценты на капитал — это то, что мог бы принести вам вложенный капитал, если бы вы не потратили его на покупку сервера и установочные затраты — в основном, это значение складывается из процентной ставки плюс издержки неиспользованных возможностей).

± Использование инструментов управления облачной инфраструктурой от сторонних поставщиков, таких как enStratus или RightScale, включено в затраты на облачные вычисления.

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

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

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

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

1 Серверы 19" монтируются в специально предназначенные для этого шкафы и стойки. Высота таких серверов измеряется в юнитах (1 unit = 1u = 43,5 мм). Минимальная высота для сервера — 1U (юнит), максимальная — 8U. Подробнее см. http://en.wikipedia.org/wiki/Rack_unit, http://tinyurl.com/325zrnx Прим. перев.

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

Кроме того, некоторые провайдеры, предоставляющие сервис облачных вычислений (например, GoGrid), бесплатно включают аппаратный балансировщик нагрузки, что делает всю дискуссию о том, какой балансировщик нагрузки следует предпочесть (программный или аппаратный) попросту неактуальной.  Далее, Amazon планирует начать предоставление собственного решения по балансировке нагрузки в 2009 г1. Тем не менее, если вы не доверяете моим рассуждениям по сравнению аппаратных балансировщиков нагрузки с программными, вот стоимость использования программных балансировщиков для всех вариантов инфраструктуры: $134K для внутренней IT-инфраструктуры, $92K — для среды, управляемой сторонним сервис-провайдером, и $106K — для облачной инфраструктуры.

Нижняя граница

Если мы отбросим пониженные затраты, то управляемый сервис от правильно выбранного удаленного сервис-провайдера и облачные вычисления всегда будут финансово более привлекательны, чем поддержание собственной инфраструктуры IT. По всем финансовым показателям — капитальным затратам, совокупной стоимости владения (Total Cost of Ownership, TCO), сопутствующим затратам — внутренняя инфраструктура IT всегда оказывается аутсайдером.

По мере того, как ваша инфраструктура усложняется, определение того, какое решение будет более экономичным — удаленно управляемая среда, смешанная инфраструктура или облачные вычисления, становится все более сложным.

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

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

1 Фактически к моменту подготовки русского издания этой книги данный сервис уже предоставляется, см. http://blog.rightscale.com/2009/05/18/amazon-load-balancing-monitoring-auto-scaling/. — Прим. перев.

УРКХАРТ О ПРЕПЯТСТВИЯХ ДЛЯ ОТКАЗА ОТ СОБСТВЕННОЙ ИНФРАСТРУКТУРЫ IT

В ноябре 2008 года Джеймс Уркхарт (James Urquhart) и я начали дискуссию в Twitter1, где обсуждали вопрос совокупной стоимости владения облачной инфраструктурой (Джеймс является рыночным аналитиком, определяющим стратегию Data Center 3 для Cisco Systems и членом сообщества блогеров CNET). В ходе этой дискуссии мы поняли, что я смотрел на проблему с точки зрения того, как начать новый бизнес "с нуля", в то время как Джеймс имел другой взгляд на проблему: с позиций реальности и входя в положение организации, которая уже сделала крупные капиталовложения в существующую инфраструктуру IT. В этом примечании приводится краткое обобщение результатов нашей дискуссии, которые Джеймс собрал вместе и кратко пересказал специально для этой книги.

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

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

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

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

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

    приложения, при работе которых от случая к случаю или периодически возникают пиковые нагрузки. Например, к такому классу приложений относятся приложения для расчета налогов или системы расчета прибылей перед длительными праздниками. Облачная обработка данных может обеспечить поддержку работы приложения, динамически предоставив дополнительные мощности в момент пиковых нагрузок, с помощью технологии, которая называется "cloudbursting"2;

1 http://blog.jamesurquhart.com/2008/12/enterprise-barrier-to-exit-to-cloud.html.

2 Cloud bursting (англ. "ливень, проливной дождь") — в облачных вычислениях этот термин может использоваться двояко, причем значение его может быть как положительным, так и отрицательным. В отрицательном смысле это означает крах всей облачной среды в момент пиковой нагрузки вследствие неспособности сбалансировать нагрузку между различными компаниями, пользующимися облаком.

Описание такой ситуации см. здесь: http://www.roughtype.com/archives/2007/04/intuits_cloudbu.php. В положительном же смысле этот термин обозначает технологию динамического развертывания ПО, которое работает, используя внутренние вычислительные ресурсы организации, в общественную облачную инфраструктуру в момент возникновения пиковых нагрузок. Источник: http://sites.google.com/site/cloudcomputingwiki/Home/cloud-computing-vocabulary. — Прим. перев.

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

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

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

$4000

$2400

Ежемесячная зарплата персоналу

$3200

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

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

Таблица 1.3. Сравнительный анализ затрат на организацию IT-инфраструктур различных типов

Внутренняя инфраструктура IT

Управляемый сервис

Облачная инфраструктура

Капитальные затраты

$40 000

$0

$0

Затраты на установку

$10 000

$5000

$1000

Ежемесячная плата за обслуживание

$0

$4000

$2400

Ежемесячная зарплата персоналу

$3200

$0

$1000

Чистая себестоимость за три года

$149 000

$129 000

$106 000

Данные табл. 1.3 приведены с учетом следующих предположений1.

± Используются совершенно стандартные серверные системы 1u1, например, такие как Dell 2950 или элитные экземпляры Amazon.

1 В главе 3 о методике расчетов будет рассказано чуть более подробно. — Прим. перев.

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

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

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

± Чистая себестоимость деноминирована в современные доллары (иными словами, не следует беспокоиться об инфляции).

± В расчеты заложены проценты на капитал 10 % (проценты на капитал — это то, что мог бы принести вам вложенный капитал, если бы вы не потратили его на покупку сервера и установочные затраты — в основном, это значение складывается из процентной ставки плюс издержки неиспользованных возможностей).

± Использование инструментов управления облачной инфраструктурой от сторонних поставщиков, таких как enStratus или RightScale, включено в затраты на облачные вычисления.

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

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

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

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

1 Серверы 19" монтируются в специально предназначенные для этого шкафы и стойки. Высота таких серверов измеряется в юнитах (1 unit = 1u = 43,5 мм). Минимальная высота для сервера — 1U (юнит), максимальная — 8U. Подробнее см. http://en.wikipedia.org/wiki/Rack_unit, http://tinyurl.com/325zrnx Прим. перев.

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

Кроме того, некоторые провайдеры, предоставляющие сервис облачных вычислений (например, GoGrid), бесплатно включают аппаратный балансировщик нагрузки, что делает всю дискуссию о том, какой балансировщик нагрузки следует предпочесть (программный или аппаратный) попросту неактуальной.  Далее, Amazon планирует начать предоставление собственного решения по балансировке нагрузки в 2009 г1. Тем не менее, если вы не доверяете моим рассуждениям по сравнению аппаратных балансировщиков нагрузки с программными, вот стоимость использования программных балансировщиков для всех вариантов инфраструктуры: $134K для внутренней IT-инфраструктуры, $92K — для среды, управляемой сторонним сервис-провайдером, и $106K — для облачной инфраструктуры.

Нижняя граница

Если мы отбросим пониженные затраты, то управляемый сервис от правильно выбранного удаленного сервис-провайдера и облачные вычисления всегда будут финансово более привлекательны, чем поддержание собственной инфраструктуры IT. По всем финансовым показателям — капитальным затратам, совокупной стоимости владения (Total Cost of Ownership, TCO), сопутствующим затратам — внутренняя инфраструктура IT всегда оказывается аутсайдером.

По мере того, как ваша инфраструктура усложняется, определение того, какое решение будет более экономичным — удаленно управляемая среда, смешанная инфраструктура или облачные вычисления, становится все более сложным.

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

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

1 Фактически к моменту подготовки русского издания этой книги данный сервис уже предоставляется, см. http://blog.rightscale.com/2009/05/18/amazon-load-balancing-monitoring-auto-scaling/. — Прим. перев.

УРКХАРТ О ПРЕПЯТСТВИЯХ ДЛЯ ОТКАЗА ОТ СОБСТВЕННОЙ ИНФРАСТРУКТУРЫ IT

В ноябре 2008 года Джеймс Уркхарт (James Urquhart) и я начали дискуссию в Twitter1, где обсуждали вопрос совокупной стоимости владения облачной инфраструктурой (Джеймс является рыночным аналитиком, определяющим стратегию Data Center 3 для Cisco Systems и членом сообщества блогеров CNET). В ходе этой дискуссии мы поняли, что я смотрел на проблему с точки зрения того, как начать новый бизнес "с нуля", в то время как Джеймс имел другой взгляд на проблему: с позиций реальности и входя в положение организации, которая уже сделала крупные капиталовложения в существующую инфраструктуру IT. В этом примечании приводится краткое обобщение результатов нашей дискуссии, которые Джеймс собрал вместе и кратко пересказал специально для этой книги.

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

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

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

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

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

    приложения, при работе которых от случая к случаю или периодически возникают пиковые нагрузки. Например, к такому классу приложений относятся приложения для расчета налогов или системы расчета прибылей перед длительными праздниками. Облачная обработка данных может обеспечить поддержку работы приложения, динамически предоставив дополнительные мощности в момент пиковых нагрузок, с помощью технологии, которая называется "cloudbursting"2;

1 http://blog.jamesurquhart.com/2008/12/enterprise-barrier-to-exit-to-cloud.html.

2 Cloud bursting (англ. "ливень, проливной дождь") — в облачных вычислениях этот термин может использоваться двояко, причем значение его может быть как положительным, так и отрицательным. В отрицательном смысле это означает крах всей облачной среды в момент пиковой нагрузки вследствие неспособности сбалансировать нагрузку между различными компаниями, пользующимися облаком.

Описание такой ситуации см. здесь: http://www.roughtype.com/archives/2007/04/intuits_cloudbu.php. В положительном же смысле этот термин обозначает технологию динамического развертывания ПО, которое работает, используя внутренние вычислительные ресурсы организации, в общественную облачную инфраструктуру в момент возникновения пиковых нагрузок. Источник: http://sites.google.com/site/cloudcomputingwiki/Home/cloud-computing-vocabulary. — Прим. перев.

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

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

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

$1000

Чистая себестоимость за три года

$149 000

$129 000

$106 000

Данные табл. 1.3 приведены с учетом следующих предположений1.

± Используются совершенно стандартные серверные системы 1u1, например, такие как Dell 2950 или элитные экземпляры Amazon.

1 В главе 3 о методике расчетов будет рассказано чуть более подробно. — Прим. перев.

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

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

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

± Чистая себестоимость деноминирована в современные доллары (иными словами, не следует беспокоиться об инфляции).

± В расчеты заложены проценты на капитал 10 % (проценты на капитал — это то, что мог бы принести вам вложенный капитал, если бы вы не потратили его на покупку сервера и установочные затраты — в основном, это значение складывается из процентной ставки плюс издержки неиспользованных возможностей).

± Использование инструментов управления облачной инфраструктурой от сторонних поставщиков, таких как enStratus или RightScale, включено в затраты на облачные вычисления.

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

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

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

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

1 Серверы 19" монтируются в специально предназначенные для этого шкафы и стойки. Высота таких серверов измеряется в юнитах (1 unit = 1u = 43,5 мм). Минимальная высота для сервера — 1U (юнит), максимальная — 8U. Подробнее см. http://en.wikipedia.org/wiki/Rack_unit, http://tinyurl.com/325zrnx Прим. перев.

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

Кроме того, некоторые провайдеры, предоставляющие сервис облачных вычислений (например, GoGrid), бесплатно включают аппаратный балансировщик нагрузки, что делает всю дискуссию о том, какой балансировщик нагрузки следует предпочесть (программный или аппаратный) попросту неактуальной.  Далее, Amazon планирует начать предоставление собственного решения по балансировке нагрузки в 2009 г1. Тем не менее, если вы не доверяете моим рассуждениям по сравнению аппаратных балансировщиков нагрузки с программными, вот стоимость использования программных балансировщиков для всех вариантов инфраструктуры: $134K для внутренней IT-инфраструктуры, $92K — для среды, управляемой сторонним сервис-провайдером, и $106K — для облачной инфраструктуры.

Нижняя граница

Если мы отбросим пониженные затраты, то управляемый сервис от правильно выбранного удаленного сервис-провайдера и облачные вычисления всегда будут финансово более привлекательны, чем поддержание собственной инфраструктуры IT. По всем финансовым показателям — капитальным затратам, совокупной стоимости владения (Total Cost of Ownership, TCO), сопутствующим затратам — внутренняя инфраструктура IT всегда оказывается аутсайдером.

По мере того, как ваша инфраструктура усложняется, определение того, какое решение будет более экономичным — удаленно управляемая среда, смешанная инфраструктура или облачные вычисления, становится все более сложным.

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

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

1 Фактически к моменту подготовки русского издания этой книги данный сервис уже предоставляется, см. http://blog.rightscale.com/2009/05/18/amazon-load-balancing-monitoring-auto-scaling/. — Прим. перев.

УРКХАРТ О ПРЕПЯТСТВИЯХ ДЛЯ ОТКАЗА ОТ СОБСТВЕННОЙ ИНФРАСТРУКТУРЫ IT

В ноябре 2008 года Джеймс Уркхарт (James Urquhart) и я начали дискуссию в Twitter1, где обсуждали вопрос совокупной стоимости владения облачной инфраструктурой (Джеймс является рыночным аналитиком, определяющим стратегию Data Center 3 для Cisco Systems и членом сообщества блогеров CNET). В ходе этой дискуссии мы поняли, что я смотрел на проблему с точки зрения того, как начать новый бизнес "с нуля", в то время как Джеймс имел другой взгляд на проблему: с позиций реальности и входя в положение организации, которая уже сделала крупные капиталовложения в существующую инфраструктуру IT. В этом примечании приводится краткое обобщение результатов нашей дискуссии, которые Джеймс собрал вместе и кратко пересказал специально для этой книги.

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

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

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

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

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

    приложения, при работе которых от случая к случаю или периодически возникают пиковые нагрузки. Например, к такому классу приложений относятся приложения для расчета налогов или системы расчета прибылей перед длительными праздниками. Облачная обработка данных может обеспечить поддержку работы приложения, динамически предоставив дополнительные мощности в момент пиковых нагрузок, с помощью технологии, которая называется "cloudbursting"2;

1 http://blog.jamesurquhart.com/2008/12/enterprise-barrier-to-exit-to-cloud.html.

2 Cloud bursting (англ. "ливень, проливной дождь") — в облачных вычислениях этот термин может использоваться двояко, причем значение его может быть как положительным, так и отрицательным. В отрицательном смысле это означает крах всей облачной среды в момент пиковой нагрузки вследствие неспособности сбалансировать нагрузку между различными компаниями, пользующимися облаком.

Описание такой ситуации см. здесь: http://www.roughtype.com/archives/2007/04/intuits_cloudbu.php. В положительном же смысле этот термин обозначает технологию динамического развертывания ПО, которое работает, используя внутренние вычислительные ресурсы организации, в общественную облачную инфраструктуру в момент возникновения пиковых нагрузок. Источник: http://sites.google.com/site/cloudcomputingwiki/Home/cloud-computing-vocabulary. — Прим. перев.

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

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

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете промотать до конца и оставить ответ. Pinging в настоящее время не допускается.

1 комментарий »

 
 

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100