Gubin Systems

Шаг 4: Доставка приложений с несколькими облаками

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

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

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

Шаг 5: Промышленный процесс доставки приложений

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

Заключение

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

Люди: переход к навыкам мульти-облака

— Повторное использование навыков управления внутренними центрами обработки данных и поставщиками единого облака и их последовательное применение в любой среде.
— Охватит DevSecOps и других гибких методов для непрерывной доставки все более эфемерных и распределенных систем.

Процесс: переход на самообслуживание.

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

Общее резюме

Чтобы процветать в эпоху многооблачной архитектуры, движимой цифровой трансформацией, 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-управляемого хранилища ключей / значений, которое можно использовать для простой настройки служб во время выполнения в любой среде.

Кейс: Для определенных задач компаниям нужны определенные ресурсы.

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

Кейс: Чтобы создать и запустить любой ИТ-сервис внутри компании, вам необходимо решить целый ряд вопросов. Например, вы решили начать новую учетную систему, систему учета или CRM-систему.

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

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

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

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

SaaS — Программное обеспечение как услуга (Software As A Service). Пример: Microsoft Office 365, UcoZ.
PaaS — Платформа как услуга (Platform As A Service). Веб-приложение или группа веб-приложений, выполняющих какие-то функции. Пример: Microsoft Office 365, Контур Эльба, GitBook, Vepp.
IaaS — Инфраструктура как услуга (Infrastructure As A Service), то есть сервер или группа серверов, объединенных общим признаком. Пример: Яндекс Облако, Amazon Web Services.
Веб-приложение — Приложение, выполняющееся в веб-пространстве. Почти не отличается от стандартных программ кроме той особенности, что может иметь форму сервиса или веб-сайта. Пример: ISPManager, cPanel.