Уточнение платформы приложений для упрощения разработки приложений и управления инфраструктурой

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

Упрощение и стандартизация

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

• Категории типов ресурсов (высокий объем вычислительных ресурсов, высокая память)
• Категории размера ресурса (размер футболки, небольшой средний и большой)

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

Вы можете отслеживать изменения с помощью средств IaC с функциями обнаружения смещения, которые могут автоматически устранять смещение (GitOps). Примерами этих инструментов являются средства Terraform и облачные собственные средства IaC (примеры, API кластера, кроссплан, оператор службы Azure версии 2). Вне смещения инструментов IaC обнаруживаются облачные средства настройки, которые могут запрашивать конфигурации ресурсов, например Azure Resource Graph. Они могут служить двумя преимуществами; вы отслеживаете изменения за пределами кода инфраструктуры и проверяете наличие измененных предварительно настроенных конфигураций. Чтобы избежать слишком жестких ограничений, можно реализовать отказоустойчивость в развертываниях с предопределенными ограничениями. Например, можно использовать Политика Azure, чтобы ограничить количество узлов Kubernetes, которые может иметь развертывание.

Самоуправляемые или управляемые?

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

Во время разработки платформы оцените и определите приоритеты потребностей вашей организации в службе. Например, независимо от того, создаете ли приложения непосредственно на Служба Azure Kubernetes (AKS) или с помощью приложений контейнеров Azure (ACA) зависит от ваших требований к службе и от собственного набора возможностей и навыков. То же самое относится к службам стиля функций, таким как Функции Azure или служба приложение Azure. ACA, Функции Azure и Служба приложений снизить сложность, а AKS обеспечивает большую гибкость и контроль. Более экспериментальные модели приложений, такие как проект инкубации OSS Radius , пытаются обеспечить баланс между двумя, но обычно находятся на более ранних стадиях зрелости, чем облачные службы с полной поддержкой и присутствием в установленных форматах IaC.

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

Общие и выделенные ресурсы

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

• Организация: совместное использование ресурсов, таких как кластеры в пределах, а не между, границы организации могут улучшить, как они соответствуют направлению организации, требованиям и приоритету.
• Тенантность приложений: приложения могут иметь различные требования к изоляции клиента; необходимо проверить соответствие отдельных приложений безопасности и нормативным требованиям, если оно может сосуществовать с другими приложениями. Например, в Kubernetes приложения могут использовать изоляцию пространства имен. Но следует также рассмотреть возможность аренды приложений для разных типов сред. Например, часто рекомендуется избегать смешивания тестовых приложений с рабочими приложениями в одном кластере, чтобы избежать непредвиденных последствий из-за неправильной настройки или проблем безопасности. Или вы можете сначала протестировать и настроить выделенные кластеры Kubernetes для отслеживания этих проблем перед развертыванием в общем кластере. Независимо от того, согласованность в вашем подходе является ключевым фактором, чтобы избежать путаницы и ошибок.
• Потребление ресурсов. Понимание использования каждого ресурса приложения, запасной емкости и прогнозирование, чтобы оценить, является ли общий доступ жизнеспособным. Кроме того, следует учитывать ограничения потребляемых ресурсов (ограничения емкости центра обработки данных или подписки). Цель заключается в том, чтобы избежать перемещения приложения и зависимостей из-за ограничений ресурсов в общей среде или иметь динамические инциденты сайта при истечении емкости. Используйте ограничения ресурсов, репрезентативное тестирование, мониторинг оповещений и отчеты для определения потребления ресурсов и защиты от использования приложений слишком большого количества ресурсов.
• Оптимизация общих конфигураций: общие ресурсы, такие как общие кластеры, требуют дополнительного рассмотрения и настройки. Эти рекомендации включают перекрестную зарядку, выделение ресурсов, управление разрешениями, владение рабочей нагрузкой, обмен данными, координацию обновления, размещение рабочей нагрузки, создание, управление итерация базовой конфигурации, управление емкостью и размещение рабочей нагрузки. Общие ресурсы имеют преимущества, но если стандартные конфигурации слишком строги и не развиваются, они становятся устаревшими.

Реализация стратегий управления

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

