Разработчиците обикновено разбират, че техните времена за изпълнение на обработка съществуват или в техните собствени центрове за данни, или са насочени към страната на клиента. Но какви възможности за изграждане на следваща итерация на разпределени системи съществуват между клиента и сървъра?

Можем ли да изпратим код до краищата на нашата мрежа, за да вършим реална работа, вместо просто да конфигурираме таблици за маршрутизиране или други IP правила тук? Какво ще стане, ако същите времена за изпълнение, към които се насочваме на нашите вътрешни сървъри, съществуват на ръба, нов функционален ръб. Ще осигури ли това интересни и ценни случаи на употреба или е просто още едно средство за конфигуриране на мрежи, като същевременно предоставя малко функционалност отвъд това, което традиционно е възможно?

Какво е крайно изчисление?

Edge computing е всеки програмируем интерфейс и среда за изпълнение, изградени върху операционни системи, работещи на мрежови устройства между крайни потребители и хостинг съоръжения, облак или по друг начин. Тези устройства обикновено съществуват в следните три области:

  • Вътрешен системен ръб: рутери, балансьори на натоварването, API шлюзове и обратни проксита като NGINX, F5, HAProxy, AWS API Gateway или други шлюзове като Traefik или Kong
  • Обществена мрежа: ISP, WAF, CDN като Akamai и Cloudflare
  • Мобилни устройства и интернет на нещата: телефони, устройства, свързани с интелигентен дом, малинови PI и домашни медии

Приложения на Edge Computing

CDN базирани времена за изпълнение като наскоро обявените от Cloudflare „Cloudflare Workers“, които могат да се използват за оформяне на публичен интернет трафик, справяне с оптимистично затопляне на кеша, пренасочване по по-интелигентни начини към други региони, базирани на всякакъв набор от условия, предизвикване на подозрителна активност на ръба, защита на основните процеси от наводнения или престъпен трафик, както и изтегляне на допълнителни метаданни и данни от крайни потребители на техните локални машини, за да се ускорят заявките или да се върне повече богата информация към техните заявки.

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

  • Използвайте персонализирана логика, за да решите кои заявки могат да се кешират на ръба, и ги канонизирайте, за да подобрите скоростта на попадение в кеша.
  • Разширете HTML шаблоните директно на ръба, извличайки само динамично съдържание от вашия сървър.
  • Отговаряйте на заявки без състояние директно от периферията, без изобщо да се свързвате с вашия първоначален сървър.
  • Разделете една заявка на множество паралелни заявки към различни сървъри, след което комбинирайте отговорите.
  • Внедрете персонализирано балансиране на натоварването и логика за преодоляване при срив.
  • Отговаряйте динамично, когато вашият първоначален сървър е недостъпен.
  • Разширете HTML шаблоните директно на ръба, извличайки само динамично съдържание от вашия сървър.
  • Отговаряйте на заявки без състояние директно от периферията, без изобщо да се свързвате с вашия първоначален сървър.
  • Разделете една заявка на множество паралелни заявки към различни сървъри, след което комбинирайте отговорите.

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

Мрежови маршрутизатори, обратни прокси сървъри и API Gateway функционалните времена за изпълнение могат да оформят вътрешния трафик, да внедрят персонализирано асинхронно затопляне на кеша или друго оптимистично управление на ресурсите, което може да се използва за намаляване на забавянето, създаване на допълнителна сигурност контролира или по-интелигентно разпределя натоварването в системата в рамките на център за данни.

Текущи реализации:
# AWS — Ламбда функциите са средствата, чрез които API Gateway на AWS може да прилага персонализирани правила за функции като проверки на състоянието, authN/Z, оптимални алгоритми за маршрутизиране и други взаимодействия в рамките на шлюз. Чрез комбинация от AWS Cloudtrail, API Gateway и Lambda мощни приложения могат да бъдат изградени по разпределен начин, за да изолират допълнително вашия EC2, база данни или други основни инфраструктурни слоеве. Следващата диаграма илюстрира клиентско влизане, при което основната система е защитена чрез функционална проверка на границите за удостоверени клиенти чрез проверка на криптирани заглавки/бисквитки, преди изобщо да докоснете вашите вътрешни услуги:

# NGINX — nginScript е JavaScript интерфейс, внедрен върху NGINX рутери, позволяващ множество различни сценарии за производителност, качество и интелигентно маршрутизиране. nginScript беше обявен преди около 2 години и работи върху най-големите рутери с отворен код, внедрени в базирани на linux уеб платформи днес. Тук NGINX използва подход на добавка, позволяващ на клиентите лесно да активират по-сложна конфигурация на JavaScript и слой за обработка.

Обобщавайки

Edge функциите имат редица потенциални случаи на употреба, като например прихващане на всяка входяща HTTP заявка. Те позволяват на уеб, мобилни и IoT приложения да правят неща като форматиране на отговори на ръба, да гарантират, че само динамично съдържание се обслужва от вътрешни сървъри, да обработват по-сложни пътеки за сигурност и да изпълняват персонализирано балансиране на натоварването с по-проактивно управление при отказ.

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

В периферните изчисления трябва да се инвестира и те да станат част от сферата на знания на разработчиците и архитектите. Предприятието е все по-асинхронно, в периферните изчисления асинхронният подход е почти изискване, като се избягват блокиращи операции, които могат да причинят забавяне на мрежата, като същевременно се въвеждат повече точки на потенциално необработен системен срив. Досега преобладаващите езици за програмиране в това пространство поддържат собствени асинхронни модели като NodeJS и Go. Въпреки че определени повиквания за сигурност и оформяне на мрежа ще трябва да се обработват синхронно в нишката на заявката.

Повече интелигентност, повече възможности за предвиждане и изпреварване, повече допирни точки, които да помогнат за пълното разбиране на човешката и автоматизирана дейност. Наслаждавам се на потенциалните възможности, въпреки че в моето портфолио в момента използвам задържане с бъдещ подход за купуване.

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