Планирование для современных платформ приложений

  • Статья

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

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

Цифровые активы

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

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

Внимание!

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

Предупреждение

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

Выявление потенциальных рабочих нагрузок

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

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

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

Документирование потенциальных рабочих нагрузок

Примечание

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

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

Входные бизнес-данные

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

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

Технические входные данные

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

Рекомендации по размещению:

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

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

Рекомендации по операциям:

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

  • Основная облачная платформа: организации должны определить основную облачную платформу для предоставления инструментов управления операциями. В некоторых организациях может быть несколько основных облачных платформ для управления разными типами операций. Какой должна быть основная облачная платформа для выполнения этой рабочей нагрузки?
  • Дополнительные операционные платформы: будет ли эта рабочая нагрузка также управляться какими-либо дополнительными операционными платформами?
  • Требования к размещению в облаке: требуется ли для этой рабочей нагрузки особая стратегия размещения в облаке? Общедоступное облако, частное облако или переносимость в облаке
  • Стандартизированная платформа оркестрации: если у компании есть стандартное решение для оркестрации контейнеров, укажите название стандартной платформы, которую следует рассмотреть. Примеры: служба Azure Kubernetes (AKS), модуль AKS или Kubernetes.
  • Рекомендации по настраиваемой оркестрации: требуется ли нестандартная платформа для оркестрации контейнеров? Если да, то объясните это требование.
  • Стандартизованные операции на узлах: предполагается, что рабочие нагрузки не являются вредоносными и могут размещаться в общих контейнерах, поддерживаемых стандартизованными операциями на узлах. Совместима ли эта рабочая нагрузка с этим подходом?
  • Рекомендации относительно настраиваемых операций на узлах: если рабочая нагрузка не совместима со стандартизированными операциями, какие конкретные требования следует учитывать при разработке практики операций на узлах для этой рабочей нагрузки?

Рекомендации по приложениям:

рекомендации по разработке и развитию приложения в будущем.

  • Среда выполнения "платформа как услуга" (PaaS): поставщики общедоступных облачных служб создают согласованные среды выполнения приложений, часто называемые предложениями "платформа как услуга" (PaaS). В Azure среда выполнения PaaS предоставляется Службой приложений Azure. Может ли это приложение работать в среде выполнения PaaS? Какая среда выполнения является наиболее совместимой?
  • Стандартизированная среда выполнения: если приложение несовместимо со средой выполнения PaaS, предоставляет ли организация стандартизированную среду выполнения? В какой среде выполнения будет создана эта рабочая нагрузка?
  • Рекомендации по настраиваемой среде выполнения: какие конкретные рекомендации потребуют настраиваемой среды выполнения для этой рабочей нагрузки?
  • Ограничения среды выполнения: существуют ли какие-либо ограничения, налагаемые на приложение выбранной средой выполнения?
  • Зависимости приложений: зависит ли эта рабочая нагрузка от каких-либо существующих систем, находящихся в определенном расположении (общедоступном или частном)? Примеры включают ERP-системы, такие как SAP, работающие в определенном решении.
  • Притяжение данных: зависит ли эта рабочая нагрузка от источника данных, который находится в определенном расположении (общедоступном или частном)? Примеры могут включать зависимость от данных в SAP или других централизованных источниках данных.
  • Рекомендации по утверждению: утверждены ли рекомендации по настраиваемым операциям для использования на вашей облачной платформе? Какие утвержденные службы следует включить в развертывание?

Рекомендации по исходным контейнерам

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

Решения PaaS для стандартизированных сред выполнения, оркестрации и операций

Некоторые рабочие нагрузки являются строго автономными и не всегда имеют преимущества от дополнительных элементов управления и требований к инфраструктуре, которые поставляются с такой крупной платформой, как Kubernetes. Тот факт, что ваша рабочая нагрузка является контейнеризованной, не означает, что ее необходимо развернуть в Kubernetes. Azure предоставляет различные решения для выполнения рабочих нагрузок в рамках вашего портфеля, которые не требуют уровня управления и инфраструктуры, необходимых для AKS. Каждое из следующих решений будет применять этот подход для планирования:

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

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

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

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

Настраиваемая оркестрация, среды выполнения и операции в общедоступном облаке

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

  • Azure Red Hat OpenShift
  • Azure Service Fabric

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

Стандартизация операций в облачных платформах

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

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

Среды выполнения приложений в частных облачных и пограничных средах

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

  • Azure Stack HCI: позволяет размещать службу приложений Azure непосредственно в Azure Stack под управлением оператора Azure Stack.
  • Azure Stack HCI для AKS: позволяет размещать настраиваемые среды выполнения, работающие на AKS, в Azure Stack, управляемые операторами Azure Stack и AKS, чтобы обеспечить возможность переносимости на другие решения Kubernetes.
  • Служба приложений Azure в Kubernetes с Azure Arc: позволяет любому узлу Kubernetes предоставлять службы приложений в Azure. Все узлы становятся небольшими экземплярами службы приложений Azure. Поскольку каждый узел также подключается к Azure Arc, этими узлами также можно управлять с помощью согласованных облачных операций узла.

План готовности современной платформы приложений

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

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

Следующий шаг: проверка среды или целевой зоны Azure

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