DE{CODE}: De ce Edge nu este o carcasă Edge

Când sunteți la limită, viteza, securitatea și starea de sănătate a serverului nu pot fi o idee ulterioară. În această sesiune, Sergi Isasi, vicepreședintele de produs Cloudflare și managerul de produs WP Engine, Pavan Tirupati, discută de ce este esențial să ai o mentalitate de vârf pentru succesul fiecărui site web pe care îl construiești sau îl menții

Diapozitive de sesiune

Transcriere text integral

PAVAN TIRUPATI : Hei, tuturor. Vă mulțumim că v-ați alăturat nouă în această sesiune despre cum vârsta nu este cu adevărat un caz limită. Sunt Pavan Tirupati, Product Manager la WP Engine cu echipa The Outreach și sunt în primul rând responsabil pentru securitatea, performanța și fiabilitatea edge pentru a crește și a împuternici clienții WP Engine.

Și ni se alătură astăzi de la Cloudflare Sergi, VP Product Management. Sergi, vrei să te prezinți?

SERGI ISASI : Sigur. Mulțumesc că m-ai primit, Pavan. Și vă mulțumim tuturor pentru că v-ați alăturat sesiunii noastre. Așadar, așa cum a spus Pavan, sunt vicepreședinte al produsului pentru performanța aplicațiilor la Cloudflare, concentrat pe performanța și fiabilitatea avantajului nostru. Dorim să facem lucrurile rapide și fiabile pentru toți clienții noștri. Produsele pe care le acoper sunt modul în care Cloudflare primește și procesează traficul la margine, deci atât la nivelul 4, cât și la 7. Deci, acestea includ memoria cache, proxy-ul nostru, spectrul FL, tehnologia fundamentală pentru Cloudflare, cum ar fi sistemele noastre DNS, sistemele noastre de gestionare a certificatelor și Sistemele de gestionare a adreselor IP și apoi noile aplicații de vârf, deci echilibrarea încărcăturii, noul nostru produs Waiting Room și viitoarele noastre produse Web3.

Sunt la Cloudflare de aproximativ 4 ani și jumătate. Și din nou, fericit să fiu aici astăzi.

PAVAN TIRUPATI: Minunat. Și astăzi, avem o sesiune minunată pentru voi, băieți, în timp ce cercetăm mai adânc ce este edge și cum este util și, după cum spune titlul, de ce edge nu mai este un caz de margine. Agenda pe care o avem pentru voi, băieți, este o săpătură mai profundă în ceea ce este marginea și care sunt beneficiile acesteia. Și având în vedere aceste vremuri, este esențial să ne concentrăm mai mult pe securitate.

Și vom vorbi despre câteva exemple și vom vorbi despre unele amenințări la securitate. De asemenea, ne vom uita la modul în care marginea va fi benefică pentru publicul care este aici și pentru toți cei care au prezență digitală în lume. Și vom analiza, de asemenea, câteva exemple specifice care ar putea fi benefice pentru persoanele care ar putea trece prin unele dintre aceste amenințări și probleme de securitate.

Deci va fi interesant, plin de resurse și perspicace. Deci, să începem cu stabilirea unui context aici. Vreau să stabilesc o linie de bază a ceea ce este marginea. Și cred că nu este o surpriză pentru nimeni când spun că companiile se confruntă cu o schimbare către o cultură a constructorului, una care se bazează pe capacitatea dezvoltatorilor de a crea și controla direct experiențe digitale.

Pe măsură ce site-urile și aplicațiile trec de la versiuni monolitice la o arhitectură mai mult de microservicii, capacitatea de a furniza conținut din diverse surse devine din ce în ce mai importantă. Și știm și înțelegem marginea de a face parte din internetul care este de fapt cel mai aproape de utilizatorii noștri finali, denumit uneori și ultima milă. Dar, înainte de a intra în detalii, Sergi, vreau să stabilesc nivelul publicului cu privire la ceea ce este marginea și de ce este chiar critică.

SERGI ISASI: Sigur. Deci, există o vorbă de mult timp în cloud computing, care este „cloud-ul este doar computerul altcuiva”. Îmi place foarte mult această zicală. Înseamnă că este același lucru pe care l-ați avea pe desktop sau laptop, dar este doar altcineva care îl gestionează. Și marginea este exact același lucru, este doar mai aproape de utilizator.

