Наконец-то я понял, как объяснить граничные вычисления

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

Почему вязаные шапки для собак? Потому что они веселые!

И это хорошая аналогия, но прежде чем мы дойдем до нее, давайте определим каждую часть «периферийных вычислений».

Начнем с последнего.

(Обратите внимание, что «пограничные вычисления» также иногда называют «пограничными функциями» или «пограничными рабочими»)

Оглавление

* Что такое «вычислить»? * Где происходит «вычисление»? * Традиционные серверы * Клиенты * Генераторы статических сайтов * Облачные функции * Что такое «край»? * Сети доставки контента * Пользователи познают жизнь в 3D * Что такое «граничные вычисления»? * Преимущества * Ограничения * Когда следует использовать граничные вычисления? * Почему я должен волноваться? * Проблема скорости света * Обязательный блок статистики * Дело не только в деньгах * Заключительные мысли

Что такое «вычисления»?

Вычисления — это то, что происходит каждый раз, когда вы просите машину сделать что-то для вас. Например, когда вы запрашиваете у калькулятора произведение 5 x 7 (и в то же время задаетесь вопросом, чем были полезны все эти годы на уроках математики), калькулятор издаст несколько звуковых сигналов и ответит 35.

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

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

Для простоты я в основном сосредоточусь на создании HTML.

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

Отсюда и шляпы для собак.

Где происходит «вычисление»?

Здесь все становится немного сложнее. Некоторые люди могут сказать вам, что есть два места, где могут происходить вычисления: на сервере или в браузере (на компьютере пользователя).

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

Чтобы справиться с этим нюансом, я хочу рассказать об этом в 4 частях:

• Традиционные серверы
• Клиенты (браузеры)
• Генераторы статических сайтов
• Облачные функции

Вы можете пропустить эти разделы, если вы уже знакомы, но вы пропустите всю мою аналогию.

Традиционные серверы

На традиционном сервере компьютер запускает программное обеспечение, выбранное вами для выполнения кода, который вы написали для возврата HTML всякий раз, когда приходит запрос. Использование сервера для генерации HTML обычно называется Server-Side-Rendering (SSR).

Компьютер может быть локальным (или «локальным») компьютером, которым вы владеете и который находится в вашем здании, или он также очень распространен в «облаке», когда в основном арендуется компьютер, которым владеет кто-то другой и который находится в их здании. .

Эти серверы работают 24×7 (в идеале) и готовы принимать трафик в любое время. Вы также можете настроить отдельные длительные задачи или запланированные задачи с заданием cron.

Это удобно, но есть и недостатки:

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

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

Серверы похожи на коммерческое рабочее пространство 🏭

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

Это красивый офис с кирпичной кладкой и большим количеством естественного света. Мы можем нарисовать его так, как мы хотим, и изменить его по мере необходимости. Но есть и недостатки.

Некоторым людям приходится преодолевать долгий путь, чтобы добраться до нашего здания. Мы также должны оплачивать счета (аренда, электричество, интернет) независимо от того, сколько собачьих шапок мы продаем (я знаю, что мы собираемся продать миллиарды долларов, но все же). И когда кто-то приводит свою собаку, чтобы купить новую шапку, а собака какает на траву на выходе, угадайте, кому придется ее убирать.

Клиенты

Когда мы говорим слово "клиент", большинство людей думают о клиенте. Например: «У меня будет миллиард клиентов, когда этот бизнес по производству собачьих шапок наберет обороты». В случае веб-разработки «клиентом» является браузер пользователя.

После того, как пользователь запрашивает наш веб-сайт, мы можем указать браузеру загрузить некоторый JavaScript, и когда это JavaScript выполняется, он может внедрить HTML на страницу. На самом деле мы даже можем использовать JavaScript для создания всего приложения.

Обычно это называется рендерингом на стороне клиента (CSR).

Создание HTML-кода на стороне клиента — это здорово, потому что оно может создавать более динамичные взаимодействия, которые ощущаются быстрее, поскольку вам не нужно ждать перезагрузки страниц.

Мы даже можем использовать такие инструменты, как Service Worker или WebAssembly, чтобы сделать эти вычисления менее эффективными.

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

Вот как я вижу недостатки:

* Пользователи должны загружать больше данных (JavaScript). * У нас не может быть секретов, таких как ключи API, потому что исходный код доступен. * На производительность сильно влияет устройство пользователя. * То, что мы можем сделать, зависит от устройства и браузера пользователя. *

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

Визуализация на стороне клиента похожа на наборы для шитья своими руками 🧶💉

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

Некоторым это может подойти, но не всем.

Генераторы статических сайтов

