Общее резюме

Чтобы процветать в эпоху многооблачной архитектуры, движимой цифровой трансформацией, Enterprise IT должна развиваться от ITIL на основе gatekeeping до обеспечения общих процессов самообслуживания для DevOps excellence.
Для большинства предприятий усилия по цифровой трансформации означают более быстрое и широкомасштабное создание новых деловых и потребительских ценностей. Следствием этого для предприятия является переход от оптимизации затрат к оптимизации скорости. Облако является неизбежной частью этого сдвига, поскольку оно предоставляет возможность быстрого развертывания услуг по требованию с неограниченным масштабом.
Чтобы открыть самый быстрый путь к ценности облака, предприятия должны подумать о том, как индустриализировать процесс доставки приложений на каждом уровне облака: охватывая модель работы облака и настраивая людей, процесс и инструменты для него.
Здесь мы рассмотрим последствия облачной операционной модели и представим решения для ИТ-групп по внедрению этой модели в инфраструктуру, безопасность, сеть и доставку приложений.

Переход к мульти-облачному центру обработки данных

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

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

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

Последствия облачной операционной модели

Существенным следствием перехода к облаку является переход от «статической» инфраструктуры к «динамической» инфраструктуре: от фокусировки на конфигурации и управлении статическим парком ИТ-ресурсов к предоставлению, обеспечению безопасности, подключению и запуску динамических ресурсов по требованию.
Разложение этой импликации и разработка стека подразумевают различные изменения подхода:

• Обеспечение. Уровень инфраструктуры переходит от запуска выделенных серверов в ограниченном масштабе к динамической среде, где организации могут легко адаптироваться к возросшему спросу, разворачивая тысячи серверов и масштабируя их, когда они не используются. По мере того как архитектуры и службы становятся более распределенными, объем вычислительных узлов значительно увеличивается.
• Безопасность. Уровень безопасности переходит от принципиально «высоконадежного» мира, навязываемого сильным периметром и брандмауэром, к среде «низкого доверия» или «нулевого доверия» без четкого или статического периметра. В результате основополагающее предположение о безопасности смещается от IP-базирования к использованию доступа к ресурсам на основе идентификации. Этот сдвиг весьма разрушителен для традиционных моделей безопасности.
• Соединение. Сетевой уровень переходит от сильной зависимости от физического местоположения и IP-адреса служб и приложений к использованию динамического реестра служб для обнаружения, сегментации и композиции. Корпоративная ИТ-группа не имеет такого же контроля над сетью или физическими местоположениями вычислительных ресурсов и должна думать о подключении на основе служб.
• Выполнение. Уровень среды выполнения переходит от развертывания артефактов к статическому серверу приложений и развертыванию приложений с планировщиком поверх пула инфраструктуры, подготовленного по требованию. Кроме того, новые приложения стали коллекциями служб, которые динамически подготавливаются и упаковываются несколькими способами: от виртуальных машин до контейнеров.

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

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

Разблокировка облачных операционных моделей

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

Шаг 1. Подготовка инфраструктуры с несколькими облаками

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

Воспроизводимая инфраструктура в виде кода

Первая цель Общей службы для подготовки инфраструктуры-обеспечить доставку воспроизводимой инфраструктуры в виде кода, предоставляя группам DevOps способ планирования и предоставления ресурсов внутри рабочих процессов CI/CD с использованием знакомых инструментов.
Команды DevOps могут создавать шаблоны Terraform, выражающие конфигурацию служб с одной или нескольких облачных платформ. Terraform интегрируется со всеми основными инструментами управления конфигурациями, что позволяет обрабатывать мелкозернистую подготовку после подготовки базовых ресурсов. Наконец, шаблоны могут быть расширены с помощью служб многих других поставщиков ISV для включения агентов мониторинга, систем мониторинга производительности приложений (APM), инструментов безопасности, DNS и сетей доставки контента и многое другое. После определения шаблоны могут быть подготовлены автоматически по мере необходимости. При этом Terraform становится lingua franca и общим рабочим процессом для команд, предоставляющих ресурсы в общедоступном и частном облаке.
Для самообслуживания ИТ, развязка процесса создания шаблона и процесса подготовки значительно сокращает время, необходимое для любого приложения, чтобы идти в прямом эфире, так как разработчикам больше не нужно ждать утверждения операций, если они используют предварительно утвержденный шаблон.

