Improving Visitor Experience with Edge Computing

Improving Visitor Experience with Edge Computing @AndyDavies, July 2020 https://www.flickr.com/photos/yoyo_hick/2423655297

Where is the Edge? Device? Network? Cloud?

Edge computing isn’t really a new concept

Safely deploying customer code has been a challenge https://www.flickr.com/photos/edenpictures/36796298946

Configuration languages have got us a long way https://www.flickr.com/photos/chrisrandall/6136814248

But what could we do with greater power and flexibility? https://www.flickr.com/photos/qubodup/14750352671

Advantages of processing at the edge • Faster responses as endpoint is closer to the visitor • Reduced load at the origin • Orchestrate data from 3rd-parties

Improvements in several areas made it feasible • ServiceWorker API provided a model for programmable proxies • Overhead of isolation between processes reduced • Serverless programming became common

Service Workers are in-browser network proxy… …can intercept and rewrite both requests and responses

Edge Workers are a similar concept… …it’s just the proxy is in a different place

New isolation techniques reduced resource overhead • Micro Virtual Machines (VMs) • V8 Isolates • Web Assembly (WASM)

Resource requirements vary by approach Virtual Machines V8 Isolates Reducing overhead Web Assembly

Some approaches are faster than others Virtual Machine V8 Isolates Web Assembly High Low Low < 125ms (just for VM) < 5ms < 40μs Runtime Overhead High Low Low Language(s) BYO JavaScript / WASM C, Rust, Go, AssemblyScript Resource Consumption Startup Time

Using JavaScript makes it very familiar // Hello World Example export function onClientRequest(request) { request.respondWith( 200, {}, ‘<html><body><h1>Hello World From Akamai EdgeWorkers</h1></body></html>’); } export function onClientResponse(request, response) { response.setHeader(‘X-Hello-World’, ‘From Akamai EdgeWorkers’); }

Using JavaScript makes it very familiar // Hello World Example addEventListener(‘fetch’, event => { event.respondWith(handleRequest(event.request)) }) /** * Fetch and log a request * @param {Request} request */ async function handleRequest(request) { return new Response(‘Hello worker!’, { status: 200 }) }

YMMV with other languages (Rust for example) #[macro_use] extern crate http_guest; use http_guest::{Request, Response}; pub fn user_entrypoint(_req: &Request<Vec<u8>>) -> Response<Vec<u8>> { Response::builder() .status(200) .body(“Hello, world!”.as_bytes().to_owned()) .unwrap() } guest_app!(user_entrypoint); Either executed as binary on VM, or compiled to WASM

Text representation of WASM looks something like this (module (type $t0 (func (param i32) (result i32))) (func $add_one (export “add_one”) (type $t0) (param $p0 i32) (result i32) get_local $p0 i32.const 1 i32.add) (table $T0 1 1 anyfunc) (memory $memory (export “memory”) 17)) Note: this is an example NOT the code from the previous slide

WASI allows WASM to access system functions

Managed and deployed as code

What might we do with these new capabilities?

Many examples… https://github.com/akamai/edgeworkers-examples

What activities can be moved from… …the origin to the edge? …the client to the edge?

Examples • More responsive user interactions • Preserving privacy • Proxying 3rd Parties • Experiment with Performance Optimisations

Responsive User Interactions

Fast autocomplete

Clientside frameworks rely on fast APIs

3rd Parties as Content

Reviews are essential to the buying experience

How could an edge worker mitigate this issue?

Move client-side experimentation to the edge Most AB / MV Testing services rely on large JavaScript bundles • Delays while downloading • Delays while executing • Often use ‘anti-flicker’ scripts to hide the page while it reflows Moving the experimentation off the client reduces these issues But…

Move client-side experimentation to the edge AB / MV Testing services are not just a large JavaScript bundle! They also provide • Cohort mangement • Experiment creation • Analytics What do we need to solve these challenges with edge workers?

Optimizely supports moving snippet processing at edge https://man.gl/optimizely-experimenting-at-the-edge

Many other client-side 3rd-parties slow the experience • Personalisation • Faceted search • Chat • Feedback Could implementing these at the edge improve that?

Preserving Privacy

How many tags are collecting visitor data? https://man.gl/chiefmartec-supergraphic-2019

And what are they doing with it? https://requestmap.herokuapp.com

Preserve privacy by proxying analytics

Cookie consent at the edge? https://www.flickr.com/photos/61287964@N00/5714826863

How do we get 3rd-Party Tags to offer their features via the edge?

Experiment with Performance Optimisations DevTools give us the ability to experiment with code locally

Create a proxy to rewrite the page https://github.com/pmeenan/cf-workers

Use proxy via overrideHost in WebPageTest script https://www.slideshare.net/patrickmeenan/getting-the-most-out-of-webpagetest

Where’s the appropriate place to carry out the work? Some workloads may be unsuitable for network edge • Machine Learning on device may be better for privacy reasons • Overhead of uploading client generated data may be prohibitive • What needs to remain on the origin?

Challenges Technical • Debugging, profiling code in environments we don’t control Mindset • It’s new, many services are still in beta, need to think about how we architect our services

Closing Thoughts Edge computing gives us new capabilities to improve our site’s reliability, and our visitors experience and privacy Vendors are adopting slightly different approaches We haven’t worked out how to make the most of them yet

@andydavies hello@andydavies.me http://noti.st/andydavies http://www.flickr.com/photos/auntiep/5024494612

Improving Visitor Experience with Edge Computing @AndyDavies, July 2020 https://www.flickr.com/photos/yoyo_hick/2423655297