De ce este asta important? Vrem ca lucrurile să fie – la Cloudflare – cât mai aproape de utilizator. Și chiar se reduce la afirmația pe care ai spus-o, care este ultima milă. Deci, indiferent cât de repede ai face software-ul, cât de eficient îl poți face, dacă chiar răspunzi la ceva – dacă software-ul tău poate rula în submilisecundă, ești încă dator cu viteza luminii. Și dacă software-ul dvs. nu se află pe dispozitivul utilizatorului sau cât mai aproape posibil de acesta, acesta va experimenta această mică latență. Și uneori această latență este OK și uneori este foarte, foarte supărătoare pentru utilizatorul final. Deci, ideea este de a optimiza ceea ce are sens să fii aproape de utilizatorul final pe margine sau ceea ce este aproape de nucleu.

Și ceea ce face Cloudflare este să încercăm să punem totul la limită. Cred că unul dintre motivele pentru care mi-ai cerut să fac acest chat este pentru că conducem, probabil, una dintre cele mai mari rețele edge din lume și, evident, suntem incredibil de mândri de asta. Cloudflare are puțin peste 10 ani și am construit această rețea în tot acest timp. A crescut pentru a fi în 250 de orașe, 100 de țări diferite, cu scopul – și de fapt am atins acest obiectiv – de a fi în 50 de milisecunde de 95% dintre utilizatorii de internet din întreaga lume. Și asta, din nou, ultima milă – dacă putem fi în 50 de milisecunde, putem fi mult mai rapid pentru fiecare dintre acești utilizatori finali.

Celălalt fragment este să vă conectați la alte rețele. Așa că ne conectăm la alte 10.000 de rețele din întreaga lume, o mulțime de ISP-uri locali, de exemplu, și apoi ne operăm și propria noastră coloană vertebrală, așa că facem backhauling-ul acelui trafic pentru atunci când trebuie să mergem la nucleu sau la origine, facem asta și mai rapid. Am încheiat 2021 cu puțin peste 100 de terabiți pe secundă de capacitate. Și asta este important când vine vorba de scalarea orizontală atât pentru creșterea traficului pentru clienții noștri, cât și pentru creșterea atacurilor asupra clienților noștri și, de asemenea, asupra propriei rețele.

Unul dintre lucrurile care au fost interesante despre calcul în ultimii 30, 40 de ani este tranziția sa, înainte și înapoi, de la margine la nucleu la client, în funcție de locul în care avea sens și unde era toată puterea de calcul la acel moment. Deci, dacă te gândești până la internetul pre-public, ai avut mainframe. Aveai multă putere de calcul la bază și foarte puțină putere de calcul la margine și cantități foarte mici de lățime de bandă pentru a trece înainte și înapoi. Deci trimiteai comenzi către mainframe și ți-ar trimite înapoi rezultatele acelor comenzi în text.

Am făcut tranziția de acolo la o mulțime de progrese la punctul final, așa că ai o mulțime de clienți grozavi – Windows, Microsoft Word, toate acele lucruri pe care acum le-ai calculat mult la punctul final și apoi le-ai trimis înapoi, de obicei, la de bază pentru a partaja acel conținut.

Pe măsură ce marginea și nucleul au devenit mai puternice, ați început să vedeți aplicații cloud. Deci, în loc să faceți acea modificare pe dispozitiv, ați făcut schimbarea într-un browser web și aceasta a fost propagată prin alte dispozitive pentru partajare. Și acest lucru a devenit cu adevărat important atunci când aveam dispozitive mobile, în special dispozitivele mobile timpurii care aveau mai puține calculatoare, dar mult mai multă lățime de bandă.

Deci de ce este acest lucru critic? Este într-adevăr totul despre așteptările utilizatorilor cu privire la viteză. Deci, utilizatorul își dorește întotdeauna o experiență de utilizator bună. Și mai ales astăzi, ideea unei experiențe bune de utilizator este un fel de interacțiune instantanee. Dau clic pe un link, apas un buton, se întâmplă ceva și nu prea îmi pasă unde s-a întâmplat. Poate nici nu știu unde s-a întâmplat, dar vreau să fie rapid.

Celălalt lucru care s-a schimbat este mediul în care ne găsim. Deci există mult mai multe atacuri, în mare parte pentru că acele dispozitive au devenit mai puternice. Și apoi vedem o mulțime de reglementări în schimbare, deoarece securitatea și confidențialitatea devin nu numai cea mai importantă pentru utilizatori, ci și pentru guverne. Și acesta este motivul pentru care Cloudflare continuă să adauge POP-uri. Vedem mai mulți utilizatori, vedem mai mult trafic, vedem mai multe atacuri și vedem mai multe cazuri de utilizare pe care le-am putea pune la limită și le-am putea face puternice pentru acești utilizatori finali.

