Использование гравитации данных:стратегические решения в области облачной архитектуры

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

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

Кикер? Гравитационному притяжению все равно, подходит ли вам среда, в которой вы застряли.

Что такое значимость данных?

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

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

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

Реальное влияние на облачную стратегию

<сильный>1. Проблемы миграции

Миграции петабайтного масштаба не являются «подъемом и сдвигом». Это поэтапные операции со встроенными окнами переключения, стратегиями дельта-синхронизации, проверкой данных и управлением рисками. Даже при самом лучшем планировании вы можете столкнуться:

• Плата за выезд, которая призвана препятствовать выезду.
• Регулирование пропускной способности со стороны провайдера.
• Простой в работе или ухудшение качества обслуживания во время переключений.
• Аудит соответствия, который может остановить миграцию на полпути.
<ли> 

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

<сильный>2. Штрафы за производительность

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

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

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

<сильный>3. Привязка к поставщику по умолчанию

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

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

См. также: Местоположение, местоположение, местоположение тоже имеет значение для данных

Снижение тяжести данных

Вот как не допустить, чтобы притяжение превратилось в ловушку:

Применить гибридную и мультиоблачную среду по умолчанию

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

Перенесите вычислительные ресурсы на периферию

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

Будьте агрессивны в управлении жизненным циклом данных

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

Заглядывая в будущее

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

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

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

Действия, которые нужно начать прямо сейчас:

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

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