Выбор правильной модели применения облака

Поиск лучшей модели применения для интеграции новых служб и расширения коммерческих возможностей

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

Тина Абдолла, старший сертифицированный ИТ-архитектор, IBM

Tina AbdollahТина Абдолла (Tina Abdollah) — старший сертифицированный ИТ-архитектор IBM Global Business Services, ИТ-архитектор группы Open Group Distinguished Certified и член академии IBM. Обладает более чем 25-летним опытом работы с информационными системами в распределенных сетях. Уделяет особое внимание проектированию и реализации крупных комплексных ИТ-решений корпоративного класса с помощью разнообразных технологий и методов, таких как корпоративная архитектура, облачные вычисления, оптимизация бизнес-процессов и SOA/Web-сервисы.



Берни Михалик, ИТ-архитектор, IBM

author photoБерни Михалик (Bernie Michalik) обладает более чем 25-летним опытом проектирования, создания и реализации сложных ИТ-решений. Он выполнял широкий спектр задач: от руководства большой группой, работающей над созданием крупномасштабных инфраструктур, до индивидуальной разработки специализированного ПО для клиентов по всему миру. Имеет опыт работы с широким спектром методов и перспективных технологий.



03.12.2013

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

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

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

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

Цель этой статьи — помочь архитекторам облачных решений в выборе подходящей модели применения облака, которая позволит расширить коммерческие возможности и интегрировать существующие локальные системы с новыми службами, предлагаемыми провайдерами облачных услуг. Основной упор сделан на аспектах интеграции, которые используют модели применения для поддержки моделей облачных услуг (инфраструктура как услуга [IaaS], платформа как услуга [PaaS], ПО как услуга [SaaS] и бизнес-процесс как услуга) и типов облака (публичное, частное, гибридное, коллективное) в абстрактной форме для классификации предлагаемых облачных решений. Эти абстракции помогут вам выбрать подходящую модель применения на основе вашей бизнес-модели, необходимого уровня развития облака и требуемой технологии (такой как ПО, платформа и инструменты). При этом основная задача — помочь вам на одном из первых ключевых этапов пути к реализации или расширению облачного решения.

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

Знакомство с моделями применения облака

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

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

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

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

Описанные здесь модели применения облака основаны на первой группе характеристик и охватывают некоторые модели облачных услуг. Модели применения облака носят следующие названия:

  • первичное гибридное облако (PHC);
  • расширенное гибридное облако (EHC);
  • полное облако (FC);
  • расширенное полное облако (EFC).

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


Первичное гибридное облако (PHC)

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

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

Характеристики

Этой модели свойственна ограниченная интеграция с локальными компонентами; компоненты связаны слабо и не имеют двунаправленной синхронизации. Интеграция с другими облачными решениями отсутствует.

Топология

Принципиально модель первичного гибридного облака можно представить так, как показано на рисунке 1:

Рисунок 1. Топология первичного гибридного облака
Primary hybrid cloud topology

Интеграция между локальными компонентами (слева) и облачными компонентами (справа) ограничена. Логически такая структура выглядит примерно так, как показано на рисунке 2:

Рисунок 2. Логическая структура первичного гибридного облака
Primary Hybrid Cloud logical structure

Применимость

Внедрение этой модели имеет смысл в следующих ситуациях:

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

Основные сценарии использования

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

  • вы хотите запустить дополнительные процессы пакетной обработки, но вашим локальным системам не хватает ресурсов;
  • у вас есть проект, связанный с обработкой больших объемов данных, получаемых из Интернета, и вы хотите обрабатывать эти данные (например, составлять аналитические отчеты [BI]) с учетом сведений, полученных из локальных систем;
  • вы хотите разместить систему управления контентом в облаке, содержащем подгруппу ваших локальных систем управления контентом;
  • вам нужно протестировать новое приложение, работающее в операционной системе, которая имеется в облаке, но отсутствует у вас;
  • вы хотите предоставить доступ к локальным данным пользователям, находящимся за пределами вашей территории;
  • вы хотите предоставить дополнительные услуги (не входящие в сферу ваших основных услуг, например, услуги анализа данных), которые опираются на локальные системы, но не играют особой роли в вашей основной деятельности;
  • вам нужно передать некоторые функции, такие как сбор платежей или биллинг, провайдеру SaaS-услуг.