PAVAN TIRUPATI: Minunat. Putem să pătrundem puțin în pop? Ce este POP? Și ce s-a schimbat în POP-uri de-a lungul timpului? Și, în special, săpat în implementarea Cloudflare a POP, ce este unic?

SERGI ISASI: Deci, mulțumesc că ai adus-o înapoi. Spun foarte mult POP-uri și ar trebui să precizez ce înseamnă. Este un punct de prezență internet. Și în cazul lui Cloudflare și în majoritatea celorlalte cazuri, când auzi pe cineva vorbind despre un POP, ceea ce înseamnă este un teanc de servere, așezate undeva, care rulează software.

În ceea ce privește ceea ce s-a schimbat în timp, este de fapt mai ușor să vorbim despre ceea ce s-a schimbat față de ceea ce nu s-a schimbat. Și vom intra puțin în asta. Deci suntem la a 11-a generație de servere. Despre fiecare dintre aceste iterații scriem pe blogul nostru. Așa că continuăm să obținem computere mai rapide la margine, ceea ce este grozav. Înseamnă costuri mai mici, înseamnă mai multe capabilități, înseamnă doar lucruri în general mai bune pentru utilizatorii finali.

Unul dintre lucrurile interesante care s-au schimbat de-a lungul timpului este că am implementat de fapt pe trei arhitecturi CPU diferite – sau de fapt două arhitecturi CPU diferite, trei producători. Deci, rulăm atât Intel, cât și AMD, și rulăm și ARM pe marginea noastră.

Un alt lucru care s-a schimbat de-a lungul timpului este că continuăm să adăugăm locații. Nu îmi este clar câți aveam când ne-am lansat acum peste 10 ani. Era în intervalul de duzină. Dar există o poveste amuzantă a CTO-ului nostru, care a fost un fan timpuriu al Cloudflare, care i-a cunoscut pe fondatorii noștri, dar a refuzat să se alăture Cloudflare până când a obținut un POP aproape de locul unde se afla în Europa. El a spus, când apare asta? Și apoi mă voi alătura.

Locațiile noastre au crescut mai întâi pe baza cererii. Deci vezi mult trafic într-o regiune, este de fapt mai puțin costisitor, în general, să pui hardware într-o regiune și să deservi traficul acolo. Așa că am început să facem asta la început.

Odată ce am devenit mari, am început să vedem parteneri locali sau ISP-uri care încep să ne ceară să construim hardware în regiune pentru a face lucrurile mai eficiente pentru ei și utilizatorii lor finali. Deci a fost un fel de schimbare interesantă în lumea lui Cloudflare.

Scopul nostru inițial a fost să fim în 100 de milisecunde de utilizatorii finali. Și apoi ne-am dat seama că putem face mai bine. Deci acum avem obiectivul de 50 de milisecunde. Și n-aș fi surprins dacă ai vedea că asta devine și mai mic pe măsură ce anii trec.

Ceea ce nu s-a schimbat este că noi, foarte devreme, am făcut o alegere unică pentru noi și destul de fatidică, și anume că vom rula același software pe fiecare server edge din fiecare locație. Aceasta a ajuns să fie o alegere mai ușoară pentru majoritatea echipelor noastre de ingineri. Știm ce rulează pe fiecare dispozitiv și poți să depanezi și să rulezi lucrurile puțin mai eficient acolo. Unele dintre echipele noastre de ingineri au mult mai mult de lucru și din această cauză.

Face lucrurile mult mai ușor de scalat, atât pe termen lung, cât și pe termen scurt. Pe termen scurt, ne permite să mutăm resursele către diferite servicii, după cum este necesar, în funcție de încărcare și de ceea ce se întâmplă în acea locație în acel moment. Putem scala orizontal pe fiecare mașină.

Pe termen lung, ne permite să decidem în mod proactiv unde trebuie să meargă noile mașini, deoarece știm că trebuie să rulăm întreaga stivă. Celălalt mare avantaj, pentru echipele noastre de inginerie și în special pentru echipele noastre de inginerie de produs, este că avem performanțe consistente în toate serviciile. Nu ne îngrijorează că o locație este mai aproape de anumite tipuri de utilizatori și, prin urmare, este mai rapidă și are o experiență diferită. Va fi consecvent pe servere și în întreaga lume.

