Troppi sviluppatori e aziende stanno affrontando il periodo buio delle reti di distribuzione dei contenuti (CDN) legacy che non sono state costruite per fornire l'osservabilità in tempo reale, la sicurezza integrata e il controllo programmatico necessari per offrire le esperienze dinamiche richieste dagli utenti e dagli sviluppatori di oggi.
La CDN moderna di Fastly è progettata per consentire agli sviluppatori di creare esperienze digitali innovative che aiutino ad aumentare il valore di vita del cliente, migliorare i tassi di conversione e aumentare il valore medio degli ordini e la fedeltà. Con questa capacità, le aziende sono meglio attrezzate per il successo quando forniscono agli sviluppatori gli strumenti necessari per innovare e mantenere siti e applicazioni sicuri e competitivi.
Durante questo webinar, gli esperti di Fastly esploreranno:
L’evoluzione delle CDN legacy e lo stato attuale dell’industria delle CDN, basato su fondamenta che stanno progressivamente mostrando i propri limiti.
I vantaggi della CDN moderna, incluse applicazioni reali da parte dei clienti Fastly, Gannett e Stripe, ognuna con le proprie sfide per soddisfare e superare le aspettative degli utenti.
Come selezionare un moderno provider di CDN e i fattori distintivi unici da cercare nel confronto con la propria legacy CDN, tra cui i modi per ottenere un ritorno sull'investimento.
Dopo questo webinar, capirai perché è il momento di valutare la sostituzione della tua legacy CDN con una progettata per utenti e sviluppatori moderni.
[Leigh Clancy] Salve e grazie per essere qui con noi in occasione del webinar “Cos'è una CDN moderna e perché è importante“.
Durante questo webinar, esploreremo l'evoluzione e lo stato attuale delle CDN, i vantaggi di una CDN moderna, incluse applicazioni reali, come scegliere un fornitore di CDN moderno e cosa cercare. Non esitate a inviare le domande tramite chat e cercheremo di rispondere durante la sessione di domande e risposte alla fine. Oggi il nostro relatore è Lee Chen, vicepresidente dello sviluppo aziendale e delle partnership strategiche qui a Fastly e sponsor esecutivo dei nostri prodotti media. Presso Fastly, ha guidato una vasta gamma di funzioni nei settori prodotto, marketing e partnership; negli ultimi 20 anni ha lavorato nel settore dei media e dell'intrattenimento, facendo da pioniere nelle trasmissioni in diretta su Internet. Prima di entrare in Fastly, ha fondato e guidato diverse startup nei settori della tecnologia e degli eSport. E con questo lascio la parola a Lee.
[Lee Chen] Grazie Leigh. Salve a tutti, grazie per essere qui oggi. Partiamo rapidamente con le slide. Le vedete tutti, vero? Salve, grazie per essere qui oggi. Ve ne sono molto grato. Sono incredibilmente entusiasta di affrontare questo argomento: cos'è una CDN moderno e perché è importante. Prima di entrare in Fastly, come ha accennato Leigh, circa nove anni fa, ho avuto la fortuna di lavorare sia nel settore delle infrastrutture che in quello della vendita diretta al consumatore. Ho iniziato la mia carriera nelle telecomunicazioni, nell’early broadband access, e poi lavorando agli albori degli eSports, occupandomi di live broadcast, ho vissuto spesso le sfide legate all’interattività in tempo reale e alla scalabilità di queste piattaforme fino a milioni e milioni di utenti. Quindi, quando sono entrato in Fastly, ho iniziato un percorso straordinario sulla risoluzione dei problemi su scala Internet in un’ampia varietà di casi d’uso. Sono quindi entusiasta di condividere con voi alcune delle cose che ho imparato e perché sono rilevanti oggi nel contesto moderno dello sviluppo.
Parlerò dell'evoluzione di una CDN moderna poiché ritengo che il contesto sia davvero importante per questa conversazione. Esamineremo alcuni dei vantaggi, parleremo di alcuni esempi del mondo reale di cui sono davvero entusiasta e discuteremo di come scegliere una CDN moderna per il vostro specifico caso d'uso. E poi una breve nota sul perché Fastly rappresenti una scelta eccellente, ma spero che questo intervento vi offra anche alcuni spunti su come immaginare, e reimmaginare, la scalabilità delle vostre applicazioni non solo in termini di numero di utenti, ma anche di prestazioni, copertura, sicurezza e, soprattutto, controllo. E sottolineo che oggi il pubblico è molto ampio e che si tratta di un argomento di cui potrei parlare per ore e ore, cosa che probabilmente non interesserebbe a nessuno, quindi cercheremo di essere rapidi. Come ha detto Leigh, se avete domande, non esitare a scriverle nella sezione Domande e Risposte e faremo del nostro meglio per rispondervi.
Quindi approfondiamo.
Cosa facevano le aziende prima delle CDN? In passato, agli albori di internet, c'erano una serie di sfide, in particolare quando il pubblico di un’app o di un sito diventava sempre più distribuito o, ancora meglio, estremamente popolare. E queste stesse sfide sono ancora valide oggi. Il più delle volte, quando costruiamo la nostra prima applicazione o il nostro primo sito, non abbiamo una rete edge distribuita a livello globale che ci aiuti a consegnare i nostri contenuti in modo sicuro o veloce in tutto il mondo e quindi ci ritroviamo con esperienze utente scadenti a causa di tempi di caricamento lenti dovuti a considerazioni sulla latenza o siti non funzionanti a causa dello sharding geografico. Quindi, per risolvere questo problema, potremmo provare
a farlo internamente mettendo in piedi più istanze del nostro sito o della nostra applicazione in tutto il mondo, ma a quel punto avremmo problemi di coerenza dei dati tra i diversi sistemi.
Le CDN sono nate proprio da queste sfide. Le prime CDN facevano più o meno la stessa cosa, giusto? Creavano copie o la possibilità di memorizzare più copie degli stessi dati in tutto il mondo, chiamiamole cache o POP, con risultati leggermente migliori perché creavano queste cache per contenere copie del cosiddetto contenuto statico di un sito o di una app. Cose come immagini, video, testo, ecc. che non cambiavano molto spesso, quindi il problema di coerenza costante veniva in qualche modo mitigato perché i contenuti non cambiavano spesso. Ma [ops, scusate] questo non è stato di aiuto quando sono entrati in scena contenuti dinamici che cambiavano frequentemente o, peggio ancora, personalizzati per ogni utente, come ad esempio lo stato di accesso, la home page di un importante sito di notizie oppure il feed personale di Twitter. Inoltre, agli albori di Internet, la topologia della rete era molto diversa. Per essere efficaci, le prime CDN dovevano collocare i propri punti di presenza, o POP, in profondità nelle reti di accesso degli utenti finali.
Quindi, con l'evolversi della situazione, le CDN hanno continuato a incontrare difficoltà e, con la scalabilità e la diffusione di Internet e l'uso quotidiano cresciuti in modo esponenziale, ogni anno i problemi dell'architettura originale hanno continuato ad accumularsi. Centinaia di migliaia di server di cache situati in profondità nell’ultimo miglio di Internet significavano centinaia di migliaia di copie dello stesso contenuto in tutto il mondo. E la prima volta che un contenuto, ad esempio una versione aggiornata della homepage, viene richiesto su uno qualsiasi di questi server di cache, deve tornare all’origine, cioè allo stack applicativo, per recuperare quel contenuto. Quindi, se l'app o il contenuto sono molto popolari, può significare che milioni e milioni di utenti tornano alla tua origine per accedere ai contenuti più recenti. Quindi, le architetture legacy adottavano quello che veniva chiamato caching di fascia media, come si vede qui, e questo significava che “solo” decine di migliaia di server fungevano da origine per le cache dell’ultimo miglio. Tuttavia, anche queste continuavano comunque a interrogare il server di origine per ottenere la copia aggiornata del contenuto o la sua versione più recente. E inoltre, i contenuti sono diventati sempre più in tempo reale. DevOps e l'integrazione e distribuzione continua sono diventati una realtà, non solo per migliorare i flussi di lavoro degli sviluppatori, ma anche per permettere alle aziende di iterare più velocemente, e tutti questi fattori hanno caricato sulle architetture edge del passato problemi sempre più difficili da risolvere. Conservare una copia obsoleta e non aggiornata di una pagina web è dannoso. Avere più versioni del contenuto, delle API o persino di intere applicazioni edge, sempre più datate e sempre più inaccurate, è decisamente molto peggio. Quindi, anche con queste cache profonde nell’ultimo miglio e con i livelli intermedi attivi, l'afflusso massiccio di richieste finiva comunque per raggiungere l’origine più spesso di quanto si volesse. Si tratta di un problema di scalabilità sia verticale che orizzontale, che la CDN edge è stata progettata proprio per risolvere fin dall’inizio. Non dimentichiamo elementi come bot e attori malevoli che cercano di sfruttare, fare scraping o peggio ancora: è qui che queste applicazioni e situazioni diventano davvero problematiche. Quindi l’altra cosa che voglio sottolineare è che in questo diagramma in realtà non c’è alcuna osservabilità o visibilità reale su ciò che accade all’edge. Nelle architetture legacy magari dopo 24 o 48 ore si riceveva un dump di log, ma questo non è assolutamente utile per diagnosticare o risolvere problemi in tempo reale.
L’altro elemento che non è rappresentato qui è che non esiste un modo per invalidare ciò che vive ai bordi della rete, e questo diventa un problema quando il tempo stringe. Ad esempio uno sviluppatore può avere tutti col fiato sul collo per correggere un titolo sbagliato, un conteggio di inventario errato o qualsiasi altro dato critico per il business o per il brand che è ormai distribuito su Internet. Qui entra in gioco Fastly. Cosa c’è di diverso nella CDN moderna e con Fastly. Prima di tutto, distribuiamo grandi POP nei principali snodi di Internet, non in profondità nell’ultimo miglio. Sono i punti in cui Internet converge e si interconnette con tutte le altre reti nel mondo. Questo significa CPU, disco e rete consolidati, maggiore efficienza nella cache e nel calcolo, che si traduce in un migliore controllo e disponibilità per voi, il vostro sito web o la vostra applicazione. E dato ci troviamo presso i principali snodi di Internet, la latenza e le prestazioni della nostra rete sono altrettanto buone, se non migliori, di quelle delle legacy CDN. Lo potete verificare nelle statistiche pubbliche di terze parti su Citrix. Anzi, se qualcuno potesse inserire quel link nella chat per tutti sarebbe fantastico. Potete vedere voi stessi le metriche di latenza: si tratta di una misurazione indipendente effettuata da terze parti, quindi non sono i nostri numeri, ma quelli di un ente esterno che misura tutti gli attori. Osservare la distribuzione dinamica degli oggetti è probabilmente uno dei modi migliori per avere un’idea delle prestazioni di latenza di qualsiasi rete edge. La densità di calcolo dei nostri mega-POP consente quindi di eseguire logiche applicative complesse negli script di configurazione o anche applicazioni complete nel nostro prodotto compute@edge, direttamente ai bordi della rete e in linea con il flusso di distribuzione delle richieste degli utenti che interagiscono con le vostre app e i vostri siti web. A questo si aggiunge la compressione delle richieste, che noi chiamiamo schermatura, e questo significa che non ci sono decine di migliaia di richieste dai livelli intermedi che tornano alla vostra origine: ce n’è solo una, al massimo due se avete attivato la schermatura ridondante. In altre parole, non esiste il problema dell'afflusso massiccio di richieste. Eppure, nella sicurezza, un firewall per la protezione di applicazioni web e API in modalità inline fa parte del flusso di richiesta verso l’applicazione, e può essere configurato in modalità di blocco perché è effettivamente in grado di distinguere tra utenti legittimi e attori malevoli. E un'interfaccia API per il controllo di tutto questo vi permette di controllare l'intera piattaforma edge, così da poter accedere programmaticamente direttamente dai flussi di lavoro degli sviluppatori e propagare cambiamenti e aggiornamenti in tutto il mondo in pochi secondi, non in minuti o ore. La funzione di instant purge consente di memorizzare nella cache e convalidare i contenuti in media in 150 millisecondi o meno; combinando questi due elementi si ottiene un controllo quasi in tempo reale non solo delle copie dei contenuti in tutto il mondo, ma anche della logica di applicazione che ne determina il rendering. E poi c'è l'osservabilità, come ho già detto prima. La possibilità di vedere cosa succede realmente con la vostra app quasi in tempo reale, così potete reagire, risolvere problemi, analizzarla per migliorare i risultati aziendali e l'esperienza utente, e non è solo un flusso di log semplice, ma un sistema che vi permette di personalizzare praticamente ogni cosa. Se volete acquisire un ID utente con un dato flusso di test AB, lo trovate nei log di Fastly. Se vi serve telemetria della latenza per una determinata regione geografica, la trovate nei log di Fastly. Se avete bisogno di una traccia di audit per la conformità, la trovate nei log di Fastly. E tutto questo è completamente personalizzabile e a portata di mano. Presi insieme, questi elementi costituiscono un toolkit estremamente potente in un ambiente di sviluppo moderno, e un ambiente di sviluppo moderno dovrebbe includere anche la vostra CDN.
Quindi, che cos'è una CDN moderna? Ho parlato di molte di queste funzionalità nella diapositiva precedente, e una CDN moderna dovrebbe avere tutte queste caratteristiche e non solo, ma l'elemento chiave che voglio che emerga da questa conversazione è che una CDN moderna dovrebbe far parte del vostro processo di sviluppo, non come un pensiero tardivo o un ostacolo, ma come toolkit che vi permetta effettivamente di raggiungere i vostri obiettivi, da quelli commerciali a quelli personali: non deve diventare un'emergenza al momento della scalabilità. In definitiva, una CDN moderna dovrebbe permettere ai team di sviluppo di accelerare le iterazioni e l'innovazione. Gli algoritmi di PageRank di Google misurano anche i tempi di caricamento delle pagine, che dipendono dalla latenza e dalla disponibilità dei contenuti nelle cache. Per questo motivo, una CDN moderna deve essere veloce e performante per contribuire automaticamente a migliorare il posizionamento nei risultati di ricerca. Inoltre dovrebbe essere ben collegata tramite peering o a livello di rete con Google e molti degli altri motori di ricerca disponibili. Ancora una volta, rimando alle metriche di PageRank o di latenza di Sodexis, che possono essere utilizzate rapidamente per valutare le prestazioni. Dovreste essere in grado di personalizzare i contenuti all’edge. Immaginate i casi d’uso dell’A/B testing se poteste spostare questa logica all’edge e generare dinamicamente i contenuti in base agli input dell’utente, mantenendo al contempo tutta la visibilità necessaria per apportare modifiche all’esperienza utente o ottimizzare i ricavi. La sicurezza dovrebbe essere nativa e ai bordi della rete. Dovreste avere la possibilità di fare più della configurazione di base della cache, per eseguire la logica applicativa e, di fatto, intere applicazioni ai bordi della rete. E l'elenco continua.
Parliamo di alcuni esempi concreti.
Gannett è il più grande editore di notizie negli Stati Uniti ed è noto per la creazione di community locali affidabili. Quella più nota forse è USA Today. Nel publishing, la cache invalidation, che noi chiamiamo instant purge, è fondamentale per garantire che gli ultimi titoli e le notizie siano sempre aggiornati: immaginiamo però cosa significherebbe avere un tempo di purge di 150 millisecondi. In poche parole Gannett ha potuto considerare Fastly come un'estensione diretta, quasi in tempo reale e distribuita a livello globale, dei suoi server di origine. La homepage di Gannett potrebbe probabilmente essere considerata non memorizzabile nella cache e servita dinamicamente; è altamente personalizzata, contiene molti contenuti che vengono costantemente aggiornati, come i titoli e così via. Quindi “servita in modo dinamico” significa che viene generata al momento e arriva direttamente dai loro server di origine nel cloud. E poiché hanno sempre bisogno delle ultime notizie e dei titoli più recenti, la realtà è che sono effettivamente dinamici in base a un evento, come l'aggiornamento di una notizia dell'ultima ora, la pubblicazione di un commento o un clic sul pulsante "Mi piace". È un evento che può essere acquisito e usato in modo programmatico per attivare una richiesta di purge, tramite API. E quindi, con il purge e con l’instant purge, questa diventa la loro nuova realtà: si scarica un’enorme quantità di onere infrastrutturale, consentendo al tempo stesso di spostare la logica applicativa verso i bordi della rete. Hanno registrato un miglioramento del 98,86 % nel tempo di push della configurazione globale rispetto alla configurazione precedente e, trasferendo tutto il traffico di origine su Fastly, hanno ottenuto un risparmio del 35 % sui costi di uscita.
Stripe è un altro dei miei esempi preferiti. Gestisce circa un miliardo di dollari all’anno, con picchi di traffico molto imprevedibili dovuti a vendite flash e periodi festivi. Il loro business richiede non solo sicurezza, ma anche altissime prestazioni, perché un ritardo nel processo di checkout può significare una vendita persa per i loro clienti e ha un impatto diretto sui ricavi di Stripe. I picchi di traffico sono normali per loro: devono solo essere in grado di assorbirli e continuare a processare le transazioni per il loro cliente finale. Quindi avere una piattaforma edge in grado di scalare per gestire quei picchi senza permettere al grande afflusso di tornare ai server di origine è stato davvero fondamentale, ed è una lezione che hanno imparato in prima persona dal loro precedente provider. Inoltre, c'è la regola dei due secondi di ritardo nel caricamento delle pagine che porta l'utente a lasciare il carrello o a cercare il prodotto su un altro sito. Quindi il cliente finale finisce per perdere una transazione se Stripe è troppo lento. Stripe deve migliorare continuamente le prestazioni al fine di evitare la perdita di vendite per i clienti: integrando Fastly nella piattaforma di applicazioni edge, Stripe è riuscita a ridurre i tempi di checkout dell'80 %, con un miglioramento incredibile e significativo nella customer experience.
Quindi come si sceglie una CDN moderna? Ecco cosa cercare prima di acquistare: la prima colonna è tutta dedicata agli sviluppatori. Come ho accennato prima, una CDN moderna dovrebbe essere parte integrante del processo di sviluppo,non qualcosa a cui pensare a posteriori o da aggiungere in un secondo momento. Se la sfrutti fin dall’inizio, mentre stai ancora avviando il progetto, i vantaggi sono tutti a favore vostro e del resto dell'azienda, per non parlare dei team di sviluppo, che possono iterare e innovare più rapidamente. E si spera che gli sviluppatori la apprezzino fin dall’inizio, permettendovi di concentrarvi sulla risoluzione delle sfide di business e sul miglioramento dell’esperienza utente. Controllo, osservabilità, standard, conformità, supporto e programmabilità integrata per la sicurezza sono tutti elementi chiave che dovresti ricercare nel prodotto. La seconda colonna riguarda la risposta alle esigenze, agli obiettivi e alle finalità aziendali che dovete affrontare. Il costo totale di proprietà è sempre importante; è ed è altrettanto fondamentale valutare l'impatto dell'uscita dal cloud e quanti server siano necessari da eseguire su EC2, o su qualunque altra infrastruttura, per supportare la vostra architettura di caching. Infine, è bene provare prima di acquistare: non siamo più nel 2000 o nel 2005 o nel 2010. Oggi avete la possibilità di provare prima di acquistare. E dovreste anche valutare il supporto offerto. Una vera piattaforma edge, come una CDN moderna, è una piattaforma che può essere integrata ed è parte integrante del vostro business e del vostro stack, e personalmente cerco di scegliere partner, fornitori e clienti di cui possono andare fiero.
Quindi ci sono alcuni numeri di cui siamo davvero orgogliosi. Abbiamo scalato la nostra rete a quasi 200 terabit al secondo, sempre mantenendo le prestazioni della purge nei tempi di distribuzione globale. Non è un risultato da poco: si tratta di un problema di calcolo distribuito piuttosto complesso. E siamo piuttosto orgogliosi del fatto che tutte le nostre metriche prestazionali abbiano continuato a migliorare con l'aumento della scalabilità. Il nostro Next-Gen WAF viene utilizzato in modalità di blocco completo da oltre il 90 % dei nostri clienti, il che significa che si fidano di noi per fermare effettivamente i malintenzionati e i bot senza allontanare utenti reali e legittimi, e questo è incredibilmente importante, perché se il WAF rimane in modalità di monitoraggio, i problemi vengono rilevati solo a posteriori. Tenere il WAF in modalità di blocco full significa potersi affidare alla qualità della tecnologia e della ricerca di sicurezza su cui si basa, che è in grado di identificare efficacemente gli attori malevoli senza ostacolare gli utenti legittimi nelle loro interazioni con l’app o nel completamento delle transazioni. Ma forse la cosa più importante, e il dato di cui siamo più orgogliosi, è che amiamo davvero i nostri clienti. Siamo stati tutti clienti a un certo punto della nostra vita, e sapendo come vogliamo essere trattati da clienti ci spinge a trattare tutti voi nello stesso modo. Quindi queste metriche relative ai clienti riflettono il nostro continuo impegno su questo fronte.
Detto questo, grazie per averci ascoltato oggi, ora passo la parola a te, Leigh.
[Leigh Clancy] Grazie mille. Vi ricordo di scrivere pure le vostre domande; risponderemo ora e, se non riusciremo, vi contatteremo in seguito. Quindi, prego, non esitate a porre qualsiasi domanda.
[Lee Chen] Visualizza lo schermo condiviso e possiamo procedere.
[Leigh Clancy] Ecco ne vedo una in arrivo, sembra che ci sia qualche domanda: potete parlare meglio di cosa significa per gli sviluppatori evidenziando il concetto di controllo completo e le relative implicazioni.
[Lee Chen] Ottima domanda. La questione può prendere varie forme. Gli aspetti sono due: per controllo si intende la possibilità di intervenire direttamente sulla configurazione, sulle intestazioni di controllo della cache e sul contenuto effettivamente presente nelle cache. In una CDN moderna e in una strategia di edge caching, esiste un’ampia varietà di elementi che è fondamentale poter gestire e governare in modo preciso. Quindi, A) devi poter accedere al sistema: non può essere una black box. Fastly lo rende possibile tramite API oppure attraverso il pannello di controllo, che in realtà è costruito sulla stessa API. Non dimentichiamo poi che quando si apportano queste modifiche, devono propagarsi in tutto il mondo su ogni nodo che sta servendo il tuo traffico o la tua configurazione in modo estremamente rapido. Quindi un tempo di implementazione di 13 secondi significa che in pochi secondi le modifiche alla configurazione vengono propagate in tutto il mondo e applicate come regole al traffico che gestiamo per te. L'altro elemento da considerare è cosa stai controllando e perché stai apportando modifiche? E quindi si torna al concetto di osservabilità. Se non riesci a vedere l’impatto delle modifiche che stai facendo in quasi tempo reale, se devi aspettare ore, o a volte giorni, perché il cambiamento si rifletta nei log o negli strumenti di osservabilità, allora è praticamente inutile. Potresti avere una modifica di configurazione molto critica che non manda giù il sito, ma magari ha semplicemente sostituito il logo con qualcos’altro, con un impatto potenzialmente dannoso per il brand. Quindi osservabilità e controllo si sviluppano entrambi in tempo reale, ed è così che operano oggi gli sviluppatori ed è qualcosa in cui crediamo molto.
[Leigh Clancy] Quindi Fastly supporta gli standard web e il software open source?
[Lee Chen] Lo facciamo a più livelli: è integrato direttamente nello stack. Supportiamo QUIC, HTTP/3 e una vasta gamma di standard web, sia a livello di piattaforma sia contribuendo attivamente all’IETF e ad altri organismi di standardizzazione, per aiutare a definire gli standard stessi. Inoltre, disponiamo di un valido programma di supporto open source di cui siamo piuttosto orgogliosi. Questo riguarda il supporto alla distribuzione di progetti open source, codice, repository e altri contenuti che potresti scaricare. Ad esempio, NPM e molti altri pacchetti principali vengono distribuiti attraverso Fastly. Quindi, anche se non conosco esattamente il contesto della domanda, direi che lo supportiamo a livello di piattaforma, permettendoti di lavorarci senza problemi: la maggior parte di questi aspetti è ben documentata su docs.fastly.com. Abbiamo dato il nostro supporto perché volevamo far sentire la nostra voce e mettere a disposizione la nostra esperienza e il nostro punto di vista per la definizione di questi standard. E poi, per i progetti open source, offriamo servizi gratuiti per la distribuzione per assicurarci che i progetti open source possano essere effettivamente utilizzati da chi è interessato a usarli.
[Leigh Clancy] Fantastico, e penso che ne abbiamo un'ultima qui: per quanto riguarda gli eventi dal vivo, in caso di afflusso massiccio di richieste, con che velocità Fastly riesce a scalare per far fronte alle esistenze? So che l'argomento è stato parzialmente affrontato.
[Lee Chen] Sì. È una problematica che conosco per esperienza diretta: l’ho vista produrre risultati eccellenti, ma anche causare seri problemi. Sai, quando pensiamo agli eventi dal vivo e al problema dell'afflusso massiccio di richieste, la prima cosa che mi viene in mente solitamente è il Super Bowl, giusto? Ogni anno milioni di persone si sintonizzano per guardare il football americano e il campionato del mondo. Quindi si tratta di uno scenario molto diverso dalle normali partite del weekend. E in questa finestra temporale di circa quattro ore, milioni di persone si collegano per accedere allo stesso streaming video, con molteplici varianti di qualità e bitrate. Questo picco di traffico costituisce un problema, e non è certo trascurabile. Si misura in terabit al secondo, decine e centinaia di terabit al secondo, ma se si analizza la questione più a fondo, in realtà lo stesso problema si presenta praticamente con qualsiasi tipo di evento. Se un contenuto diventa virale, all'improvviso ti ritrovi con un afflusso incontrollabile di richieste. Ad esempio, potrebbe esserci una notizia dell'ultima ora che innesca lo stesso problema, anche se non si tratta di un evento gigantesco e globale. Può essere un fenomeno estremamente locale e regionale. Ad esempio un'allerta tornado o un evento locale che improvvisamente suscita grande interesse. Il modo in cui le CDN gestiscono questo problema è proprio quello per cui sono state progettate all'inizio, non si trattava solo di un problema di distribuzione, ma anche di scalabilità orizzontale e verticale, semplicemente immagazzinando copie della cache. Quindi ogni CDN dovrebbe essere in grado di gestire questo scenario, e le CDN moderne in particolare dovrebbero riuscire a farlo senza sovraccaricare l’origine. L’ultimo elemento è quello che chiamiamo shielding: l’idea è che gestiamo tutto il traffico sull’edge perché disponiamo di una copia aggiornata del contenuto, attraverso i nodi edge o le cache edge, oppure attraverso i nostri POP di shield. In questo modo, solo una o due richieste tornano all'origine. Le legacy CDN non offrono gli stessi vantaggi. Hanno migliaia di cache di livello intermedio, ognuna delle quali deve interrogare l’origine per ottenere quel contenuto e poi distribuirlo verso i bordi. L’approccio che abbiamo adottato, e che abbiamo visto funzionare insieme ai nostri clienti, mostra che ci sono enormi benefici nella gestione dei picchi di traffico come questo.
[Leigh Clancy] Fantastico. Grazie mille, Lee, a quanto pare queste sono le ultime domande. Quindi grazie per la presentazione e grazie a tutti voi per aver partecipato. Apprezziamo davvero il tempo che ci avete dedicato. Riceverete un'e-mail con un link alla registrazione del webinar di oggi. Se desiderate provare Fastly, andate su Fastly.com e cliccate sul pulsante "Prova Fastly gratis". E con questo vi auguro una buona continuazione di giornata e vi ringrazio ancora per aver partecipato.
[Lee Chen] Grazie a tutti, davvero; alla prossima.