Факторы принятия решения

Факторы, определяющие необходимость применения этой модели:

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

Последствия

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

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

Расширенное гибридное облако (EHC)

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

Характеристики

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

Топология

Принципиально модель расширенного гибридного облака можно представить так, как показано на рисунке 3:

Рисунок 3. Топология расширенного гибридного облака
Extended hybrid cloud topology

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

Логически такая структура выглядит примерно так, как показано на рисунке 4:

Рисунок 4. Логическая структура расширенного гибридного облака
Extended hybrid cloud logical structure

Применимость

Внедрение этой модели имеет смысл в следующих ситуациях:

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

Основные сценарии использования

Как правило, использование модели расширенного гибридного облака обеспечивает удовлетворение следующих коммерческих требований:

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

Факторы принятия решения

Факторы, определяющие необходимость применения этой модели:

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

Последствия

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

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

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

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

Полное облако (FC)

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

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

Характеристики

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

Топология

Принципиально модель полного облака можно представить так, как показано на рисунке 5:

Рисунок 5. Топология полного облака
Full cloud topology

В этой модели отсутствует интеграция между локальными компонентами (слева) и облачными компонентами (справа). Вся интеграция выполняется внутри облака.

Логически такая структура выглядит примерно так, как показано на рисунке 6:

Рисунок 6. Логическая структура полного облака
Full cloud logical structure

Применимость

Внедрение этой модели имеет смысл в следующих ситуациях:

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

Основные сценарии использования

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

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

Факторы принятия решения

Факторы, определяющие необходимость применения этой модели:

  • потребность в исключении локальной ИТ-поддержки;
  • гибкость и эластичность облачной среды;
  • применение экономически эффективной модели, такой как PAYG;
  • сжатые сроки вывода продуктов на рынок;
  • поиск новых путей окупаемости инвестиций.

Последствия

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

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

Расширенное полное облако (EFC)

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

Характеристики

В этой модели применяется интеграция с одним или несколькими облачными решениями в других облачных средах. Интеграция с локальными ресурсами отсутствует.

Топология

Принципиально модель расширенного полного облака можно представить так, как показано на рисунке 7:

Рисунок 7. Топология расширенного полного облака
Extended full cloud topology

В этой модели присутствует интеграция между компонентами, находящимися в разных облачных средах. Логически такая структура выглядит примерно так, как показано на рисунке 8:

Рисунок 8. Логическая структура расширенного полного облака
Extended full cloud logical structure

Применимость

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

Основные сценарии использования

Как правило, использование модели расширенного полного облака позволяет удовлетворить следующие коммерческие требования:

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

Факторы принятия решения

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

  • потребность в исключении локальной ИТ-поддержки;
  • гибкость и эластичность облачной среды;
  • применение экономически эффективной модели, такой как PAYG;
  • сжатые сроки вывода ваших продуктов на рынок;
  • поиск новых путей окупаемости инвестиций.

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

Последствия

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

  • принятие открытых и отраслевых стандартов;
  • платформа интеграции, позволяющая осуществлять интеграцию и управление услугами;
  • поддержка системы аутентификации и авторизации с единимым входом в систему, такой как Federated Identity Manager;
  • управление работой в режиме коллективной аренды;
  • портал самообслуживания, например, Web-портал для клиентов и провайдеров;
  • унифицированные и общие платформы предоставления услуг;
  • стандарты, процессы и процедуры управления;
  • необходимость внедрения модели распределения прибыли;
  • функция тарификации и возврата платежей;
  • функция управления контрактами;
  • функция мониторинга и аудита;
  • автоматизация услуг;
  • управление исправлениями.

Заключение

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

Ресурсы

Научиться

Получить продукты и технологии

  • Испытайте продукты IBM самым удобным для себя способом: скачайте ознакомительную версию продукта, опробуйте продукт в Интернете, поработайте с продуктом в облачной среде или проведите несколько часов в SOA Sandbox, чтобы ознакомиться с эффективной реализацией сервис-ориентированной архитектуры.

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления
ArticleID=955661
ArticleTitle=Выбор правильной модели применения облака
publish-date=12032013