Și una dintre marile schimbări pe care le-am avut – probabil că are trei ani în acest moment – ​​este că acum le permitem clienților noștri să ruleze codul pe marginea noastră prin produsul nostru Workers. Și avantajul frumos este atunci când acel client alege să-și implementeze produsul, ei selectează de fapt regiunea lumii. Nu îi forțăm să spună, vreau să candid în vestul SUA sau ce ai tu. Software-ul lor este implementat în toate locațiile și rulează cât mai aproape de globul ocular.

PAVAN TIRUPATI: Super. Deci, cum se compară marginea cu miezul?

SERGI ISASI: Sigur. Deci depinde într-un fel de arhitectura ta. Și pentru unele arhitecturi, marginea este nucleul și nucleul este marginea. Dacă ai un singur loc, faci totul deodată.

În general, totuși, marginea va fi mai rapidă și mai eficientă pentru calcul, iar nucleul este locul în care păstrați secretele și configurația și împingeți datele de la nucleu la margine.

PAVAN TIRUPATI: Și are Cloudflare un nucleu? Și dacă se întâmplă, cum este implementat?

SERGI ISASI: Din prima zi, da. Și nu prea vorbim despre asta. E cam interesant. Dar dacă vă gândiți bine, am fost înființați în 2009 și, așadar, conducerea totul la margine a fost incredibil de nepractică în 2009 și, pentru unele lucruri, nepractic acum.

Deci, ce alergăm la bază? Gestionarea configurației – așa că trebuie să scoatem software-ul. și trebuie să o facem de undeva, așa că încă împingem software-ul Cloudflare, toate noile noastre versiuni, ne împingem codul, în fiecare zi, de la nucleu la marginea noastră. Și apoi rulăm, de asemenea, configurații pentru clienți care încă vorbește cu centrele noastre de date de bază. Și merge de acolo până la margine. Și este de fapt o poveste interesantă aici de la WP Engine și software-ul nostru DNS.

Așadar, în primele zile, Cloudflare a rulat PowerDNS, software DNS open-source. Și am început să construim ceva pe care îl numim intern RR DNS, propriul nostru software DNS, în 2013. Și un software foarte eficient. Aveam unele zone care erau în sute de mii de înregistrări și totul mergea relativ bine cu aceste cerințe. Și apoi a venit WP și au spus că avem mai mult de un milion de înregistrări în zona noastră. Iar viteza de actualizare, astfel încât capacitatea de a face o schimbare și de a împinge asta până la marginea noastră, a fost incredibil de critică, deoarece însemna că un client era încorporat și că trebuie să aibă această experiență. Și acesta a fost un caz marginal real pentru noi. Așa că ne-am uitat la asta și am spus: OK, evident că trebuie să reluăm modul în care ne gestionăm nucleul și să trimitem acel trafic la margine pentru a gestiona atât dimensiunea conținutului, cât și viteza și frecvența la care îl actualizați.

Așadar, în 2016, unul dintre inginerii noștri DNS, Tom Arnfeld, a întrebat dacă ar putea să stea cu WP Engine pentru a înțelege cu adevărat ce vrei și de ce l-ai dorit și cum ar arăta în 2017 și cum ar arăta în 2016. 2022, acum că am trecut cinci ani în asta. Și, așadar, ceea ce am făcut în 2017 a fost de fapt rescris întregul structur de date pentru software-ul nostru DNS pentru ca, la solicitarea CEO-ului nostru, să mutăm datele de la margine ca prin magie. Și a fost de fapt unul dintre acele lucruri în care aveam un client cu o nevoie, am vrut să satisfacem această nevoie, dar a trebuit să regândim modul în care mutăm datele de la bază la margine.

Un alt lucru pe care încă îl facem la bază este analiza. Deci telemetria vine de la margine în nucleu. Clienții noștri, când își văd analiticele, merg la un tablou de bord sau la un API și toate acestea sunt servite de la bază.

De-a lungul timpului, dimensiunea clienților și sofisticarea sporită a atacurilor ne-au făcut să ne regândim de fapt modul în care am făcut telemetria. Anterior, de exemplu, rulam tot software-ul nostru de detectare DDoS la bază. Deci, telemetria ar veni de la margine, ar spune nucleul, care arată ca un DDoS și ar trimite date înapoi la margine pentru a atenua. Acest lucru este suficient pentru unele atacuri DDoS, dar pentru altele, trebuie să luăm de fapt această decizie la margine. Așa că am îmbunătățit sistemul nostru original Gatebot, care rulează nucleul cu câteva sisteme noi, la jumătatea anului trecut, care funcționează efectiv la margine și iau decizii independente de nucleu, apoi raportează, așa că ne-am adaptat continuu la atac. suprafaţă.

