Антишаблоны готовности к работе в облаке

  • Статья

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

Антишаблон: предполагается, что выпущенные службы готовы для рабочей среды

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

  • Службы предварительной версии обычно не предоставляют соглашения об уровне обслуживания (SLA).
  • А новые службы зачастую не такие зрелые, как уже доступные облачные службы.

Пример: использование предварительной версии службы в рабочей среде

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

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

Предпочтительный результат: необходимо использовать предварительно утвержденные облачные службы в рабочей среде

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

Антишаблон: предполагается повышенная устойчивость и доступность

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

  • Повышенная устойчивость: восстановление после сбоя.
  • Доступность: работоспособное состояние без длительного простоя.

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

Пример: предполагается высокий уровень доступности

При запуске реализуется критически важное приложение в службах инфраструктуры как услуги (IaaS). Во время запуска разработчики изучили виртуальную машину с соглашением об уровне обслуживания с временем бесперебойной работы на уровне 99,9%. С целью сокращения затрат они использовали одну виртуальную машину и хранилище класса Premium.

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

  • Модели служб (платформа как услуга (PaaS) и программное обеспечение как услуга (SaaS)).
  • Технической архитектуры (группы доступности с балансировкой нагрузки и зоны доступности).

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

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

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

  • Одна виртуальная машина может иметь соглашение об уровне обслуживания с гарантированным временем бесперебойной работы 99,9%.
  • Две виртуальные машины, выполняющие одну и ту же рабочую нагрузку, обеспечивают соглашение об уровне обслуживания с временем бесперебойной работы от 99,95 до 99,99%.

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

Антишаблон: станьте поставщиком облачных услуг

Некоторые компании вменяют своим ИТ-отделам обязанности по поставке облачных услуг. Эти отделы становятся ответственными за эталонные архитектуры. Им также необходимо обеспечить работу IaaS и PaaS в бизнес-подразделениях. Поскольку этот вид деятельности не является основным для ИТ-отдела, предлагаемые услуги могут быть недостаточно удобными, устойчивыми, эффективными и безопасными.

Пример: предоставление монолитных управляемых облачных служб

ИТ-отдел компании создает облачный центр инноваций (CCoE), который выступает в качестве брокера между ИТ-отделом и другими подразделениями. Для обеспечения соответствия компании требованиям облачных вычислений, совет директоров возлагает на облачный центр инноваций задачу предоставления монолитных комплексных служб. Облачный центр инноваций настраивает внутренний облачный портал закупок для того, чтобы подразделения могли заказывать полностью управляемую облачную виртуальную машину в качестве службы. А ИТ-отдел контролирует доступ к этой платформе и ее использование, а также активно предотвращает использование преимуществ всего спектра служб, предоставляемых Azure, бизнес-подразделениями. Доступа к облачному порталу у бизнес-подразделений нет. Доступ к желаемому серверу можно получить только через Secure Shell (SSH) и протокол удаленного рабочего стола (RDP).

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

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

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

При внедрении облачных технологий ИТ-отдел получает опыт работы с облаком, начав с рабочих ИТ-нагрузок. Используя платформу Microsoft Cloud Adoption Framework для Azure, обозначьте первый проект внедрения.

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

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

Максимально используйте решения SaaS для ИТ-инструментов, таких как:

  • Репозитории кода.
  • Непрерывная интеграция и непрерывная поставка (CI/CD).
  • Системы совместной работы.

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

Дальнейшие действия