Репатриация данных: почему возврат облачных данных on-premises имеет значение

Рано или поздно ваши общие облачные расходы достигнут цены on-prem хостингового оборудования. Однако к этому моменту вы потратите эти средства на операционные расходы облака и не будете владеть никаким железом, несмотря на инвестиции. С этой точки зрения, on-prem хостинг имеет гораздо более высокий ROI.

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

• Провайдеры меняют цены.
• Ваши ИТ-потребности меняются со временем.
• Команды часто недооценивают затраты на операцию в облаке.
• Сложные ИТ-среды страдают от shadow IT.

С on-prem системой хранения затраты не меняются в зависимости от того, что вы делаете с данными. Если ИТ-потребности растут, нужно инвестировать в большее железо, но вы никогда не «перебьете» счет так, как может случиться с облачным хранилищем.

Практичный контроль безопасности над данными

Хранение данных в публичном облаке означает, что провайдер отвечает за хранение и безопасность информации. Это благо для некоторых, но dealbreaker для компаний, ищущих более hands-on подход к безопасности данных.

Также есть уникальные опасения при хранении данных в публичном облаке:

• Сотни тенантов (или больше) делят инфраструктуру публичного облака, вводия элемент риска, отсутствующий при in-house хостинге.
• Нехватка видимости в контролах, защищающих облачные данные.
• Команда клиента отвечает за использование мер, предоставляемых вендором, поэтому много места для misconfiguration (частые ошибки в политиках облачной безопасности).
• Провайдер держит права на файлы, хранящиеся в публичном облаке (если вы не подпишете SLA, гласящее иное).
• Публичное облако позволяет конечным пользователям доступ к данным отовсюду, поэтому всегда есть возможность поделиться данными с неверными людьми.

Хотя сбои провайдеров редки, пользователи публичного облака должны знать, что они возможны. В августе 2018 ошибка AWS раскрыла бизнес-критичные данные около 31 000 систем, принадлежащих GoDaddy. Если бы компания держала данные on-prem, этот инцидент не произошел бы.

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

Нет риска vendor lock-in

Vendor lock-in происходит, когда компания становится слишком зависимой от облачного провайдера. Если вы храните данные у вендора слишком долго и строите архитектуру приложения вокруг этого хранилища, lock-in естественным образом растет со временем. Вы затем не можете переключиться на другую платформу (будь то in-house или другого провайдера) без высоких switching costs.

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

Лучшая латентность

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

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

• Аналитика в реальном времени.
• Приложения кибербезопасности.
• Сенсоры.
• IoT-приложения.

Если у вас есть latency-sensitive приложение, сильно зависящее от набора данных, хостинг информации on-prem (или использование edge-сервера) дает гораздо меньше лага, чем публичное облако. Вы сокращаете коммуникационный путь, плюс in-house команда имеет возможность тонко настроить хранилищные, вычислительные и сетевые ресурсы под приложение.

Проще комплаенс с регуляциями данных

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

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

Недостатки репатриации данных

Вот самые заметные вызовы и минусы репатриации:

• Вам придется выделить бюджет на железо для хостинга данных on-prem, независимо от выбранной системы (приватное облако, выделенный сервер, colocated оборудование и др.).
• Вам нужно нанять in-house команду для настройки и управления новой ИТ-средой.
• Ваша команда несет единственную ответственность за настройку защиты и безопасность on-prem данных от потенциальных нарушений, утечек, кибератак и угроз целостности данных.
• На вашем персонале лежит обеспечение адекватной доступности данных.
• Когда что-то идет не так, ваша команда должна это исправить. Нет провайдера, к которому можно обратиться в случае даунтайма, поэтому убедитесь, что ваша команда умеет управлять on-prem базами данных перед решением вытащить что-либо из публичного облака.
• Репатриация иногда нарушает химию и культуру команды. Некоторые сотрудники могут чувствовать, что компания делает шаг назад, плюс нужно добавить новые задачи в их рабочий день.
• Иногда возврат данных on-prem приводит к потере скорости или производительности. Тогда придется ре-оптимизировать все сервисы и рабочие нагрузки, использующие этот набор данных, процесс, который часто длится минимум несколько дней.
• Вы больше не имеете доступа к бесконечным on-demand ресурсам после ухода из публичного облака, поэтому прощайтесь с быстрым провижинингом и мгновенным масштабированием. Вы должны заранее выделять ресурсы и покупать новое железо, если нужно больше хранилища.

Как репатрировать данные?

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

• Начните с определения, какие данные вы хотите репатрировать, и определите цель изменения. Вы идете на полную репатриацию, или частичный подход имеет больше смысла?
• Рассмотрите любые вопросы vendor lock-in, архитектуры или конечных пользователей, которые могут замедлить или предотвратить переезд из облака.
• Разбейте план на этапы и установите KPI для мониторинга прогресса.
• Решите, какая хостинговая среда оптимальна для ваших данных. Вы хотите вернуть данные в on-prem серверную, или аренда выделенного сервера подойдет лучше? Или может быть гибридное облако — путь?
• Оцените уровень навыков вашей команды. В зависимости от опыта сотрудников, некоторые хостинговые варианты будут более привлекательны.
• Проведите детальный анализ затрат и выгод проекта для оценки финансового влияния каждого жизнеспособного альтернативы.
• Запланируйте, как команда обновит архитектуру приложения с данными, получающими новый дом. Есть ли место для улучшения производительности или сокращения лага?
• Начните перемещение данных из публичного облака. Помните, что переезд занимает время, и приложения, полагающиеся на эти данные, будут дауна в процессе, если у вас нет бэкап-хранилища. Холодные архивы обычно легче перемещать, чем часто используемые репозитории, поэтому сделайте план с минимальным влиянием на UX.
• Проведите обширное тестирование, чтобы увидеть, работают ли все приложения и сервисы, связанные с набором данных, оптимально.

Когда репатрировать данные?

Вы должны репатрировать данные, когда становится очевидно, что уход от публичного облака будет полезен для одного (или нескольких) из следующих бизнес-фронтов:

• Ваша прибыль (bottom line).
• Уровни безопасности.
• Производительность сервиса.

Вот несколько частых сценариев, когда репатриация — правильный бизнес-ход:

• Счета за облачное хранение выходят из-под контроля: начните рассматривать альтернативы хранения, как только публичные облачные счета начинают стоить больше ожидаемого (или если вы платите за ресурсы, которые не используете).
• Переход в более подходящую хостинговую среду: репатриация часто означает, что компания нашла лучшее хранилищное решение для своего сценария. Самые частые проблемы, которые бизнес решает — лаг и проблемы доступности.
• Новые правила комплаенса: обновления регуляций заставляют компании в строгих отраслях репатрировать данные из публичного облака.
• Использование облака изжило себя: публичное облако имеет наибольшее влияние на начальных фазах каждого проекта. Как только ваша команда начинает анализировать тренды использования ресурсов, начинайте регулярные cost-benefit анализы, чтобы увидеть, нужна ли репатриация.
• Спешка с облачной адопцией: плохое начальное планирование, lift-and-shift тактики и отсутствие всесторонних планов миграции — частые причины возврата публичных облачных данных on-prem. Помните, что урезание убытков лучше, чем going all-in на неправильное хранилищное решение.
• Облачные провайдеры выходят из бизнеса: клиенты не имеют выбора, кроме как вытащить свои данные, если вендор закрывается. Хотя такие сценарии редки, компании должны иметь план disaster recovery на случай закрытия провайдера.

Не бойтесь репатриации данных и всегда ищите оптимальное хранилищное решение

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