Ultimul lucru despre care voi vorbi la bază este că astăzi facem cea mai mare parte a învățării automate. Ne bazăm mult pe învățarea automată pentru, în special, produsele de securitate. Dar vrem să facem mai mult din asta la margine, deoarece vedem, probabil, un model similar cu sistemul DDoS. Așa că am colaborat cu NVIDIA pentru a începe să rulăm mai mult din ML și la margine.

PAVAN TIRUPATI: Sergi, ai mentionat DDoS si securitate. Vreau să aprofundez puțin în asta, mai ales pentru că securitatea este extrem de critică. Care sunt unele dintre tendințele și lucrurile pe care le vedeți?

SERGI ISASI: Sigur, deci un record cam doborât din partea noastră, dar atacurile DDoS bat record. Doborâm acel record de la an la an. Motivul pentru aceasta este că botnet-urile cresc de fapt în dimensiune și folosesc dispozitive mai puternice. Deci, dacă vă gândiți la cât de mai rapid este telefonul dvs. mobil acum sau computerul dvs. față de anul anterior, este logic că doar dobândesc din ce în ce mai multă capacitate de a lansa atacuri mari, atât de semnificativ, încât am luptat împotriva unui Atacul „2 terabyte pe secundă” cu puțin timp în urmă – Este al doilea ca mărime despre care am auzit – și apoi, de asemenea, atacuri mai inteligente care pot face lucruri fără o mare capacitate de transfer, dar poate o mulțime de solicitări și solicitări costisitoare.

Într-adevăr, despre ce vorbim aici este mai multă sofisticare din partea atacurilor. Și statistica care cred că este cea mai interesantă, ceva noi

despre care tocmai am vorbit, este că 8% din traficul de pe marginea noastră este atenuat. Deci, înainte de a face orice fel de reguli sau ceva de genul acesta, 8% pur și simplu este renunțat cu totul, ceea ce înseamnă că, pentru un client care se gândește să facă securitate la limită, poate scăpa rapid de o mulțime de tranzacții și interacțiuni cu aplicația sa. că pur și simplu nu vor sau nu au nevoie pentru că este un fel de atac.

PAVAN TIRUPATI: Da, și la WP Engine, încercăm să facem ca Advanced Network, care este una dintre ofertele noastre de rețea, să fie implicit pentru toți clienții noștri, astfel încât aceștia să poată folosi acest nivel suplimentar de securitate. Și asistăm, de asemenea, la o creștere nemaivăzută până acum cu oferta noastră de securitate, GES, care este legată – mai atentă față de clienții care caută niveluri și straturi de securitate suplimentare. Și vine cu – GES este ceva care vine cu un firewall pentru aplicații web și Argo Smart Routing.

Dar un lucru pe care vreau să-l subliniez aici este că 65% dintre clienții WP Engine nu sunt în prezent în niciuna dintre aceste rețele. Argo Smart Routing și WAF este ceva de care ar putea beneficia cu siguranță. Așa că v-ați deranja să extindeți puțin despre modul în care acea rutare inteligentă și WAF funcționează din perspectiva Cloudflare.

SERGI ISASI: Sigur. Deci Argo este un produs foarte interesant. Este foarte unic pentru Cloudflare și este ceva care este puțin atrăgător dacă nu ești atât de familiarizat cu el. Așa că Argo ia acea telemetrie despre care vorbeam, telemetria de margine, și caută de fapt rute mai bune pe internet. Există o vorbă, în interior, este ca Waze pentru internet, care cred că funcționează. Nu este analogia mea preferată, dar este una rezonabilă.

Pentru că uneori rutele sunt ineficiente și nu sunt consistente. Așa că astăzi, poate fi mai rapid să mergi direct la origine și uneori nu este. Uneori, este mai logic să trecem de la o margine Cloudflare la alta pentru a evita un fel de congestie pe internet.

Principalul punct al Argo este că reduce eficiența ultimului kilometru atât de la utilizator la margine, cât și de la margine până la origine – pentru că probabil că nu vă difuzați tot conținutul de la margine astăzi – cu 40%. Și aceasta este o creștere masivă prin apăsarea unui buton și fără a necesita nici un fel de schimbare a codului pentru aplicație.

PAVAN TIRUPATI: Asta este de fapt destul de perspicace. Mulțumesc, Sergi. Ce schimbări ați observat pentru baza dvs. de clienți? Care este impactul practic al creșterii atacurilor și suprafața reală a atacurilor?