Статические генераторы сайтов (SSG) интересны тем, что вместо того, чтобы создавать веб-страницу по мере поступления запросов, они заранее создают все страницы веб-сайта. Результатом является набор статических папок и файлов (HTML, CSS, JavaScript), представляющих веб-сайт.

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

Этот подход технически попадает в корзину SSR, потому что вы не используете браузер для выполнения вычислений. Вы используете какой-то язык программирования для заблаговременного создания страниц на компьютере, которым вы управляете (ваш ноутбук, конвейер сборки и т. д.).

Технически конечный результат не сильно отличается от того, если бы вы написали все эти HTML-страницы вручную, но использование SSG, вероятно, в конечном итоге быстрее и проще в работе.

Есть несколько преимуществ использования SSG. Генерируя HTML заранее, вы удаляете это время вычислений из запроса пользователя. Это может ускорить время отклика, поскольку им нужно только дождаться, пока сервер ответит статическим HTML-файлом. На его создание не тратится время, а это может иметь большое значение.

Поскольку вы имеете дело только со статическими файлами, которые не меняются при каждом запросе, SSG также отлично сочетается с сетями доставки контента. Я расскажу об этом чуть позже, но в результате вы получаете еще более быстрые ответы, потому что вы можете устранить большую часть задержки.

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

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

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

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

Еще одна ошибка SSG заключается в том, что для создания каждой страницы требуется время. Если вам нужно сгенерировать десятки или сотни тысяч страниц, это может занять много времени. И когда вы публикуете новый контент или изменяете существующий контент, вам может потребоваться предварительно собрать все. Это может быть неудачным.

Генераторы статических сайтов похожи на готовые собачьи шапки 🐶🎩

Если бы я сравнил это с продажей вязаных шапок для собак, SSG подобен продаже готовых шапок вместо того, чтобы вязать их по запросу. Когда покупатель находит то, что ему нужно, он может просто взять его с полки и оформить заказ; не дожидаясь, пока кто-нибудь свяжет его.

Но что, если они хотят чего-то персонализированного, например, сшитого на заказ или в их любимом цвете? У меня может не быть в наличии. Некоторые сообразительные бизнесмены могут сказать, чтобы они забыли о них и делали только готовые вязаные шапки из-за маржи и трудозатрат (я понятия не имею, о чем говорю). Другие консультанты могут подумать, что стоит добавить больше сотрудников (сложность) для поддержки вязания по запросу, а также изготовления и хранения готовых вязаных шапок.

В конце концов, это зависит от вашего варианта использования. Предварительно связанные шапки (SSG) могут быть великолепны, вязание по запросу (SSR) может быть лучше, или, возможно, вы поддерживаете оба варианта.

Облачные функции

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

Обратите внимание, что в этой системе вам не нужно выделять, развертывать, обслуживать или обновлять какой-либо сервер. Вот почему их также называют «бессерверными функциями» или просто «бессерверными» (их также иногда называют «лямбда-функциями»).

Несмотря на «бессерверную» природу, все же задействован сервер. Это просто чужой сервер. Это ставит его в сферу SSR.

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

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

Несмотря на то, что это может показаться необычным, весь этот подход имеет некоторые преимущества.

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

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

В дополнение к языковым ограничениям вы, вероятно, заметите ограничения на доступные вычислительные ресурсы (ЦП, память), и у большинства провайдеров относительно короткие тайм-ауты. Эти сервисы предназначены для кратковременных операций.

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

Облачные функции похожи на роботов, обученных вязать собачьи шапки 🤖🧶💉🐶🎩

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

В отличие от спроса на готовые вязаные шапки для собак, эти клиенты хотят изготовленные на заказ шапки с их любимыми талисманами спортивного мяча. Если вы предпочитаете денверских такс, питтсбуллов, нью-йоркцев, ретриверов Golden Gate или чикагских хуахуа, индивидуальные запросы по запросу не станут проблемой для роботов-вязальщиц (облачные функции).

Что такое «преимущество»?

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

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

Вот где все становится немного нечетким. Должен ли «граница» состоять из веб-серверов или ваш смартфон может считаться узлом в сети? Разве устройства IoT тоже не являются «пограничными»? Какое минимальное количество узлов вам нужно, прежде чем вы сможете назвать сеть «краем»? Два? Должна ли сеть охватывать определенный регион, чтобы претендовать на статус «пограничного»?

Я не могу ответить на эти вопросы. Извиняюсь. Но я не думаю, что нам это нужно, пока мы понимаем, что цель состоит в том, чтобы уменьшить задержку за счет сокращения расстояния между пользователями и конечными точками. Следовательно, чем больше распределено количество устройств, тем лучше.

Давайте рассмотрим менее туманный пример того, каким может быть «преимущество».

Сети доставки контента