• Соответствие начальному развертыванию (справа от начала): это можно достичь с помощью стандартных шаблонов IaC, доступных через каталоги, с помощью управления разрешениями и политик, чтобы обеспечить развертывание только разрешенных ресурсов и конфигураций.
• Поддержание соответствия требованиям (оставайтесь правым ): средства на основе политик могут предотвратить или предупредить вас при изменении ресурсов. Помимо основной инфраструктуры, рассмотрите также средства обеспечения соответствия требованиям внутри ресурсов, таких как K8s, а также OS, используемых в контейнерах или виртуальных машинах. Например, может потребоваться применить заблокированную конфигурацию ОС или установить средства программного обеспечения безопасности, такие как групповая политика Windows, SELinux, AppArmor, Политика Azure или Kyverno. Если у разработчиков есть доступ только к репозиториям IaC, можно добавить рабочие процессы утверждения для просмотра предлагаемых изменений и предотвращения прямого доступа к плоскостям управления ресурсами (например, Azure).

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

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

• Централизованно управляемые стандарты
• Управление версиями для политик
• Автоматическое тестирование и проверка
• Сокращение времени развертывания
• Непрерывное развертывание

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

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

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

Для поддержки приложений и инфраструктуры требуется наблюдаемость и ведение журнала во всем стеке.

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

Чтобы устранить эти проблемы, рассмотрите следующее:

• Стандарты. Применение стандартов ведения журнала для упрощения создания и повторного использования стандартных панелей мониторинга и упрощения обработки приема с помощью платформы наблюдения OpenTelemetry.
• Разрешения. Предоставьте панели мониторинга уровня команды или приложения, используя что-то подобное Grafana для предоставления свернутых данных для всех заинтересованных лиц, а также средства для доверенных членов групп приложений, чтобы безопасно получить доступ к журналам при необходимости.
• Хранение: хранение журналов и метрик может быть дорогостоящим, и может создавать непреднамеренные риски или нарушения соответствия требованиям. Установите значения по умолчанию хранения и опубликуйте их в рамках руководства по началу.
• Мониторинг ограничений ресурсов. Группы операций должны иметь возможность определять и отслеживать ограничения для заданного типа ресурса. Эти ограничения следует учитывать в шаблонах или политиках IaC с помощью таких средств, как Политика Azure. Затем операции должны заранее отслеживать с помощью панелей мониторинга в нечто подобное Grafana и развернуть общие ресурсы, где автоматическое масштабирование невозможно или включено. Например, отслеживайте количество узлов кластера K8s для емкости по мере подключения и изменения приложений с течением времени. Требуется оповещение, и эти определения должны храниться в виде кода, чтобы их можно было программным способом добавлять в ресурсы.
• Определите ключевые метрики емкости и работоспособности: отслеживайте и оповещайте ОС и общие ресурсы (например, ЦП, память, хранилище) для голода с коллекцией метрик с помощью таких функций, как Prometheus или Azure Container Insights. Вы можете отслеживать использование сокетов и портов, потребление пропускной способности сети для чатовых приложений и количество приложений с отслеживанием состояния, размещенных в кластере.

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

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

• Следуйте принципу минимальных привилегий.
• Объединение управления безопасностью DevOps в нескольких конвейерах.
• Убедитесь, что контекстная аналитика позволяет выявлять и устранять наиболее критически важный риск.
• Включите обнаружение и реагирование на современные угрозы в облачных рабочих нагрузках во время выполнения.

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

• Управление внешними атаками с помощью таких Управление направлением внешних атак Microsoft Defender (Defender EASM).
• Сетевые службы безопасности — приложения и облачная защита от кибератак на основе сети с помощью таких приложений, как Безопасность сети Azure.
• Интеллектуальная аналитика безопасности. Использование решения для управления сведениями и событиями безопасности (SIEM), например Microsoft Sentinel
• Способы управления, защиты, визуализации и безопасного управления данными, таких как Microsoft Purview
• Способы сканирования кода для потенциальных уязвимостей безопасности, обнаружения секретов, проверки зависимостей, таких как GitHub Advanced Security и GitHub Advanced Security для Azure DevOps.
• Управление цепочкой поставок программного обеспечения, особенно для контейнеров (например, применение платформы безопасной цепочки поставок контейнеров).

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

Управление доступом к удостоверениям к службам, приложениям, инфраструктуре в масштабе может оказаться сложной задачей. Поставщики удостоверений для создания, обслуживания и управления сведениями об удостоверениях. План должен включать службы проверки подлинности для приложений и служб, которые могут интегрироваться с системами авторизации на основе ролей (RBAC). Например, можно использовать идентификатор Microsoft Entra для предоставления проверки подлинности и авторизации в масштабе для таких служб Azure, как Служба Azure Kubernetes без необходимости настраивать разрешения непосредственно в каждом отдельном кластере.

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

