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

Миграция приложений и других основных ресурсов в облако лежит в основе многих стратегий трансформации, но если крупные поставщики услуг отключат вам доступ, то что с вами станется?

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

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

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

CTO Aiven Хейкки Нузиайнен также считает, что угроза отключения сразу от всех основных поставщиков облачных технологий очень низка для большинства предприятий — однако компании могут захотеть сохранить возможность перемещения кода для нужд аварийного восстановления. «Хоть и редко, но все же иногда мы видим большие отключения Google, AWS или Azure в одном или нескольких регионах», — говорит он. И компаниям с очень чувствительными ко времени простоя потребностями онлайн-бизнеса может понадобиться возможность восстановления из резервных копий.

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

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

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

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

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

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

По словам Валентайна, цифровая трансформация все еще находится в начале своего развития в качестве отраслевого тренда: «Вероятно, мы прошли лишь 10% пути», — говорит он. Тем не менее, уже сейчас прогнозируется, что 20% всех приложений навсегда останутся онпремис.

Потенциальные изменения, которые могут сделать облачный ландшафт более гибким, могут произойти от гибридной облачной платформы Google Anthos, говорит он. AWS также обсуждает технологии «run-anywhere» в своем облаке, на периферии или в облаке другого поставщика. «В конечном итоге поставщики облачных приложений сами признают, что облачные приложения должны быть более переносимыми, чем в прошлом», — говорит Валентайн.

Другие провайдеры помимо AWS, Google Cloud Platform и Microsoft Azure также приходят к пониманию необходимости надинфраструктурных уровней. «Snowflake — лучший пример, — указывает Валентайн, ссылаясь на известную облачную платформу данных. — Вместо того, чтобы кодировать собственное озеро на инфраструктуре как сервисе с помощью AWS, Azure или GCP, вы можете купить платформу у Snowflake».

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

  • запуск резервного копирования реляционных баз данных. «Это, скорее всего, займет время, и вам потребуется свежий бэкап для восстановления в другом месте»;
  • загрузка объектных файлов в локальную систему. «Вы должны их где-то разместить, хотя бы временно в Dropbox, вам надо их просто спасти»;
  • подготовьтесь к изменениям в работе с кодом приложений. «Если организация имеет конвейер непрерывной интеграции/непрерывного развертывания исходного кода, но он находится в облаке, нужно иметь всю необходимую информацию, чтобы развернуть его в другом месте»;
  • посмотрите, как потребуется изменить настройки DNS. «Как только вас отключат, вы окажетесь в черной дыре». Если организация сможет перейти к другому регистратору, то, по крайней мере, сможет указать своим пользователям альтернативную целевую страницу для переходного периода. «В конечном итоге можно перенаправить в какое-то другое место, но для этого необходимо иметь собственный домен, поэтому необходимо сменить регистратора».