Сеть доставки контента (CDN) – это сеть глобально распределенных серверов, предназначенная для доставки статических ресурсов, таких как CSS, JavaScript, изображения, шрифты и т. д. Могут быть тысячи серверов, каждый со своей собственной копией ваших ресурсов.< /p>

Когда делается запрос на актив, например на фотографию моей собаки Наггет, CDN выясняет, где находится ближайший сервер, и отправляет запрос для обработки там. Изображение отправляется обратно пользователю lickity-split. Это относится к любым статическим объектам, которые они запрашивают, и это отличный способ повысить производительность.

CDN существуют уже давно, и они отлично сочетаются с такими вещами, как SSG выше. Вы можете заранее создать свой веб-сайт и обслуживать все это из CDN, и это будет очень быстро.

CDN похожи на магазины шаговой доступности 🏪

Помните приведенную выше аналогию, где мы обсуждали предварительное вязание шапок для собак, чтобы они были легко доступны, когда бы кто-нибудь ни пришел в наш магазин? А теперь представьте, что мы делаем то же самое, но также распространяем эти шляпы по нескольким магазинам по всему миру.

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

Для них это очень быстро и удобно.

Пользователи видят жизнь в 3D

Куда, черт возьми, я клоню? Оставайтесь со мной на мгновение.

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

* Расстояние между запросом и ответом (задержка). * Размер загрузки для анализа и выполнения ответа. * Возможности устройства зависят от оборудования, программного обеспечения и доступных ресурсов.

И это подводит меня к следующим советам. Когда дело доходит до сути, аллитерация лучше связности 🔥🔥🔥

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

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

Для идеального трехмерного опыта мы бы:

* Переместите вещи ближе к пользователям (например, CDN) * Работайте на серверах (например, облачных серверах/функциях) * Отправляйте объекты меньшего размера (упс 🥺)

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

Это, наконец, подводит нас к ответу на главный вопрос.

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

Первичные вычисления — это программируемая среда выполнения (например, облачные функции), распределенная по всему миру (например, CDN). Это здорово, потому что дает нам динамическую функциональность на стороне сервера, которая выполняется как можно ближе к пользователям.

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

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

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

Преимущества

Я вижу, что преимущества периферийных вычислений разделены на три разные группы.

Для пользователей :

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

Для разработчиков:

• Низкие барьеры для создания доказательств концепции.
• Последовательные среды выполнения (в отличие от браузеров).
• Команды несут соответствующие обязанности.
• Логика на основе местоположения.
• Нет серверов/инфраструктуры для управления.
• Секреты остаются тайной (в отличие от клиентской части).

Для заинтересованных сторон:

• Снижение нагрузки на исходные серверы повышает производительность, надежность и стоимость исходных серверов.
• Автоматическое масштабирование повышает общую производительность и надежность.
• Платите только за то, что используете.

Ограничения

Итак, мы пришли к выводу, что периферийные вычисления — это прекрасно, но не без недостатков ( ͡° ͜ʖ ͡°)

В настоящее время большинство платформ поддерживают JavaScript в виде пользовательских сред выполнения (изолятов V8). Таким образом, хотя функции языка поддерживаются, у вас может быть доступ только к очень ограниченному набору функций платформы. Он может не поддерживать все те функции, которые вы найдете в браузере или Node.js.

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

Когда вы вникаете в то, что происходит на самом деле, эти ограничения обретают смысл. Если вы собираетесь развернуть серверы в десятках или сотнях тысяч мест по всему миру, они должны быть как можно более легкими и быстрыми, а поскольку вычисления стоят денег, поставщики платформ должны накладывать некоторые ограничения на ресурсы и время.< /p>

Когда следует использовать граничные вычисления?

Решить, где выполнять вычисления, уже сложно. Вы должны учитывать задержку, размер загрузки, возможности устройства и т. д., прежде чем принимать решение. И, как мы отметили выше, у каждого предложения есть свои плюсы и минусы.

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

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

Что было раньше:

Клиентский JS -> Работник клиентской службы -> Облачные функции -> Традиционные серверы

Теперь у нас есть:

JS на стороне клиента -> Работник клиентской службы -> Пограничные вычисления -> Облачные функции -> Традиционные серверы

Посмотрим, смогу ли я помочь вам принять решение.

Признаки того, что у вас есть хороший вариант использования периферийных вычислений:

• Без сохранения состояния (не требует постоянной памяти или файлов).
• Это не займет много времени.
• Чувствителен к задержке
• Гиперлокальный

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

• Отслеживание состояния (требуется постоянная память или файловая система).
• Требуется много вычислительных ресурсов.
• Длительные операции — последовательные/водопадные запросы (могут увеличить задержку)

(обратите внимание, что приведенные выше пункты без сохранения состояния/с сохранением состояния не относятся к внешним источникам, таким как базы данных)

Некоторые распространенные варианты использования:

• Геолокация
• Быстрый автоматический поиск/упреждающий ввод
• Изменить запрос/ответ
• Управление переадресацией
• Персонализация на основе токенов (A/B-тестирование, пометки функций)
• Аутентификация без сохранения состояния (веб-токены JSON)
• Прокси/оркестрация API

Почему меня это должно волновать?

А теперь мы подходим к части шоу, посвященной принципу "если что-то не сломалось, не чини-это". Если вы прекрасно создавали веб-сайты без периферийных вычислений, зачем вообще об этом беспокоиться?

Ответ кроется в производительности.

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

Задача о скорости света

Со временем технологии совершенствуются; компьютеры становятся быстрее, хранилище становится больше, а сети могут обрабатывать больше данных.

Если я напишу программу для подсчета того, насколько сильно я люблю свою собаку, сегодняшним компьютерам потребуется 10 лет, чтобы вычислить ее. Через 10 лет компьютерам может понадобиться всего 10 миллисекунд. Однако в обоих случаях время, необходимое для того, чтобы сказать моей собаке, что я ее люблю, зависит от того, как далеко она находится.

Поэтому, пока мы не придумаем, как отправлять «Я люблю тебя НАСТОЛЬКО сильно» через червоточины, мы никогда не сможем отправлять сообщения со скоростью, превышающей скорость света. Это универсальная константа.

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

Вот пример из моего поста «Оптимизация переноса контента с помощью граничных вычислений". Он показывает, как периферийные вычисления могут сократить время поиска для перенаправления.

Без периферийных вычислений:

Пользователь запрашивает старый URL-адрес, старый сервер отвечает инструкциями по перенаправлению на новый URL-адрес, браузер перенаправляет запрос на новый URL-адрес, и, наконец, ответ отправляется пользователю.

С периферийными вычислениями:

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

Вы заметили, как я использую длину стрелок для обозначения физического расстояния? Умная! И я надеюсь, что это поможет донести мысль, но помимо стрелок на изображении, сколько времени мы реально можем сэкономить в наихудшем сценарии кругосветного путешествия…?

Возможно, около 300 мс.

Это подводит меня к моему экзистенциальному кризису:

• Действительно ли все дело только в скорости?
• Насколько важны 300 миллисекунд?
• Стоит ли сложность?
• Нравится ли собакам носить шляпы?

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

Обязательная блокировка статистики

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

Эта статья ничем не отличается (может быть, еще одна универсальная константа?). Людям нравятся числа, так что вот:

В 2017 году компания Akamai опубликовала свой Отчет об эффективности розничной торговли в Интернете, в котором обнаружено следующее:

* Задержка в 100 мс приводит к падению продаж на 7% * 2-секундная задержка увеличила показатель отказов на 103% * 53% пользователей смартфонов не конвертируются, если время загрузки превышает 3 секунды * Оптимальная загрузка для большинства продаж 1,8-2,7с * 28% пользователей не вернутся на медленные сайты * Веб-страницы с наибольшим количеством продаж загружаются на 26 % быстрее, чем у конкурентов

Хотите больше статистики? Вы поняли.

Walmart обнаружил, что каждая секунда увеличения времени загрузки увеличивает продажи на 2% (источник). Учтите, что Walmart заработает 500 миллиардов долларов в 2021 году. Два процента от этой суммы составляют 10 миллиардов долларов. Это означает, что они могут нанять 133 000 разработчиков, чтобы увеличить время загрузки всего на 1 секунду, и при этом получать прибыль (исходя из средней зарплаты в 2020 году в размере 75 000 долларов США).

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

Дело не только в деньгах

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

Я немного подумал, и, хотя это более расплывчато, вот мои мысли.

Пограничные вычисления — это скорость, а также надежность. Что заставило меня задуматься о важности доступа к информации. Информация становится все более важной во времена кризиса, и сегодня у нас есть множество тому примеров.

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

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

Заключительные мысли

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

Как роботы, обученные вязать шапки для собак в магазинах 🤖🧶💉🐶🎩+🏪

Довольно ясно, правда?

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

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

* Астро * ремикс * Nuxt * Далее * 11ty * и многое другое

Это интересно!

Собачьи шапки для всех!!!

Оно того стоит?

Это зависит 💩

Но я думаю, что это круто, и надеюсь, что вы попробуете.

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

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

Дополнительную информацию об Akamai EdgeWorkers можно найти по этим ссылкам:

* akamai.com * developer.akamai.com * techdocs.akamai.com

Большое спасибо за прочтение. Если вам понравилась эта статья, поделитесь ею. Это один из лучших способов поддержать меня. Вы также можете подписаться на мою рассылку или подписаться на меня в Twitter. если вы хотите знать, когда публикуются новые статьи.

Первоначально опубликовано здесь