Соблюдение и управление

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

Шаг 2: Безопасность нескольких облаков

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

Управление безопасностью

Первым шагом в облачной безопасности обычно является управление безопасностью: Централизованное хранилище, Управление доступом и Распространение динамических паролей. Вместо зависимости от статических IP-адресов решающее значение имеет интеграция с системами доступа на основе удостоверений, такими как AWS IAM и Azure AAD, для аутентификации и доступа к службам и ресурсам.
Корпоративные ИТ-группы должны создать общую службу, которая позволяет запрашивать секреты для любой системы через согласованный, проверенный и защищенный рабочий процесс.

Шифрование как сервис

Кроме того, предприятия должны шифровать данные приложений в состоянии покоя и в пути. Определенные системы могут предоставлять шифрование как услугу для обеспечения согласованного API для управления ключами и криптографии. Это позволяет разработчикам выполнять единую интеграцию, а затем защищать данные в нескольких средах.
Использование таких систем в качестве основы для шифрования как услуги решает сложные проблемы, с которыми сталкиваются группы безопасности, такие как сертификат и ротация ключей. Также это позволяет централизованное управление ключами для упрощения шифрования данных в пути и в покое через облака и центры обработки данных и помогает снизить затраты на дорогостоящие аппаратные модули безопасности (HSM), повысить производительность благодаря согласованным рабочим процессам безопасности и криптографическим стандартам в организации.
Хотя многие организации предоставляют разработчикам мандат на шифрование данных, они не часто знают «как это сделать», что оставляет разработчикам создавать пользовательские решения без надлежащего понимания криптографии.

Шаг 3: Сеть мульти-облачных сервисов

Проблемы создания сетей с помощью сервиса Cloudflare часто являются одним из самых сложных аспектов принятия облачной операционной модели для предприятий. Сочетание динамических IP-адресов, значительный рост трафика Восток-Запад, как шаблон микросервисов принимается, и отсутствие четкого периметра сети является огромной проблемой.
Сетевые службы должны предоставляться централизованно там, где ИТ-группы предоставляют возможности реестра служб и обнаружения служб. Наличие общего реестра предоставляет «карту» того, какие службы запущены, где они находятся и их текущее состояние работоспособности. Реестр можно запросить программно, чтобы включить обнаружение служб или автоматизацию сети дисков шлюзов API, балансировщиков нагрузки, брандмауэров и других важных компонентов промежуточного программного обеспечения. Эти компоненты промежуточного программного обеспечения могут быть перемещены из сети с помощью подхода service mesh, где прокси работают на краю, чтобы обеспечить эквивалентную функциональность. Подходы к сервисной сетке позволяют упростить топологию сети, особенно для топологий с несколькими облаками и несколькими центрами обработки данных.

Реестр и обнаружение служб

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

Обслуживание сети

В сложной среде облачные вычисления предоставляют распределенную сетку служб для подключения, защиты и настройки служб на любой платформе выполнения и в облаке. Облако может предоставить управляемую API плоскость управления, которая интегрируется с прокси, такими как Envoy, HAProxy и Nginx для плоскости данных. Это позволяет критически важным функциям, таким как именование, сегментация и авторизация, а также маршрутизация обрабатываться прокси на краю, а не с помощью централизованного промежуточного программного обеспечения.
Службы также могут позволить мелкозернистой сегментации службы для обеспечения связи между службами с автоматическим шифрованием TLS и авторизации на основе удостоверений; могут быть интегрированы для централизованного управления PKI и сертификатами. Конфигурация службы достигается с помощью API-управляемого хранилища ключей / значений, которое можно использовать для простой настройки служб во время выполнения в любой среде.