Архитектура гибридного облака: модернизация устаревших систем с контролем on-premise и мощью публичного облака

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

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

Архитектура гибридного облака: объяснение

Архитектура гибридного облака — это смесь двух или более разных типов инфраструктуры (публичное, приватное, комьюнити облака, bare metal и т.д.), объединенных в единую систему с полной переносимостью рабочих нагрузок и данных. Архитектуры варьируются в зависимости от бизнес-потребностей, но самые распространенные системы сочетают:

• On-premise систему (bare metal или приватное облако) с публичным облаком.
• Публичное облако, приватное облако и bare metal инфраструктуру.
• Два или более приватных облака.
• Два или более публичных облака.

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

Независимо от конкретной настройки, у каждой архитектуры гибридного облака есть четыре общие черты:

• Сетевое соединение: Разные среды в гибридном облаке используют одни и те же соединения, либо внутри частной сети, либо через Интернет.
• Полная интеграция: Синхронизация данных и рабочих нагрузок происходит во всех компонентах гибридного облака.
• Унифицированное управление: Команда управляет гибридной настройкой через один инструмент, и каждая среда использует одну и ту же ОС.
• Быстрая подготовка ресурсов: Гибридное облако может быстро предоставлять новые ресурсы, обычно через стороннее публичное облако.

Соединение между разными компонентами — главная особенность гибридного облака. Оно предлагает единую облачную вычислительную систему, позволяющую администраторам перемещать сервисы между средами.

Если нет интеграции между компонентами, у компании нет гибридной системы. Вместо этого настройка запускает несколько облаков параллельно и, вероятно, является формой multi-cloud.

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

Подключение

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

• Свободное перемещение рабочих нагрузок.
• Унификацию управления.
• Оркестрацию процессов.

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

Когда кто-то обращается к нашему примеру приложения, пользователь попадает на эндпоинт в приватном облаке и попадает в on-prem Kubernetes кластер. Кластер содержит множество сервисов:

• Фронтенд приложения (UI).
• MQ-сервис, обеспечивающий возможность очереди сообщений.
• Сервис портфеля, позволяющий пользователям управлять инвестициями.

Портфель выполняет операции в приватном облаке, но сервис также полагается на задачи в публичном облаке. Центральный сервис в публичном облаке — тот, который получает котировки акций с Investors Exchange (IEX).

MQ-сервис отслеживает уровни лояльности пользователей. Этот сервис также требует доступа к публичному облаку и уведомляет пользователей в реальном времени об изменениях в их статусе лояльности или портфеле.

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

Модернизация приложений

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

Допустим, наше приложение для торговли акциями начиналось как монолитная on-prem система. Приложение было на Java и имело те же сервисы, что и в настройке публично-приватного облака выше:

• UI.
• Сервис портфеля.
• MQ-сервис.
• Соединение с IEX.
• On-premise база данных.

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

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

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

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

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

Безопасность гибридного облака

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

• Потенциальные утечки данных.
• Строгие законы о конфиденциальности: GDPR, HIPAA, PCI.

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

Периметровая безопасность критична для любой гибридной облачной архитектуры с on-prem компонентами. Независимо от того, управляете ли вы bare metal дата-центром или приватным облаком, убедитесь, что периметр имеет:

• Межсетевой экран.
• Безопасность конечных точек с защищенными API-шлюзами.
• Zero-trust безопасность.

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

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

В Kubernetes среде микросегментация требует настройки TLS-сертификатов для запросов между микросервисами. Шифруйте запросы и данные (как в полете, так и в покое) как можно раньше в их жизненном цикле. Еще одна лучшая практика Kubernetes — настроить admission controller, добавляющий дополнительные уровни верификации после начальной аутентификации.

Типы архитектуры гибридного облака

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

Традиционная архитектура гибридного облака

Традиционная архитектура гибридного облака фокусируется на преобразовании дата-центров в приватные облака. Как только on-prem настройка готова, команда проектирует соединение с публичным облаком для создания бесшовного потока рабочих нагрузок и данных. Этот унифицированный ИТ-инфраструктура идеальна, если:

• Организации нужно хранить чувствительные данные в приватном облаке из-за регуляторных требований.
• Компания хочет мигрировать в облако для улучшения устаревших приложений и повышения производительности.
• Команда хочет «lift and shift» существующие on-prem рабочие нагрузки в публичное облако для уменьшения отпечатка дата-центра.
• Бизнес хочет мигрировать нестабильные рабочие нагрузки в публичное облако.
• Команда хочет использовать публичное облако для быстрого запуска ресурсов разработки и тестирования (способность, жизненно важная для эффективных DevOps-команд).

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

Современная архитектура гибридного облака

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

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

В современной архитектуре гибридного облака границы между публичными и приватными облаками менее четки. Многие провайдеры теперь предлагают публичные облачные сервисы, запускаемые в on-premise дата-центре клиента. Приватные облака, традиционно работающие on-premises, теперь могут работать:

• В off-premises дата-центре.
• На виртуальных частных сетях (VPN).
• Как виртуальное приватное облако (VPC).

Infrastructure-as-code (IaC) — значительный аспект современной архитектуры гибридного облака. IaC позволяет разработчикам быстро и по запросу запускать новые среды.

Проектирование и построение гибридной облачной архитектуры

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

Рассмотрите более простые, менее дорогие модели развертывания

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

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

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

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

• Потребностями in-house доступности.
• Требованиями соответствия.
• Потребностями приложения.

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

• Уровни безопасности.
• Юридические обязательства.
• Цена сервиса.
• Доступность.
• Требования приложения.
• Локации пользователей.

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

Будьте осторожны с vendor lock-in

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

Команды, ищущие SaaS-партнера, имеют больший запас прочности, но компании, желающие построить приложение через PaaS или IaaS провайдера, должны сделать правильный выбор с самого начала, чтобы избежать серьезных проблем с vendor lock-in. При выборе облачного провайдера учитывайте:

• Стоимость сервиса.
• Используемые технологии.
• Инструменты управления.
• Физические локации дата-центров.
• Service-level agreements (SLA).
• Поддержку bare metal и приватных облачных сред.
• Безопасность, управление и бизнес-политики.
• Зависимости сервисов.

Выберите правильную Cloud OS

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

• Kubernetes.
• VMware Cloud.
• OpenStack.
• Nutanix.

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

Встройте безопасность в свою гибридную облачную архитектуру

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

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

Идеальный облачный вариант для модернизации приложений

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