SERGI ISASI: Așa că cred că marea schimbare în 2020 și în 2021 este că am început să vedem creșterea atacurilor ransomware și a unui alt tip de ransomware, deci nu unul care a preluat punctul final și l-a criptat, ci mai degrabă vom ataca. tu și te dai jos dacă nu ne plătești.

În 2020, am văzut destul de multe dintre ele. În 2021, am văzut o creștere, dar o schimbare a modelului. Iar schimbarea tiparului a fost, mai degrabă decât a găsi o țintă în mod generic, a fost găsirea unei ținte în aceeași industrie. Deci, cel mai interesant este că am văzut o mulțime de companii de voce off IP și teleconferințe vizate. Are un fel de sens, nu? Deci, deoarece toată lumea lucra de la distanță mai mult, aceste servicii au fost critice. Și era important atât pentru utilizatori, cât și pentru furnizori să rămână online, astfel încât atacatorul să aibă o țintă foarte evidentă acolo.

Un lucru care rămâne adevărat este că inteligența comună este importantă. În timp ce vedeam că fiecare client este vizat, am văzut că aceleași modele apar și același model de atac merge la acele aplicații, ceea ce face mai ușor pentru cineva ca noi care vede acel trafic - ne face mai ușor să blocăm.

PAVAN TIRUPATI: Da, predictibilitatea sau modelele sunt de fapt bune în înțelegerea datelor, așa că înțeleg asta. Dar cum și unde ar trebui să se gândească dezvoltatorii din acest apel la protecție în general? Care este cel mai rău scenariu pe care l-ați văzut în trecut și pe care îl puteți împărtăși aici?

SERGI ISASI: Sigur. Deci, cel mai rău caz este un atac concentrat. Așadar, dacă cineva dorește cu adevărat să te ia offline, este extrem de dificil să te ocupi de acest tip de atacator motivat. Deci, este ceva de luat în considerare dacă rulați o aplicație care este într-un fel controversată sau poate avea un fel de inamic. Și astea sunt multe lucruri în zilele noastre.

Atacul pe care îl am aici este un exemplu că Adidas a avut 17,2 milioane de solicitări pe secundă. Deci, acesta nu este debit, este doar o cerere HTTP legitimă reală. Acestea nu au fost amplificate sau falsificate. Deci, acest atacator a avut acces la suficiente dispozitive care ar putea face aceste conexiuni și să le facă să pară legitime – sau, de fapt, erau legitime. Atacul extrem de distribuit. A avut o oarecare concentrare în unele regiuni, dar a fost văzut în marea majoritate a locațiilor noastre.

Și cel mai rău caz este că atenuarea a fost costisitoare. S-a făcut la stratul 7. Așa că a trebuit să acceptăm conexiunea. A trebuit să reziliem SSL – deci este o serie de strângeri de mână care merg înainte și înapoi – înainte de a putea renunța și identifica atacul față de traficul legitim. Deci, acesta este genul de lucru pe care, dacă încercați să rulați acest lucru pe un WAF on-premise sau ceva de genul acesta, va fi foarte, foarte scump doar să găsiți traficul, cu atât mai puțin să-l atenuați.

PAVAN TIRUPATI: Super. Mulțumesc, Sergi. Rămânând cu securitatea, în timpul războiului, așa cum asistăm acum cu Rusia și Ucraina, există o creștere așteptată a atacurilor cibernetice. De fapt, CIA și FBI au emis un aviz comun despre natura distructivă a acestor atacuri și cât de vulnerabile pot fi activele și datele critice în aceste vremuri. Ei recomandă tuturor organizațiilor, indiferent de dimensiune, să adopte o poziție sporită de securitate. Și la WP, vedem această tendință ascendentă și în cazul atacurilor.

Ce părere aveți despre pregătirea pentru astfel de evenimente? Și cum ne putem pregăti pentru astfel de situații? Unele dintre celelalte evenimente mari, altele decât războiul Rusia-Ucraina, care ne vin în minte este evenimentul Log4shell la care am fost martori anul trecut, care a afectat aproape o mulțime de aplicații din întreaga lume.

SERGI ISASI: Da, vreau să spun, trebuie să răspundem. Aceasta este lumea în care ne aflăm. Lucrurile se întâmplă și se întâmplă lucruri cu adevărat, foarte groaznice și trebuie să reacționăm la ele. În ceea ce privește Ucraina, nu putem împărtăși o mulțime de informații, dar unul dintre lucrurile pe care le putem împărtăși este, în timp ce traficul în Ucraina a rămas relativ consistent din perspectiva generală a utilizatorilor, am văzut că atenuările firewall-ului au crescut considerabil.

