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

Прочитано: 138 раз(а)


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

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

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

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

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

Оценка приложений перед миграцией

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

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

«Вы также должны учитывать стоимость того, к чему подключается приложение», — сказал Эрик Костлоу, старший директор по исследованиям и продуктам Azul, платформы разработки Java. Например, Костлоу работал с компанией, которая хотела перенести 300 приложений в облако. Миграция пяти из них сильно ударила по годовому бюджету, потому что компания не ожидала, насколько большими окажутся требования к хранилищу.

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

Повышение переносимости приложений

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

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

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

Тим Хинрихс, соучредитель проекта Open Policy Agent и технический директор Styra, рекомендует настраивать ресурсы, не относящиеся к Kubernetes, с помощью инструмента, не зависящего от облака, для повышения переносимости. Например, Terraform одинаково раскручивает инфраструктуру на разных облачных платформах. Инструменты, не зависящие от облака, могут гарантировать, что безопасность, соответствие требованиям и операционный контроль не изменятся, даже если изменится облачная служба вашей организации. Независимые от облака API, используемые несколькими облаками, например Amazon S3 , также могут помочь.

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

Изучите использование контейнеров

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

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

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

Эли Зильберштейн, старший инженер-менеджер компании Hippo Insurance, также рекомендует создать уровень абстракции между вашими приложениями и облачным сервисом. Например, Hippo использует Loggly для управления журналами. Поскольку приложения компании используют внутреннюю библиотеку для отправки журналов, было бы просто переключиться на другого поставщика журналов. Благодаря этому уровню абстракции для такого переключения потребуется всего одно изменение в библиотеке протоколирования, а не изменение кода приложения.

Учитывайте зависимости данных и рабочего процесса

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

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

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



Новости партнеров