Сокращение затрат путем идентификации владельцев рабочих нагрузок и ресурсов отслеживания

Управление затратами является еще одной частью разработки платформы. Чтобы правильно управлять платформой приложений, необходимо определить владельцев рабочих нагрузок. Вы хотите получить список ресурсов, которые сопоставляют владельцев определенного набора метаданных. Например, в Azure можно использовать метки AKS, теги Azure Resource Manager, а также такие понятия, как проекты в средах развертывания Azure, чтобы сгруппировать ресурсы на разных уровнях. Для этого выбранные метаданные должны содержать обязательные свойства (используя примерно Политика Azure) при развертывании рабочих нагрузок и ресурсов. Это помогает с выделением затрат, сопоставлением ресурсов решения и владельцами. Рекомендуется выполнять регулярные отчеты для отслеживания потерянных ресурсов.

Помимо отслеживания, вам может потребоваться назначить затраты отдельным группам приложений для использования ресурсов, используя эти же метаданные с системами управления затратами, такими как Microsoft Cost Management. Хотя этот метод отслеживает ресурсы, подготовленные командами приложений, он не покрывает затраты на общие ресурсы, такие как поставщик удостоверений, ведение журнала и хранилище метрик, а также потребление пропускной способности сети. Для общих ресурсов можно разделить операционные затраты по отдельным командам или предоставить выделенные системы (например, хранилище ведения журнала), где есть несоединяемое потребление. Некоторые общие типы ресурсов могут предоставлять аналитические сведения о потреблении ресурсов, например Kubernetes имеет такие средства, как OpenCost или Kubecost и может помочь.

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

Определите, когда и где инвестировать

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

Вопрос	Советы
Вы хотите адаптировать существующую платформу приложений, начать новую версию или использовать сочетание этих подходов?	Даже если вы довольны тем, что у вас есть сейчас или начинается свежий, вы хотите подумать о том, как адаптироваться к изменению с течением времени. Немедленные изменения редко работают. Платформы приложений — это движущаяся цель. Ваша идеальная система изменяется по мере прохождения времени. Вы хотите учитывать это мышление и любые связанные планы миграции в ваш проект.
Если вы хотите изменить то, что вы делаете сегодня, какие продукты, услуги или инвестиции вы довольны?	Как говорится, "если это не сломано, не исправьте его". Не изменяйте вещи без причины сделать это. Тем не менее, если у вас есть какие-либо домашние решения, рассмотрите, пришло ли время перейти к существующему продукту, чтобы сэкономить на долгосрочном обслуживании. Например, если вы работаете с собственным решением для мониторинга, вы хотите удалить это бремя из команды ops и перейти на новый управляемый продукт?
Где с течением времени происходит наибольшее изменение? Существуют ли какие-либо из этих областей, которые являются общими для всех (или большинства) типов приложений вашей организации?	Области, с которыми вы или ваши внутренние клиенты не довольны и вряд ли изменятся часто являются отличными местами для начала. Они имеют большую отдачу от инвестиций в долгосрочной перспективе. Это также поможет вам определить, как можно упростить миграцию в новое решение. Например, модели приложений, как правило, являются гибкими, но средства анализа журналов, как правило, имеют более длительный срок хранения. Вы также можете сосредоточиться на новых проектах или приложениях, чтобы начать, пока вы подтверждаете, что изменение направления имеет требуемые возвращаемые значения.
Вы инвестируете в пользовательские решения в областях с наивысшей стоимостью? Вы чувствуете, что уникальная платформа инфраструктуры приложений является частью вашего конкурентного преимущества?	Если вы определили пробелы, прежде чем делать что-то пользовательское, рассмотрите, какие области поставщики, скорее всего, будут инвестировать и сосредоточить свое пользовательское мышление в другом месте. Начните с самого себя как интегратора, а не пользовательской инфраструктуры приложений или поставщика моделей приложений. Все, что вы строите, придется поддерживать, какие карлики передних затрат в долгосрочной перспективе. Если вы чувствуете, что срочно необходимо создать решение в области, которую вы подозреваете, будут охвачены поставщиками в долгосрочной перспективе, план для закатирования или долгосрочной поддержки. Ваши внутренние клиенты обычно будут так же счастливы (если не больше) с готовым продуктом в качестве пользовательского.

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

Связанный контент

Разработка основы самообслуживания разработчика