Разработчики обычно понимали, что их среда выполнения обработки существует либо в их собственных центрах обработки данных, либо нацеленна на клиентскую сторону. Однако какие возможности для построения следующей итерации распределенных систем существуют между клиентом и сервером?

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

Что такое периферийные вычисления?

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

  • Внутренняя граница системы: маршрутизаторы, балансировщики нагрузки, шлюзы API и обратные прокси, такие как NGINX, F5, HAProxy, AWS API Gateway или другие шлюзы, такие как Traefik или Kong.
  • Предел общедоступной сети: ISP, WAF, CDN, такие как Akamai и Cloudflare.
  • Мобильные устройства и Интернет вещей: телефоны, устройства, подключенные к умному дому, устройства Raspberry PI и домашние мультимедиа.

Приложения пограничных вычислений

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

Текущие реализации:
# Cloudflare Workers - построены с использованием стандартного Service Workers API на основе движка Google V8 JavaScript, также используемого в Chrome и NodeJS. Сервисные работники могут направлять несколько подзапросов последовательно или параллельно, а затем объединять результаты в одно ответное сообщение. Cloudflare называет следующие возможные варианты использования своей новой рабочей среды:

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

# Akamai Cloudlets - кажущаяся надежной функциональная периферийная платформа, хотя подход здесь кажется более рыночным, где функции предоставляются Akamai и ее партнерами. Вероятно, разумно, что Akamai будет следовать более расширяемой модели, такой как AWS и Cloudflare.

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

Текущие реализации:
# AWS - функции Lambda - это средства, с помощью которых AWS API Gateway может реализовывать настраиваемые правила для таких функций, как проверки работоспособности, authN / Z, оптимальные алгоритмы маршрутизации и другие взаимодействия в шлюз. Благодаря сочетанию AWS Cloudtrail, API Gateway и Lambda мощные приложения могут быть построены в распределенном режиме для дальнейшей изоляции EC2, базы данных или других уровней базовой инфраструктуры. На следующей диаграмме показан вход в систему клиента, при котором основная система защищена функциональной пограничной проверкой для аутентифицированных клиентов путем проверки зашифрованных заголовков / файлов cookie, прежде чем когда-либо коснется ваших внутренних служб:

# NGINX - nginScript - это интерфейс JavaScript, реализованный поверх маршрутизаторов NGINX, позволяющий реализовать ряд различных сценариев производительности, качества и интеллектуальной маршрутизации. nginScript был анонсирован около 2 лет назад и работает поверх крупнейших маршрутизаторов с открытым исходным кодом, реализованных сегодня в веб-платформах на базе Linux. Здесь NGINX использует надстройку, позволяющую клиентам легко включить более сложный уровень конфигурации и обработки JavaScript.

Подведение итогов

У пограничных функций есть несколько потенциальных вариантов использования, например, перехват любого входящего HTTP-запроса. Они позволяют веб-приложениям, мобильным приложениям и IoT-приложениям выполнять такие действия, как форматирование ответов на периферии, обеспечивать обслуживание только динамического контента с внутренних серверов, обрабатывать более сложные пути безопасности и выполнять настраиваемую балансировку нагрузки с более проактивной обработкой аварийного переключения.

Снова и снова поднимаются обычные вопросы управления кодом, потребностей в операционных навыках, SDLC, CI / CD, тестирования и зрелости среды выполнения, и снова они представляют как риски, так и возможности для многих организаций.

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

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

Как ваша организация смотрит на край? Как новинка или как возможность еще больше продвинуть определение распределенного масштаба?