Deci, s-a trecut de la 8% tipic despre care am vorbit mai devreme la 30% din totalul cererilor. Și asta înseamnă că există doar mai mult trafic de atac amestecat cu traficul de utilizatori obișnuiți. Și din nou, la fel ca exemplul anterior, acestea sunt atenuări costisitoare, lucruri care trebuie făcute la nivelul 7, deoarece este dificil să le identifici din atacurile obișnuite doar bazate pe nivelul 4.

Vorbim despre Log4shell, acesta a fost probabil cel mai mare eveniment pe care mi-l amintesc de mult timp. Așa că acest lucru a lovit industria destul de greu. Îmi amintesc o mulțime de indivizi, ambii la Cloudflare, care citeau discuția internă și îmi amintesc doar că am mers, oh, oh, Doamne, asta este masiv.

Și a fost o vulnerabilitate și un bit foarte comun de software care i-a permis atacatorului să insereze unele caractere arbitrare, iar apoi prezența acelor caractere ar face ca software-ul să meargă și să emită o solicitare git pentru o adresă URL pe care atacatorul l-a inserat. Așa că toată lumea se bătea. Este posibil să nu vă cunoașteți dependențele. Acesta este un fel de lecție întâi, este să vă cunoașteți dependențele, să știți ce software rulați și ce software rulează acel software.

Dar cel mai mare lucru a fost că aici au fost o mulțime de fapte cu adevărat inteligente. Așadar, când am atenuat acest lucru pentru clienții noștri – și pentru clienții dvs. – am avut o mulțime de variații diferite ale regulilor noastre de firewall care au continuat să fie implementate deoarece existau prezența conținutului și diferite moduri prin care puteți codifica acel conținut.

Unul dintre lucrurile pe care le-am crezut că este cel mai interesant lucru pe care Log4j-ul este că l-am văzut în procesul de logare. Deci, chiar dacă ați crede că aplicația dvs. a fost suficient de firewall încât să nu primească o conexiune din lumea exterioară, dacă ați scos un eveniment de jurnal care conținea aceste caractere, va merge și va face acea cerere. Deci un simplu firewall nu a fost suficient.

Edge este important aici și foarte util, deoarece vă permite să aveți o modalitate rapidă și ușoară de a iniția controalele, indiferent dacă sunteți sigur dacă sunteți vulnerabil sau nu. Nu există niciun dezavantaj în a pune în aplicare controalele, care este un alt motiv pentru care l-am lansat chiar și pentru clienții noștri gratuiti. Deci punctul unic de control este de fapt foarte util în acest scenariu.

PAVAN TIRUPATI: Și care sunt unele dintre instrumentele sau tehnicile care sunt disponibile pentru clienți pentru a scala traficul în acest scenariu?

SERGI ISASI: Sigur, deci pentru orice scenariu, avem lucrători pe Cloudflare. Acest lucru vă permite să rulați codul pe marginea noastră și puteți construi orice doriți și nu vă faceți griji cu privire la scalarea orizontală.

Am introdus și un produs, la începutul lui 2021, numit Waiting Room. Sala de așteptare este ceva cu care probabil ești familiarizat. Te-ai dus să cumperi ceva și ai fost pus într-o coadă pentru a decide dacă era suficient din acel lucru de cumpărat. Poate funcționa și pentru o aplicație. Vă puteți conecta la site și aveți o experiență bună? Sau ar trebui să aștepți?

Acesta este de fapt un produs cu adevărat interesant pe care l-am construit. L-am construit pe margine și folosind lucrători Cloudflare. Și asta a fost dificil. Probabil că este un produs mai simplu de construit la bază. Acesta nu este ADN-ul lui Cloudflare. Putem construi lucruri pe margine și, într-adevăr, ne uitam la scalare. Dacă încerci să scalați ceva la bază, devine mult mai dificil.

Marea problemă pe care am avut-o când construiam sala de așteptare este împărțirea stării. Așadar, ați vrut ca utilizatorii să aibă o experiență în sala de așteptare, la nivel global. Și vorbeam despre peste 200 de locații. Nu e ușor.

