Ожидается, что в 2022 г. edge-технологии будут набирать обороты, но прежде чем строить свою стратегию, стоит выслушать советы опрошенных порталом Enterprisers Project экспертов.
Станет ли
В конечном счете, это всего лишь цифра, хотя и большая. Могут быть и более качественные признаки созревания периферийных вычислений с точки зрения архитектурных подходов, технических возможностей, сценариев использования на предприятиях, тактики обеспечения безопасности и т. д.
«Хотя мы видим отголоски старых архитектур в некоторых edge-развертываниях, мы также видим развивающиеся edge-тенденции, которые являются по-настоящему новыми или, по крайней мере, совершенно отличными от того, что существовало ранее, — отмечает Гордон Хафф, технологический евангелист Red Hat. — Они помогают ИТ- и бизнес-лидерам решать проблемы в различных отраслях, от телекоммуникаций до автомобилестроения, например, в условиях роста объемов данных датчиков и машинного обучения».
ИТ-лидеры не часто решают бизнес-проблемы без плана, именно поэтому периферийные стратегии — и связанные с ними категории, такие как IoT и МО — занимают важное место в их дорожных картах. Например, 61% респондентов исследования Red Hat «2022 Global Tech Outlook» сообщил о планах запуска IoT- или периферийных рабочих нагрузок (или и того, и другого) в ближайшие 12 месяцев.
Ниже представлены мнения ряда ИТ-лидеров и экспертов в области периферийных вычислений, проливающие свет на некоторые пробелы, если не ловушки, разрушающие рентабельность инвестиций, которые, по их мнению, имеют место в корпоративных edge-стратегиях. Речь пойдет о пяти аспектах, которые нужно обязательно учесть в своих планах по внедрению периферийных вычислений.
1. Не стоит слишком сильно полагаться на универсальные определения понятия «периферия»
Как и в случае с другими крупными технологическими терминами, в отрасли существует тенденция к догматическим определениям, которые не учитывают повседневную реальность конкретной команды или организации. К тому же универсальное определение подразумевает универсальную стратегию.
Универсального решения не существует, и это первый возможный пробел в вашей стратегии, говорит Шамик Мишра, технический директор по подключенности Capgemini Engineering, поэтому не пытайтесь втиснуть свои цели в рамки стратегии (или технологической платформы), которая не подходит.
«Периферия имеет различные интерпретации, — отмечает он. — Мобильное устройство может быть периферийным в той же степени, что и локальный микроЦОД».
В одной компании «периферийный сервер» может означать специализированное оборудование, а в другой — обычный сервер в необычном месте. То же самое относится и к сценариям использования. Хотя повторяющиеся сценарии, построенные на отраслевом или ином контексте, будут появляться и дальше, корпоративные стратегии должны учитывать специфику предприятия.
«Применение периферийных вычислений варьируется от отрасли к отрасли и от региона к региону, — говорит Шамик Мишра. — В то время как инспекция с помощью беспилотников может представлять интерес в одной географии, этот же сценарий использования может быть неинтересен в другой».
Это не означает, что не существует универсальных проблем. Хорошим примером является безопасность: edge-стратегия, которая игнорирует безопасность, является неполной. Автоматизация — еще один общий знаменатель. «Отсутствие автоматизации может также привести к увеличению затрат на обслуживание, что может свести на нет преимущества edge для бизнеса, поэтому необходимо заранее продумать адекватные стратегии автоматизации», — говорит Шамик Мишра.
2. Сбрасывать со счетов управление изменениями можно только на свой страх и риск
Для опытных ИТ-руководителей это скорее вежливое напоминание, чем свежая новость, но все же стоит сказать: игнорировать влияние значительной инициативы по внедрению периферийных вычислений на повседневную работу людей — не лучшая идея.
«Один из самых больших пробелов в edge-стратегии — это неспособность привлечь все необходимые заинтересованные стороны, — говорит Джош Джонсон, корпоративный архитектор Akamai. — Перенос рабочих нагрузок на периферию — это не просто „lift-and-shift“, а проект, который включает в себя изменения в ряде команд».
Внутри самого ИТ-отдела практически каждая широкая функция потребует некоторого обучения и/или адаптации, особенно если вы еще не используете большое количество рабочих нагрузок в архитектуре edge и возможно опираетесь на прошлый опыт. Вот примеры:
- разработчики. Тем, кто в основном отвечает за написание кода, может потребоваться изучить передовые методы разработки и развертывания edge-систем. «Переход от среды с относительно небольшим количеством серверов в нескольких локациях к среде с тысячами отдельных небольших локаций требует совершенно иных проектных и архитектурных решений», — говорит Джонсон;
- операторы/DevOps/SRE. Людям, ответственным за эксплуатационные потребности, такие как инструментарий, мониторинг и управление конфигурацией, возможно, придется пересмотреть свои методы и инструменты для периферийных вычислений. «Без видимости кода, выполняемого на периферии, трудно убедиться, что приложение работает так, как ожидалось», — отмечает Джонсон;
- безопасность. В условиях, когда все больше рабочих нагрузок переходит на edge-вычисления (независимо от того, как организация понимает этот термин), безопасность, естественно, станет важным направлением. Это потребует изменений в традиционных руководствах по безопасности, так же как аналогичной эволюции потребовал и более широкий переход к распределенным ИТ-средам (гибридное и мультиоблако). «Команды безопасности должны изменить свою практику, чтобы обеспечить защиту приложений на периферии, — считает Джонсон. — Код и данные живут на периферии вне защиты традиционных брандмауэров в дата-центре».
3. Отдавайте приоритет последовательности, предсказуемости и повторяемости
Edge-стратегии, успех которых зависит от одноразовых «снежинок», приведут к долгосрочным головным болям.
Это еще одна область, где опыт работы с гибридной облачной архитектурой, вероятно, принесет пользу периферийному мышлению: если вы уже понимаете важность автоматизации и повторяемости, скажем, для запуска сотен контейнеров в производстве, то вы увидите аналогичную ценность и в периферийных вычислениях.
«Следуйте стандартизированной архитектуре и избегайте фрагментации — кошмара управления сотнями различных типов систем, — советует Шахед Мазумдер, глобальный директор по телекоммуникационным решениям компании Aerospike. — Последовательность и предсказуемость являются ключевыми в развертывании периферийных систем, так же как и в развертывании облачных систем».
Действительно, это та область, где связь между облаком и периферией становится все более глубокой. Некоторые из тех же подходов, которые делают гибридное облако выгодным и практичным, будут перенесены на периферию. В целом, если вы уже решаете некоторые сложные задачи, связанные с гибридным облаком или мультиоблачными средами, то вы на правильном пути.
«Периферийные среды гетерогенны по своей природе, и организациям следует подготовиться к решению этой проблемы, — говорит Саурабх Мишра, старший менеджер по IoT в SAS. — Это особенно актуально при попытке создать равные условия на периферии с помощью контейнеров и Kubernetes. Это также важно при переносе рабочих нагрузок из облака на периферию, которая играет все большую роль».
4. Определитесь, как вы будете управлять в масштабе
Из пункта 3 напрямую вытекает пункт 4: заранее определитесь, как вы будете управлять всем после того, как начнете производственную эксплуатацию. Как и в случае с управлением облаком, централизованная платформа — хорошая идея для любого значительного внедрения.
«При инвестировании в платформу важно остановиться на той, которая позволяет централизованно управлять edge-инфраструктурой и рабочими нагрузками, — говорит Саурабх Мишра. — Хотя большинство сценариев использования периферийных систем стараются выполнять рабочие нагрузки с постоянным подключением к облаку, важно иметь платформу управления, которая позволяет изменять конфигурацию и переводить новые рабочие нагрузки из облака в edge-среду. Отчеты о состоянии и оповещения от периферии до облака — это то, что способствует масштабированию и внедрению на предприятиях».
Отношения между периферией и облаком должны быть взаимовыгодными. Например, Саурабх Мишра считает, что есть смысл разрабатывать сценарии использования, которые опираются как на периферийные, так и на облачные рабочие нагрузки, где локальная обработка и оповещение происходят на периферии, а глобальное представление «на уровне всего парка» создается в облаке.
5. Менталитет «создай один раз, запускай где угодно» не подходит для всех рабочих нагрузок
Облачные и периферийные вычисления имеют естественную взаимосвязь, то же можно сказать и о машинном обучении и edge/IoT-сценариях использования.
Однако некоторым командам трудно представить себе, что модель, которая прекрасно работала в локальной сети или в облаке гиперскейлера, может давать сбои в периферийной среде.
«Мы видим, как компании создают и обучают потрясающие модели, но в итоге не могут использовать ИИ/МО на периферии, — говорит Пол Легато, вице-президент Wallaroo по разработке платформы. — Почему? Потому что эффективность выполнения критически важна. Необходимо выжать все возможное из ограниченных вычислительных ресурсов».
Рабочие edge-нагрузки становятся все более сложными, и ИТ-лидеры и команды должны помнить о том, что философия «запускай где угодно», которая применяется в других современных парадигмах ПО, может оказаться более сложной в граничной архитектуре. Нагрузки MО являются ярким примером этой проблемы.
«МО на периферии — это еще и запуск моделей на сильно ограниченном оборудовании, — говорит Легато. — В облаке вы можете нажать кнопку и получить новейшую и лучшую машину с 128 процессорными ядрами, но на периферии вы будете работать на крошечном маломощном промышленном ПК или камере наблюдения с минимально возможными мощностью процессора и объемом оперативной памяти».
