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

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

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

1. Недооценка стоимости гибридного облака

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

Однако легко допустить ошибки, которые приведут к занижению оценок затрат, например:

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

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

2. Недооценка сетевой задержки

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

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

Снизить этот риск может помочь эффективная сетевая архитектура. Так же как и сервисы подключения к частным сетям, такие как AWS DirectConnect, при наличии бюджета на их оплату.

3. Использование негибкой гибридной облачной платформы

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

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

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

4. Привязка к облачному провайдеру

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

Например, если вы используете AWS Outposts для создания гибридного облака, то вы привязаны к AWS. Azure Stack тесно связан с облаком Microsoft. Azure Arc и Google Anthos в некоторых отношениях более гибкие, но все равно заставляют вас в определенной степени зависеть от экосистем поставщиков.

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

5. Забвение резервного копирования в гибридном облаке

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

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

Резюме

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