Așa că vă voi da un exemplu. Să presupunem că este un concert aici, în Bay Area. Cei mai mulți cumpărători pentru acel concert vor fi în Bay Area și probabil se vor conecta la centrul nostru de date din San Jose. Cu toate acestea, unii nu sunt. Veți avea o mână sau un anumit procent de cumpărători din întreaga lume care zboară la concert sau poate călătoresc în acel moment.

Deci, cum o faci corect? Nu puteți avea o coadă pentru utilizatori în Bay Area și o coadă pentru utilizatori este în orice altă locație. Asta ne-a impus să ne gândim cum putem împărți starea peste margine. Și cred că aici este locul în care viitorul se îndreaptă într-un fel.

Și folosim propriul nostru produs Durable Objects – îl puteți vedea aici pe diapozitiv – pentru a sincroniza și a partaja starea în toate locațiile. Dar, pe măsură ce noi, ca industrie, căutăm să rezolvăm mai multe dintre aceste probleme la margine, cred că veți începe să vedeți mult mai multe cazuri de utilizare a software-ului la margine în care starea de partajare este încă dificilă și ce faceți despre consecvență, dacă este un fel de eventual sau imediat? Și cred că acesta este viitorul software-ului nostru.

PAVAN TIRUPATI: Super. Mulțumesc, Sergi. Știu, la WP Engine, avem această mentalitate de vârf pentru a ne asigura că oferim performanță și securitate clienților noștri. Sergi, care sunt gândurile tale finale sau sfaturile tale sau considerațiile sau sugestiile de top pentru dezvoltatorii aflați în apel, care construiesc la margine?

SERGI ISASI: Deci cred că, în primul rând, construiești la locul potrivit. Și în al doilea rând, cred că este să fii creativ. Sunt o mulțime de lucruri pe care dacă m-ai fi întrebat, acum un an, dacă le putem face la margine, aș fi spus, eh, nu știu. Eu nu cred acest lucru. Și există doar un ritm mai rapid de inovație pe care îl găsești aici și o mulțime de dezvoltatori creativi care se gândesc la problemele la care te gândești și vin cu soluții atât din partea clientului, cât și a produsului.

Un alt lucru interesant este un fel de a comunica și de a împărtăși. Am văzut o mulțime de mișcări, în special în dezvoltatorii Discords, de a găsi modalități noi și creative de a rezolva probleme și de a construi mai multe lucruri la margine. Cred, în sfârșit, ca un plug pentru Cloudflare, dacă există ceva ce nu puteți face, găsiți un manager de produs Cloudflare. Trimite-ne un e-mail, găsește-ne pe Twitter sau orice altceva și spune-ne ce vrei să construiești și vom vedea dacă nu te putem ajuta să-l construiești.

PAVAN TIRUPATI: Asta e grozav. Și cred că este corect să spun că edge nu mai este un caz de margine, pentru că dacă securitatea și performanța sunt concentrarea ta, atunci edge este locul potrivit.

Așa că îți mulțumesc, Sergi, pentru acele cuvinte grozave despre margine. Sper că ați găsit utilă această sesiune. Vă mulțumim pentru timpul acordat și pentru că v-ați alăturat nouă. Sper să aveți un rest bun al zilei.

PREZENTATOR: Și aceasta este o încheiere pentru DE{CODE} 2022. Sper că v-a părut inspirat și că plecați cu mai multă expertiză WordPress și noi conexiuni cu comunitatea. Uitați-vă la conținutul înregistrat pe site de vineri pentru a ajunge din urmă cu orice ați ratat sau vizionați din nou un videoclip.

Vreau să le mulțumesc final partenerilor noștri sponsori – Amsive Digital, Box UK, Candyspace, Draw, Elementary Digital, Illustrate Digital, Kanopi Studios, Springbox, Studio Malt, StrategiQ, WebDev Studios și 10Up. Vă mulțumim enorm pentru donația pentru strângerea de fonduri DECODE. Apreciem cu adevărat generozitatea dumneavoastră.

Acum, pentru toți cei care au interacționat cu noi în Centrul nostru pentru participanți și în sesiunile noastre, vom alege primii trei câștigători și vă vom anunța cum vă puteți revendica premiul la sfârșitul DE{COD}E. Așteptăm cu nerăbdare să vă revedem în evenimentele noastre viitoare, fie în persoană, fie virtual. Abia așteptăm să vă aducem mai multe despre cele mai recente tendințe de dezvoltare WordPress și despre cum le puteți implementa pentru a construi site-uri WordPress mai rapid. Asta e tot de la mine. Vă mulțumim foarte mult că ne-ați alăturat și aveți grijă.