Прогноз погоды: Обсуждение миграции в облако

Источник: IBM

Эксперт в области облачных вычислений Дэйв Рассел дважды обсуждал в группе Google "Варианты использования облачных вычислений" аспекты и процессы при планировании добавления раздела "Миграция в облако" в постоянно модернизируемое техническое описание облачных вычислений. В ходе этих обсуждений были получены прекрасные комментарии по аспектам, которые необходимо учитывать при миграции в облако, описанным в документе Варианты использования облачных вычислений (EN). Вместо того, чтобы пытаться объяснить каждый из предложенных аспектов, имеет смысл вернуться на шаг назад и рассмотреть процесс возможной идентификации облачных сервисов.

Предварительные сведения

Ознакомьтесь с оригиналами обсуждений от 22 сентября и 25 августа, а также подключайтесь к группе и добавьте свое собственное мнение.

Новая серия статей "Прогноз погоды" преследует две цели:

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

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

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

22 сентября: предлагаемый итерационный процесс идентификации сервисов для облачных вычислений

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

Шаг 1: идентификация существующих или новых процессов, сервисов и данных в качестве кандидатов

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

Экономят деньги?
Повышают эластичность обработки меняющихся объемов данных?
Улучшают доступ/удовлетворенность потребителей?
Разгружают существующую информационную среду?
Консолидируют аналогичную работу для других предприятий внутри облака?
Другие аспекты.

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

Шаг 2: управление рисками для кандидатов

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

Примеры типов данных:

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

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

При определении уровня риска необходимо рассмотреть политики безопасности для данных. Также надо принять во внимание SLA, возможность реализации единого входа (single sign-on), доступность, восстановление после сбоев и т.д. (в оригинальном документе приводится список).

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

Шаг 3: измерение

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

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

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

25 августа: темы для обсуждения миграции в облако

Хочу поблагодарить всех участников обсуждения за отзывы. С момента представления списка количество потенциальных тем (и подтем) для обсуждения увеличилось с 8 до 17.

Тема 1. Источники рабочей нагрузки

Рассмотрите следующие возможные источники рабочей нагрузки:

Углубленный анализ данных.
Внутренние приложения, такие как расчет зарплаты.
Управление данными клиентов, например медицинскими данными.
Проверка идентичности и защита.
Статические (например, каталоги продуктов) и интерактивные (например, система приема заказов) Web-сайты.
Пакетная обработка (затратные по времени задачи, например, анализ базы генетических данных, делопроизводство, Hadoop-нагрузки и т.д.).

Тема 2. Типы облаков

При выборе типов облаков учитывайте:

Соответствие требованиям необходимого уровня защиты.
Отображение требований к облаку в плане безопасности, готовности, доступности и т.д.

Тема 3. Вопросы соответствия нормативным документам

В плане соответствия нормативным документам примите во внимание:

Законы HIPAA, Сарбейнса-Оксли, GLBA, Patriot ACT (это лишь некоторые примеры; я уверен, что в других странах найдутся и другие).
PIV-I, национальные идентификационные коды и т.д.
Стандарты Industry Standards Organizations и т.д.
Отраслевые требования, устанавливаемые отраслевыми организациями, такими как agxml.org.
Закон PCI для финансовых институтов и его аналоги в других странах.
Соответствие размещения данных требованиям правительства.

Тема 4. Использование облака

Рассмотрите следующие способы использования облака:

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

Тема 5. Готовность, надежность

С точки зрения готовности и надежности облачной среды необходимо учитывать:

Соответствие соглашению об уровне обслуживания (см. раздел SLA в V4 документа).

Тема 6. Переносимость

С точки зрения переносимости приложений примите во внимание:

Переносимость из ИТ-среды к поставщику облака.
Переносимость от поставщика облака А к поставщику облака Б.
Переносимость от поставщика облака в ИТ-среду.
Один из участников группы выдвинул тезис, что переносимость может быть не важна.

Тема 7. Производительность и рабочая нагрузка

В плане объемов рабочей нагрузки и проблем производительности примите во внимание:

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

Тема 8. Восстановление после сбоев

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

Является ли облако альтернативой восстановлению после сбоев?
Что делать, если у поставщика облака случится сбой?

Тема 9. Режимы миграции

С точки зрения режимов миграции рассмотрите следующие вопросы:

Доступность данных (необходимо учитывать проблемы синхронизации данных и доверия между сайтами).

Тема 10. Разработка и тестирование сервисов

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

Использование облачной среды для разгрузки основного сайта.

Тема 11. Бизнес-модели и бизнес-сценарии

Для выбора бизнес-сценариев рассмотрите следующие вопросы:

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

Тема 12. Аутентификация, авторизация, аудит

По теме аутентификации, авторизации и выполнения аудита приложения рассмотрите следующие вопросы:

Вопрос федерированной идентификации: что лучше - SAML или OpenID?

Тема 13. Конфиденциальность

Вопросы конфиденциальности.

Тема 14. Безопасность

С точки зрения безопасности рассмотрите:

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

Тема 15. SLA

С точки зрения соглашений об уровне обслуживания рассмотрите:

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

Тема 16. Идентификация

По вопросам идентификации при аутентификации на облачных ресурсах, рассмотрите следующие вопросы:

Обеспечение доверенной идентификации.
Связь с переносимостью.

Тема 17. Миграция данных

Применительно к руководству рассмотрите следующие вопросы миграции данных:

Формат хранения данных.
Имеется ли привязка пользователя к формату данных поставщика?
Есть ли возможность миграции к другому поставщику?
Доступна ли какая-либо поддержка миграции, если пользователь примет решение о переходе к другому поставщику?

Следующий шаг: оценка

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

Заключение

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

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

К базовому профилю - за представлением Linked Data.

Удобное встраивание RESTful API в проект.

Как предварительно заполнить поля создания OSLC-ресурса в IBM Rational Change.

Критическая уязвимость в сервисе SAP Dispatcher доступна через интернет.

Главная » Xml