Что такое оркестрация в ит
От микросервисного монолита к оркестратору бизнес-сервисов
Когда компании решают разделить монолит на микросервисы, в большинстве случаев они последовательно проходят четыре этапа: монолит, микросервисный монолит, микросервисы, оркестратор бизнес-сервисов.
Если вы определите, на каком из этапов находитесь сейчас, это поможет вам понять плюсы и минусы текущего этапа, оценить стоит ли идти на следующий этап и, если стоит, увидеть шаги необходимые для перехода.
В каждом разделе вы найдете ссылки для более глубокого погружения в нюансы конкретного перехода.
Этап №1. Монолит
1.1 Характеристики
Обычно монолитную архитектуру можно описать так:
1.2 Проблемы
1.3 Как перейти на следующий этап
В основе процесса выделения микросервисов лежит вынесение бизнес-задач из монолита в отдельные сервисы. При этом нужно руководствоваться принципом единственности ответственности, который перефразируется так: у микросервиса должна быть только одна причина для изменения. Этой причиной является изменение бизнес-логики той единственной задачи, за которую он отвечает.
Постепенно у вас образуется набор из микросервисов, где каждый отвечает лишь за свою бизнес-задачу:
При создании микросервисной архитектуры полезно периодически проверять себя по чеклисту The Microservice Architecture Assessment, чтобы не упустить какую-то важную деталь.
Этап №2. Микросервисный монолит
2.1 Характеристики
Все части монолита стали независимыми микросервисами и эти микросервисы должны общаться между собой. Если раньше, находясь внутри одного процесса, сервисы вызывали методы друг друга напрямую, то теперь нужно интегироваться.
Из четырех способов интеграции в микросервисной архитектуре обычно не используют обмен файлами и стараются не использовать shared database, зато активно работают с RPC и очередью сообщений.
Получается, что все части монолита распались на микросервисы, а их обратно соединили паутиной синхронных и асинхронных интеграций:
По факту, получился тот же монолит, но с большим количеством новых проблем.
2.2 Проблемы
Если на пути рефакторинга монолита вы остановитесь на этом этапе, то, вполне резонно, сделаете вывод, что с монолитом было лучше и дешевле.
2.3 Как перейти на следующий этап
Основные идеи: локализовать точки интеграции и контролировать все потоки данных. Чтобы этого добиться, надо использовать:
Чтобы избежать типовых проблем и упростить разработку, рекомендую взять на вооружение подходы по повышению отказоустойчивости:
Этап №3. Микросервисы
3.1 Характеристики
Микросервисы ничего не знают о существовании друг друга: работают со своей базой данных, API и сообщениями в очереди. Каждый микросервис решает только одну бизнес-задачу и старается делать это максимально эффективно, за счет выбора технологий, стратегии масштабирования.
Становится заметна главная черта хорошей архитектуры: сложность системы растет линейно с увеличением количества микросервисов.
3.2 Проблемы
На этом этапе сложные технические задачи решены, поэтому начинаются проблемы на уровне бизнес-задач:
3.3 Как перейти на следующий этап
Многие компании не идут дальше, потому что на текущем этапе бизнес-задачи могут решаться уже достаточно быстро и эффективно. Тем, кто решают двигаться дальше:
Этап №4. Оркестратор бизнес-сервисов
4.1 Характеристики
Оркестратор бизнес-сервисов обычно является визуальной платформой, где соединяются сервисы, выставляются триггеры и условия ветвления, контролируются все потоки данных: реализована трассировка запросов, логирование событий, автомасштабирование по условиям. Сам оркестратор ничего не знает о специфике бизнес-процессов, которые на нем крутятся.
На этом этапе можете решить задачу создания продукта в визуальном редакторе. Если нужных «квадратиков» не хватает, то программисты создают микросервис, учитывая правила описания сервиса для оркестратора, публикуют API и «кубик» появляется в визуальном редакторе, готовый соединяться с другими участниками бизнес-задачи.
4.2 Проблемы
4.3 Как перейти на следующий этап
На данный момент я не вижу сформировавшегося пятого этапа. Если вы видели жизнь после оркестратора бизнес-сервисов, буду рад увидеть описание вашего опыта в комментариях.
Заключение
Эти четыре этапа показывают, как мне кажется, естественный ход вещей:
☸️ Первое знакомство с Kubernetes: что под капотом у системы оркестрации?
Андрей Трошин
Что под капотом у оркестратора?
Любой ИТ-дирижер позволяет развертывать приложения, управлять ими и реагировать в реальном времени на происходящие в них изменения. Типичные, задачи которые стоят перед оркестратором:
Примеры оркестраторов
Apache Mesos
Apache Mesos – централизованная система управления кластером. Она объединяет в группы отдельные узлы согласно требованиям, а также обеспечивает их изоляцию от остальных IT-ресурсов. Разработанный в университете Беркли продукт вышел в 2009 г. и имеет нестандартный подход к архитектуре. Apache Mesos отлично подходит для создания очень больших систем и реализации масштабных проектов.
Kubernetes
Самый модный оркестратор основан на разработках Google. В 2014 г. корпорация открыла код Kubernetes и стала распространять систему под лицензией Apache 2.0. В результате началось быстрое развитие продукта сообществом, и на данный момент он используется как в небольших проектах, так и в сегменте Enterprise.
Docker Swarm
Компания Docker (в девичестве dotCloud) одной из первых предложила реализацию контейнеров и систему управления ими. Kubernetes внутри себя обычно использует Docker как среду исполнения контейнеров (Container runtimes). Docker swarm позволяет объединять хосты Docker в общий виртуальный хост. Обычно это решение используют в относительно небольших проектах.
Что под капотом у Kubernetes?
Любой оркестратор позволяет развертывать и масштабировать приложения, а также реагировать на изменения в них. Все эти функции реализуются в Kubernetes слоем Control plane. В предыдущей статье мы рассмотрели простой способ развертывания кластера, а сейчас разберем его компоненты более подробно.
На схеме видно, что внутри кластера есть некоторое количество нод (от англ. node – узел), на которых запущена среда исполнения контейнеров (Container runtimes). В Conteiner runtime живет контейнер, а в нем – наше приложение. Вот такая матрешка получается. Kubernetes управляет этими матрешками, отслеживает их состояние, планирует ресурсы (CPU, RAM, HDD) и осуществляет при необходимости масштабирование.
Control Plane
Мозгом Kubernetes кластера является набор компонентов, которые обычно устанавливаются на Master node (мастер-узел). В разных конфигурациях k8s мастеров может быть несколько – это необходимо, если требуется высокая доступность кластера. На схеме показан набор компонентов мастер-ноды.
Познакомимся поближе с каждым из них.
API server
Этот компонент является endpoint, т.е. точкой контакта, на которую приходят запросы на создание объектов Kubernetes. API Server – единственный компонент, который общается с Сluster store напрямую.
Scheduler
Компонент, который отслеживает созданные поды без привязанного узла и выбирает узел, на котором они должны работать с учетом запрошенных ресурсов и фактических ресурсов ноды.
Cluster store (etcd)
Этот компонент реализует распределенное и высоконадежное хранилище данных в формате key-value, которое используется как основное для данных кластера Kubernetes. Рекомендуется делать его резервные копии, поскольку если Cluster store разрушится, под угрозой весь кластер k8s.
Controllers
Компонент, осуществляющий контроль на всех уровнях кластера Kubernetes.
Мы разобрали на верхнем уровне, что из себя представляет Control plane. Это своего рода серверная часть, обслуживающая очередь клиентов. Клиентами являются Worker node (рабочие ноды), на которых мы и развертываем наши приложения.
На каждой Worker node есть определенный набор компонентов, представленный на схеме.
Познакомимся с ними.
Kubelet
Самый главный компонент Worker node. Через него происходит обмен данными с API-сервером. Основная функция – слушать сервер на предмет появления новых заданий и выполнять их при необходимости. Также Kubelet отчитывается серверу о проделанной работе.
Container runtime
Для выполнения задач на ноде необходима некая среда исполнения, внутри которой запускаются контейнеры с приложениями: обычно это Docker, но Kubernetes поддерживает и другие варианты. Например containerd, реализующий модель Container Runtime Interface (CRI). Выбор среды исполнения остается за вами.
Kube proxy
Последний компонент Worker node отвечает за локальную сеть. Он гарантирует, что каждый узел получит свой уникальный IP, реализует правила IPTABLES или IPVS для управления маршрутизацией и балансировкой нагрузки трафика во внутренней сети k8s.
Подведем итог. Если соединить компоненты Control Plan и компоненты Worker nodes, получится следующая схема.
Надеюсь, пазл сложился. В третьей публикации цикла мы начнем углубляться в практическую часть и изучим базовые конструкции кластера, а в четвертой перейдем к развертыванию приложений.
Оркестрация данных: основные элементы инфраструктуры и стратегии
Рост объемов данных остается беспрецедентным, причем они поступают из огромного множества источников. Все более сложные перемещения данных по большому многообразию экосистем существенно затрудняют управление, и в будущем эта тенденция сохранится. Однако данные — такой же важный актив, как капитальное имущество и интеллектуальная собственность. И чем данных больше, тем сложнее ими управлять. Поэтому современным распределенным предприятиям требуются новые методы перемещения и оркестрации данных.
В статье мы рассмотрим этапы жизненного цикла данных, которые постоянно находятся в движении. Данные перемещаются от источника в точку первоначального приема, а оттуда в системы хранения и анализа. Наконец, данные архивируются. Для управления потоками данных требуется программное обеспечение, отвечающее за оркестрацию по всей инфраструктуре. Но каким требованиям должна удовлетворять оркестрация? Что следует учитывать при разработке политик оркестрации данных? На эти вопросы мы тоже ответим.
Мы расскажем, почему в идеале организации должны развернуть систему оркестрации данных, которая работает внутри мультиоблачной среды или ЦОД и может перемещать данные во всех направлениях между этими платформами. Причем эффективность и продуктивность оркестрации данных зависит от программного уровня инфраструктуры хранения. В конце статьи мы дадим рекомендации для успешной оркестрации данных.
Рост данных продолжается
Рост объемов данных остается беспрецедентным. Согласно отчету Seagate Rethink Data на основе исследования IDC, объем данных увеличивается на 42,2% в год. Корпоративные данные поступают из огромного множества источников. Они находятся повсюду — на устройствах, на границе сети и в центральной системе, состоящей из множества уровней публичных, частных и гибридных облаков, которые вместе образуют мультиоблачную архитектуру, о которой мы писали чуть раньше. Все более сложные перемещения данных по большому многообразию экосистем существенно затрудняют управление. Управлять корпоративными данными становится все сложнее, и в будущем эта тенденция сохранится.
И это еще не все. Данные всех видов теперь имеют гораздо большую потенциальную ценность, чем раньше, благодаря развитию инструментов расширенной аналитики, искусственного интеллекта и машинного обучения. Вот почему каждая организация должна сохранять, отслеживать и использовать все эти данные. Согласно исследованиям IDC, приведенным в отчете Rethink Data, предприятия используют только 32% данных — остальные 68% пропадают напрасно.
Поэтому современным распределенным предприятиям требуются новые методы перемещения и оркестрации данных.
Более эффективная оркестрация данных: с чего начать?
Большинство ИТ-руководителей знают, что им нужно реализовать подход DataOps, которые объединяет тех, кто создает данные, и тех, кто их использует. Сегодня только 10% организаций говорят о том, что полноценно используют DataOps по всему предприятию. Согласно IDC, реализация подхода DataOps в совокупности с другими решениями по управлению данными позволит существенно повысить лояльность клиентов, доход и прибыль. И это далеко не полный список преимуществ. Подробнее с концепцией DataOps можно ознакомиться в нашей статье «Бизнес без данных — деньги на ветер».
Руководители должны оценить четыре этапа жизненного цикла данных и понять, как эти этапы влияют на способность организации эффективно использовать свои данные. Особенно важно разобраться, как используются данные, где они хранятся, как перемещаются и как их защитить. Чтобы извлекать из данных пользу, нужно подготавливать их к использованию, управлять их хранением, обеспечивать сбор всех необходимых данных, гарантировать безопасность собранных данных и предоставлять доступ к разрозненным массивам данных.
Если организации не наладят эффективное выполнение всех этих задач, они упустят возможность использовать один из своих самых ценных активов.
Этапы жизненного цикла данных
Жизненный цикл данных определяется операциями с ними на протяжении их существования. Данные находятся в движении, перемещаясь от источника в точку первоначального приема, а оттуда в системы хранения и анализа. На протяжении всего жизненного цикла и при перемещении по инфраструктуре вычислений, хранения и сети данным нужна защита. Жизненный цикл состоит из четырех этапов.
Рождение данных
Это этап создания данных. Существует множество источников данных с разными характеристиками, которые необходимо учитывать. Например, датчики на производственном оборудовании или беспилотных автомобилях генерируют огромные объемы данных. Непрактично было бы передавать все эти данные в центральную систему обработки. Вместо этого их можно обрабатывать прямо в месте создания, на границе сети, а затем отправлять результаты первоначальной обработки в центр по проводной сети или сохранять на физических устройствах хранения, если объем слишком велик, а скорость имеет решающее значение.
В некоторых случаях необходимо собрать абсолютно все данные, и тогда их можно передавать в масштабируемые хранилища с низкой задержкой. Если приложению нужны все данные, но не срочно, лучше загружать их партиями в частное или публичное облако.
Прием данных
Организация получает данные и берет их под свой контроль. Основные сложности на этом этапе — большой объем данных, скорость приема, безопасность и проверка. В некоторых случаях данные можно кэшировать локально и передавать пакетами. Например, поток данных временных рядов можно анализировать локально, чтобы как можно скорее выявлять аномалии. Затем данные можно передавать потоком или пакетами в постоянное хранилище. В некоторых случаях можно развернуть на границе сети модели машинного обучения, чтобы предварительно проверять и анализировать данные, а затем отправлять только результаты.
Анализ и консолидация данных
Здесь данные используются в бизнес-процессах. Это может быть что угодно — от выполнения транзакций до обучения алгоритмов машинного обучения. Раньше большие наборы данных имели ограниченное применение, но с внедрением машинного обучения все изменилось. Качество моделей машинного обучения зависит от комбинации алгоритмов и данных. Обычно модель можно улучшить, дав ей еще больше данных для обучения. Модели машинного обучения учатся замечать исключения и отклонения, влияющие на прогнозы, так же, как и люди, — накапливая опыт. Одна из самых сложных, если не сказать невыполнимых, задач управления данными — определить, какие данные понадобятся в будущем. Данные, которые кажутся бесполезными сегодня, могут иметь большую ценность завтра. Например, беспилотные автомобили с трудом распознавали пешеходов в светоотражающих жилетах на поворотах. Инженеры использовали изображения с метаданными из существующих наборов, чтобы найти дополнительные примеры и обучить на них модель.
Поскольку совершенно невозможно угадать, какие данные потребуются в будущем, при этом они используются для создания ценной интеллектуальной собственности в виде моделей машинного обучения, организациям приходится на всякий случай сохранять практически все свои данные.
Архивирование данных
Четвертый и последний этап жизненного цикла данных — архивирование. На этом этапе пригодится комплексная платформа оркестрации, охватывающая всю инфраструктуру от ЦОД до облака. Раньше для этой цели можно было использовать лучшие устройства и ПО для хранения, но сейчас все изменилось. Каждый компонент этого набора инструментов локально оптимизирует часть жизненного цикла, но предприятиям требуется эффективное глобальное решение.
Движение данных в организации
Выше мы привели четыре этапа жизненного цикла данных. При этом данные постоянно находятся в движении, перемещаясь от источника в точку первоначального приема, а оттуда в системы хранения и анализа. А затем архивируются. Здесь стоит более подробно рассмотреть движение данных в организации.
Организациям следует оценить, как данные перемещаются по устройствам, и развернуть решение, которое будет отвечать за оркестрацию данных по всей инфраструктуре. Здесь нужно учитывать несколько классов инфраструктуры хранения.
Большая часть данных, которые нуждаются в управлении и первичном анализе, создается на конечных устройствах. Это могут быть смартфоны, датчики Интернета вещей или автоматическое оборудование.
Не все данные с конечных устройств напрямую передаются в ЦОД или облако. Фильтрацию, объединение и предварительный анализ можно выполнять ближе к источнику. Это называется граничными вычислениями. С одной стороны, они позволяют сразу анализировать данные, а с другой — требуют дополнительного управления. Локальную обработку удобно использовать, когда приложениям требуется принимать решения в реальном времени. Более глубокий анализ, обработка с помощью искусственного интеллекта или машинное обучение происходят в централизованном расположении. Чтобы использовать данные по назначению и исследовать их для более эффективного применения, специалисты по управлению данными должны передавать большой объем данных в центр. Где они уже будут использоваться для совершенствования аналитических моделей. Администраторы СХД должны найти самый простой и эффективный способ защищать и перемещать данные с границы сети.
Если данных немного, можно использовать сети 5G, но для больших объемов это слишком дорогой способ. Проводные сети дешевле и мощнее, но не всегда доступны в нужном месте.
В ЦОД сосредоточены сервисы вычислений и хранения, и обычно именно там организации размещают свою инфраструктуру хранения данных. Все чаще ЦОД дополняются облаком. Сочетание локальных и облачных ресурсов называется гибридной средой и активно набирает популярность, особенно для хранения данных. Здесь мы вновь рекомендуем обратиться к статье, посвященной мультиоблачной стратегии.
Как можно видеть, данные перемещаются по инфраструктуре организации разными способами — от границы сети, через каналы приема и аналитические рабочие процессы, выполняющиеся в ЦОД или публичных облаках.
Требования к оркестрации данных в любом масштабе
Еще раз подчеркнем, что для управления потоками данных требуется программное обеспечение, отвечающее за оркестрацию по всей инфраструктуре. Но каким требованиям должна удовлетворять оркестрация? Что следует учитывать при разработке политик оркестрации данных?
Одно из первых требований к оркестрации данных — определение масштаба. Организациям нужны способы эффективно перемещать петабайты данных по системам хранения. Если использовать для этого сети, это надолго займет почти всю их пропускную способность. Чтобы переместить 20 ТБ данных на скорости 100 Мбит/с, потребуется больше 20 дней. Даже если это гигабитная оптоволоконная сеть со средней стабильной скоростью 800 Мбит/с, понадобится 2,5 дня для передачи 20 ТБ данных и почти неделя для 50 ТБ. Перемещать терабайты и тем более петабайты данных по сетям — слишком медленно и дорого.
Нужна дополнительная инфраструктура, в которой можно быстро загрузить данные на материальные носители, а затем отвезти их в ЦОД. Для этого потребуется уровень оркестрации, который будет координировать поток данных. Чтобы доставить данные в пункт назначения, понадобится управление на основе политик. Практически невозможно управлять потоком данных, контролируя каждый набор данных или рабочую нагрузку. Лучше настроить политики, которые будут определять, как перемещать и хранить данные в зависимости от их атрибутов.
Например, как правило, данные при передаче необходимо шифровать. Для этого нужно использовать определенный алгоритм и ключ шифрования. У ключей шифрования, в свою очередь, есть собственный жизненный цикл, за который отвечает служба управления ключами. При хранении данным обычно тоже требуется шифрование, и это должно быть указано в политиках управления данными.
У наборов данных разные требования к скорости передачи. Некоторые данные нужно анализировать сразу после создания — например, данные с датчиков Интернета вещей, чтобы быстрее выявлять потенциальные проблемы, или данные о транзакциях по кредитным картам, чтобы снизить риск мошенничества.
Многим бизнес-приложениям данные не нужны так срочно. Некоторые данные можно передать на следующий день, и они все равно будут иметь ценность. Например, сеть розничных магазинов может загружать все данные о запасах ночью, чтобы спланировать логистику на следующие несколько дней.
Еще один важный фактор, который необходимо учитывать для успешной оркестрации, — это объем данных. Объем данных с датчиков, например, зависит от числа датчиков и частоты передачи измерений. Скорость прироста данных зависит от масштаба развертывания датчиков. Если речь идет о складе, то объем данных определяется числом имеющихся товаров, а скорость прироста — добавлением новых товаров.
При разработке политик оркестрации данных нужно подобрать методы перемещения данных в зависимости от скорости передачи, ожидаемых объемов и мер безопасности.
Политики должны быть основаны на метаданных о наборах данных. Часто метаданные добавляются в виде тегов, которые используются для интеграции, выбора и фильтрации на различных этапах жизненного цикла данных.
Проблемы сохранения и анализа данных
Данные — такой же важный актив, как капитальное имущество и интеллектуальная собственность. Поскольку совершенно невозможно угадать, какие данные потребуются в будущем, организациям приходится на всякий случай сохранять практически все свои данные. И здесь стоит поговорить о проблеме сохранения данных.
Уже имеющиеся и ожидаемые объемы данных побуждают многие организации сокращать затраты на хранение и перемещение данных. Эти затраты нужно сопоставить с потенциальным ущербом от потери данных. Поскольку все больше организаций используют методы анализа и обработки данных (data science), а также модели машинного обучения, они открывают для себя новые способы использовать данные, которые раньше казались бесполезными.
В высокораспределенных средах данные могут перемещаться по сторонним сетям, например, 5G, и тогда встает вопрос о стоимости и безопасности передачи. Сторонние сети помогают ускорить доставку данных, но обходятся дороже, чем другие методы. Потенциальная бизнес-ценность моментального доступа к данным должна превосходить расходы на быстрые, но дорогие способы передачи данных.
Разумеется, ЦОД — это не конечный пункт. Оттуда данные могут перемещаться в облако, затем в другое облако и обратно в ЦОД. Одна из главных сложностей в этой ситуации — недостаток стандартизированных инструментов для перемещения данных. Не существует универсального способа передачи терабайтов данных для любого облака — у каждого вендора собственные методы.
В идеале организации должны развернуть систему оркестрации данных, которая работает внутри мультиоблачной среды или ЦОД и может перемещать данные во всех направлениях между этими платформами.
Анализ данных в большом масштабе
Специалисты по машинному обучению хорошо понимают, что качество модели зависит как от алгоритмов, так и от самих данных. Поскольку алгоритмы прозрачны и хорошо известны, часто именно данные определяют итоговый результат. Еще один общеизвестный факт о машинном обучении — невозможно заранее узнать, какие данные пригодятся.
Иногда тесты показывают, что модель не работает в определенных условиях, и тогда нужно целенаправленно обучить ее в этой конкретной области на основе подходящих данных. Найти их будет несложно, если они хорошо упорядочены и снабжены понятными тегами.
Долгосрочная стратегия создания интеллектуальной собственности на основе данных должна быть направлена на сохранение потенциально ценных данных. Потеря данных происходит по разным причинам — например, организация настроила их удаление через определенный период, чтобы сэкономить скудные и дорогие ресурсы. Сейчас это уже не такая серьезная проблема. Из-за высокой стоимости передачи данных по сетям 5G организации могут объединять данные на конечных устройствах перед их отправкой в ЦОД или облако. Однако объединение увеличивает задержку и не всегда подходит для данных, которые должны поступать в реальном времени. Возьмем, к примеру, данные временных рядов о производительности станка. Если объединять их и отправлять раз в минуту, мы можем упустить отклонения, заметные при передаче данных каждые 5 секунд.
Ценность данных будет возрастать по мере того, как организации будут находить новые способы их использования, но уже сегодня они открывают широкие возможности. Их нужно сохранять, особенно есть учесть, что это требует все меньше затрат.
Оркестрация на основе программного обеспечения
Эффективность и продуктивность оркестрации данных зависит от программного уровня инфраструктуры хранения. Программное обеспечение отвечает за важные аспекты управления данными — защита, минимизация операционных издержек, оптимизация расходов и использование политик.
ПО для оркестрации данных позволяет сократить расходы с помощью политик, которые, в свою очередь, основаны на отслеживании источника данных и других метаданных. Если данные хорошо упорядочены, можно использовать искусственный интеллект, чтобы принимать решения о приеме, перемещении, хранении и обработке данных.
Автоматические сервисы могут применять различные политики при движении данных по инфраструктуре хранения. Администраторы хранения данных могут управлять процессами с помощью приложений, которые не требуют VPN или физического подключения к сети.
Политики интегрируются в систему обработки конвейера данных. Например, можно передавать небольшие и ценные наборы данных по сети, а остальные — на материальных носителях.
Рекомендации для успешной оркестрации данных
Наконец, позвольте привести рекомендации для успешной оркестрации данных.
При создании системы оркестрации данных необходимо учитывать требования регуляторов к использованию, передаче, конфиденциальности и безопасности данных, которые зависят от отрасли и характеристик самих данных. Удовлетворить эти требования без лишних затрат бывает весьма проблематично. Но с этим поможет оркестрация данных. Например, организации могут отслеживать целостность данных с помощью цифровых отпечатков или хеш-кода. Если отпечаток не совпадает с ожидаемым, файл можно поместить на карантин, чтобы его проверил администратор данных. В системе комплаенса также может использоваться отслеживание с помощью блокчейна и отслеживание источника данных.
Кроме того, нужно контролировать, кто имеет доступ к данным. Если данные дают конкурентное преимущество, зачем хранить их у облачного провайдера, который в будущем может стать вашим конкурентом?
Данные нуждаются в защите на протяжении всего жизненного цикла, поэтому в системе оркестрации данных необходимо реализовать корень доверия. Кроме того, необходимо согласованно собирать, хранить и контролировать информацию об источнике данных. Организациям нужны механизмы, гарантирующие целостность и достоверность данных, а также защищающие конфиденциальность чувствительных данных.
Рекомендуется использовать программное обеспечение с открытым исходным кодом и типовые СХД с программно-определяемым хранилищем, чтобы оптимизировать расходы. При таком подходе организация не будет привязана к одному поставщику.
Еще одна полезная рекомендация — не спешите удалять данные. Лучше накапливать большие наборы данных, которые можно использовать для анализа и машинного обучения, чем пытаться сэкономить на хранении в ущерб возможности создавать качественные и эффективные модели.
Данные — источник конкурентного преимущества в будущем
Нарастающие объемы данных, распределенных по обширной инфраструктуре, — это источник конкурентного преимущества. Нельзя упустить эту возможность. Самый важный шаг реализации успешной стратегии оркестрации данных — обдумать, как развивать корпоративную ИТ-инфраструктуру с поддержкой масштабирования. Чтобы быстро и эффективно собирать, перемещать и анализировать данные, а затем извлекать из них практическую ценность. Используя при этом распределенную архитектуру хранения и обширный уровень управления, способный доставить данные туда, где они необходимы.
Узнать больше о последних решениях корпоративного класса по эффективному управлению данными можно тут: