Гибридное облако и многооблачная среда: в чем разница?

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

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

Сначала разделите три концепции

Частное облако не обязательно должно находиться в офисе

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

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

Гибридная ИТ-среда шире, чем гибридное облако

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

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

«Мультиоблако» относится к количеству провайдеров, а не к серверам.

Два региона одного облачного провайдера сами по себе не создают многооблачную среду. Два провайдера создают такую среду, даже если их приложения не обмениваются данными. Само обозначение multicloud не гарантирует единого управления, переносимости рабочих нагрузок или переключения на резервную среду при аварии.

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

Сравните модели по операционным задачам

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

Отличите намеренное решение от случайного набора подписок

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

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

Три варианта архитектуры для малого бизнеса

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

Офисная система и один облачный поставщик

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

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

Два облачных поставщика без локального сервера

Состав: сотрудники, облачная система продаж от поставщика A, веб-сайт на облачной платформе поставщика B и обмен запросами между веб-сайтом и системой продаж. Это мультиоблачная архитектура. Два поставщика по отдельности не создают гибридную облачную среду. Для этого требуется отдельная облачная инфраструктура, соединенная посредством механизмов переноса данных и приложений.

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

Частный облак и два публичных поставщика

Состав: частный облак компании, публичный облак A для приложения, публичный облак B для отдельной аналитической задачи и согласованные соединения для передачи данных. Если инфраструктуры соединяются посредством механизмов переноса данных и приложений, то такая архитектура объединяет гибридную и мультиоблачную среды.

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

Проверьте соединения, доступ и ответственность

Определите потоки данных и точки отказа

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

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

Координируйте вход и жизненный цикл доступа

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

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

Назначьте владельца для всего сервиса

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

Тип сервиса влияет на распределение работы. С виртуальной машиной компания может владеть гостевой системой и приложением. С готовым облачным приложением, она может управлять доступом и настройками. Облачные сервисы не снимают ответственность за данные и учетные записи. Проверьте объем работы в документации и контракте выбранного сервиса, а не полагайтесь на слово «многооблачность».

Оцените переносимость и устойчивость без обещаний

Второй поставщик не устраняет зависимость от первого

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

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

Разные облака не заменяют план восстановления

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

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

Рассчитайте стоимость дополнительной сложности

Объедините затраты и мониторинг в одном представлении

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

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

Проверьте ограничения общего дашборда управления

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

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

Согласуйте правила перед автоматизацией повторяющихся действий

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

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

Заполните контрольный список перед добавлением поставщика

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

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

Выберите среду для подтвержденной задачи

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

Для оценки существующих связей и требований к управлению, обсудите облачную и гибридную инфраструктуру с ключевыми заинтересованными сторонами (DK). Начните со списка систем, поставщиков и проблемных зависимостей.

Источники

• Определения облачных моделей, согласно NIST
• Модели развертывания в руководстве AWS
• Совместная ответственность в облачных сервисах Microsoft
• Планирование затрат на передачу данных в AWS