DE{CODE}: Por que o Edge não é um caso de Edge

Quando você está no limite, a velocidade, a segurança e a integridade do servidor não podem ser deixadas de lado. Nesta sessão, o vice-presidente de produto da Cloudflare, Sergi Isasi, e o gerente de produto do WP Engine, Pavan Tirupati, discutem por que ter uma mentalidade de vanguarda é essencial para o sucesso de cada site que você cria ou mantém.

Slides da Sessão

Transcrição de texto completo

PAVAN TIRUPATI : Olá pessoal. Obrigado por se juntar a nós nesta sessão sobre como a idade não é realmente um caso extremo. Sou Pavan Tirupati, gerente de produto da WP Engine com a equipe The Outreach, e sou o principal responsável pela segurança, desempenho e confiabilidade da borda para crescer e capacitar os clientes da WP Engine.

E juntando-se a nós hoje da Cloudflare está Sergi, vice-presidente de gerenciamento de produtos. Sergi, gostaria de se apresentar?

SERGI ISASI : Claro. Obrigado por me receber, Pavan. E obrigado a todos por se juntarem à nossa sessão. Então, como disse Pavan, sou vice-presidente de produto para desempenho de aplicativos na Cloudflare, focado no desempenho e na confiabilidade de nossa borda. Queremos tornar as coisas rápidas e confiáveis ​​para todos os nossos clientes. Os produtos que abordo são como a Cloudflare recebe e processa o tráfego na borda, tanto na camada 4 quanto na 7. Isso inclui nosso cache, nosso proxy, espectro FL, tecnologia fundamental para a Cloudflare, como nossos sistemas DNS, nossos sistemas de gerenciamento de certificados e nossos Sistemas de gerenciamento de endereço IP e também os novos aplicativos de borda, balanceamento de carga, nosso novo produto Waiting Room e nossos próximos produtos Web3.

Estou na Cloudflare há cerca de 4 anos e meio. E novamente, feliz por estar aqui hoje.

PAVAN TIRUPATI: Sensacional. E hoje, temos uma sessão maravilhosa para vocês enquanto nos aprofundamos no que exatamente é o edge e como ele é útil e, como o título diz, por que o edge não é mais um caso extremo. A agenda que temos para vocês é aprofundar o que é vantagem e quais são os benefícios dela. E nestes tempos, é fundamental focar mais na segurança.

E vamos falar sobre alguns exemplos e falar sobre algumas ameaças de segurança. Também veremos como o edge será benéfico para o público que está aqui e para todos que têm presença digital no mundo. E também veremos alguns exemplos específicos que podem ser benéficos para pessoas que podem estar passando por algumas dessas ameaças e problemas de segurança.

Portanto, será emocionante, engenhoso e perspicaz. Então, vamos começar definindo algum contexto aqui. Eu quero definir uma linha de base do que é vantagem. E acho que não é uma surpresa para ninguém quando digo que as empresas estão passando por uma mudança para uma cultura de construtor, baseada na capacidade dos desenvolvedores de criar e controlar experiências digitais diretamente.

À medida que sites e aplicativos passam de construções monolíticas para uma arquitetura de microsserviços, a capacidade de fornecer conteúdo de diversas fontes torna-se cada vez mais importante. E sabemos e entendemos a vantagem de fazer parte da Internet que está realmente mais próxima de nossos usuários finais, às vezes também chamada de última milha. Mas antes de entrar nos detalhes, Sergi, quero definir o nível para o público sobre o que é o limite e por que é crítico.

SERGI ISASI: Claro. Portanto, há um ditado antigo na computação em nuvem, que é “nuvem é apenas o computador de outra pessoa”. Eu realmente gosto deste ditado. Isso significa que é a mesma coisa que você teria em seu desktop ou laptop, mas é apenas outra pessoa que está gerenciando. E a borda é exatamente a mesma coisa, apenas mais perto do usuário.

Por que isso é importante? Queremos que as coisas sejam – na Cloudflare – o mais próximo possível do usuário. E tudo se resume àquela afirmação que você disse, que é a última milha. Portanto, não importa o quão rápido você crie seu software, o quão eficiente você pode torná-lo, se você responder a algo - se o seu software puder ser executado em submilissegundos, você ainda estará em dívida com a velocidade da luz. E se o seu software não estiver no dispositivo do usuário ou o mais próximo possível do usuário, o usuário experimentará um pouco de latência. E às vezes essa latência é boa e às vezes é muito, muito chocante para o usuário final. Portanto, o objetivo é otimizar o que faz sentido estar próximo ao usuário final na borda ou o que está próximo ao núcleo.

E o que a Cloudflare faz é tentar colocar tudo no limite. Acho que uma das razões pelas quais você me pediu para fazer este bate-papo é porque administramos uma das maiores redes de borda do mundo e obviamente estamos incrivelmente orgulhosos disso. A Cloudflare tem pouco mais de 10 anos e estamos construindo essa rede o tempo todo. Ele cresceu para estar em 250 cidades, 100 países diferentes, com o objetivo – e realmente alcançamos esse objetivo – de estar a 50 milissegundos de 95% dos usuários da Internet em todo o mundo. E isso, novamente, última milha - se pudermos chegar a 50 milissegundos, podemos ser muito mais rápidos para cada um desses usuários finais.

A outra parte é conectar-se a outras redes. Então, nos conectamos a 10.000 outras redes em todo o mundo, muitos ISPs locais, por exemplo, e também operamos nosso próprio backbone, então fazemos o backhaul desse tráfego para quando precisamos ir para o núcleo ou para a origem, faça isso Ainda mais rápido. Encerramos 2021 com pouco mais de 100 terabits por segundo de capacidade. E isso é importante quando se trata de escalabilidade horizontal, tanto para aumentos de tráfego para nossos clientes quanto para aumentos de ataques a nossos clientes e também à nossa própria rede.

Uma das coisas que tem sido interessante sobre a computação nos últimos 30, 40 anos é sua transição, para frente e para trás, da borda ao núcleo e ao cliente, dependendo de onde fazia sentido e onde estava todo o poder da computação naquele momento. Então, se você pensar desde a internet pré-pública, você tinha mainframes. Você tinha muito poder de computação no núcleo e muito pouco poder de computação na borda e quantidades realmente pequenas de largura de banda para fazer a transição para frente e para trás. Então você estava enviando comandos para o mainframe e ele enviaria de volta os resultados desses comandos em texto.

Fizemos a transição de lá para muitos avanços no endpoint, para que você tivesse muitos clientes gordos - Windows, Microsoft Word, todas essas coisas que agora você fazia muito cálculo no endpoint e depois enviava de volta para, normalmente, o núcleo para compartilhar esse conteúdo.

À medida que a borda e o núcleo ficaram mais fortes, você começou a ver aplicativos em nuvem. Portanto, em vez de fazer essa alteração em seu dispositivo, você fez a alteração em um navegador da Web e isso foi propagado por outros dispositivos para compartilhamento. E isso se tornou muito importante quando tínhamos dispositivos móveis, especialmente os primeiros dispositivos móveis que tinham menos computação, mas muito mais largura de banda.

Então, por que isso é crítico? É realmente tudo sobre as expectativas do usuário quanto à velocidade. Portanto, o usuário sempre deseja uma boa experiência de usuário. E especialmente hoje, a ideia de uma boa experiência do usuário é meio que uma interação instantânea. Clico em um link, pressiono um botão, algo acontece e não me importa onde aconteceu. Posso nem saber onde aconteceu, mas quero que seja rápido.

A outra coisa que mudou é o ambiente em que nos encontramos. Portanto, há significativamente mais ataques, principalmente porque esses dispositivos se tornaram mais poderosos. E então vemos muitas mudanças nos regulamentos, pois a segurança e a privacidade não apenas se tornam as principais preocupações dos usuários, mas também dos governos. E é por isso que a Cloudflare continua adicionando POPs. Vemos mais usuários, vemos mais tráfego, vemos mais ataques e vemos mais casos de uso que poderíamos colocar na borda e tornar poderosos para esses usuários finais.

PAVAN TIRUPATI: Sensacional. Podemos nos aprofundar um pouco no pop? O que é POP? E o que mudou nos POPs ao longo do tempo? E analisando especificamente a implementação do POP na Cloudflare, o que é único?

SERGI ISASI: Obrigado por trazer isso de volta. Eu digo muito POPs e devo especificar o que isso significa. É um ponto de presença na Internet. E no caso da Cloudflare e na maioria dos outros casos, quando você ouve alguém falar sobre um POP, o que isso significa é uma pilha de servidores, em algum lugar, que executa o software.

No que diz respeito ao que mudou ao longo do tempo, é realmente mais fácil falar sobre o que mudou versus o que não mudou. E vamos entrar um pouco nisso. Portanto, estamos em nossa 11ª geração de servidores. Escrevemos sobre cada uma dessas iterações em nosso blog. Portanto, continuamos obtendo computadores mais rápidos na borda, o que é ótimo. Isso significa custos mais baixos, mais recursos e, em geral, coisas melhores para os usuários finais.

Uma das coisas interessantes que mudou ao longo do tempo é que implementamos em três arquiteturas de CPU diferentes – ou, na verdade, em duas arquiteturas de CPU diferentes, de três fabricantes. Portanto, executamos Intel e AMD e também executamos ARM em nossa borda.

A outra coisa que mudou ao longo do tempo é que continuamos adicionando locais. Não está claro para mim quantos tínhamos quando lançamos há mais de 10 anos. Estava na faixa das dezenas. Mas há uma história engraçada de nosso CTO que foi um dos primeiros fãs da Cloudflare, conhecia nossos fundadores, mas se recusou a ingressar na Cloudflare até conseguir um POP perto de onde estava na Europa. Ele disse, quando isso vai acontecer? E então eu vou participar.

Nossas localizações cresceram primeiro com base na demanda. Então você vê muito tráfego em uma região, na verdade é mais barato, geralmente, colocar hardware em uma região e atender o tráfego lá. Então começamos a fazer isso no começo.

Quando crescemos, começamos a ver parceiros locais ou ISPs nos pedindo para construir hardware na região para tornar as coisas mais eficientes para eles e seus usuários finais. Então esse foi um tipo interessante de mudança radical no mundo de Cloudflare.

Nosso objetivo original era estar a 100 milissegundos dos usuários finais. E então percebemos que poderíamos fazer melhor. Então agora temos a meta de 50 milissegundos. E eu não ficaria surpreso se você visse isso diminuir ainda mais com o passar dos anos.

O que não mudou é que nós, desde o início, fizemos uma escolha única e bastante fatídica, que seria executar o mesmo software em todos os servidores de ponta em todos os locais. Isso acabou sendo uma escolha mais fácil para a maioria de nossas equipes de engenharia. Sabemos o que está sendo executado em cada dispositivo e você pode solucionar problemas e executar as coisas com um pouco mais de eficiência. Algumas de nossas equipes de engenharia têm muito mais trabalho por causa disso também.

Isso torna as coisas muito mais fáceis de escalar, tanto a longo quanto a curto prazo. A curto prazo, permite mover recursos para diferentes serviços conforme necessário, dependendo da carga e do que está acontecendo naquele local naquele momento. Podemos dimensionar horizontalmente em todas as máquinas.

A longo prazo, isso nos permite decidir proativamente para onde as novas máquinas precisam ir, porque sabemos que precisamos executar toda a pilha. A outra grande vantagem, para nossas equipes de engenharia e especificamente nossas equipes de engenharia de produto, é que temos desempenhos consistentes em todos os serviços. Não nos preocupamos que algum local esteja mais próximo de determinados tipos de usuários e, portanto, seja mais rápido e tenha uma experiência diferenciada. Vai ser consistente em todos os servidores e em todo o mundo.

E uma das grandes mudanças que tivemos - provavelmente já faz três anos neste momento - é que agora permitimos que nossos clientes executem seu código em nosso edge por meio de nosso produto Workers. E a grande vantagem é que quando esse cliente escolhe implantar seu produto, ele realmente seleciona a região do mundo. Não os forçamos a dizer, quero concorrer no oeste dos EUA ou o que quer que seja. Seu software é implantado em todos os locais e funciona o mais próximo possível do globo ocular.

PAVAN TIRUPATI: Ótimo. Então, como a borda se compara ao núcleo?

SERGI ISASI: Claro. Então, meio que depende da sua arquitetura. E para algumas arquiteturas, a borda é o núcleo e o núcleo é a borda. Se você tem apenas um lugar, você está fazendo tudo de uma vez.

Geralmente, porém, a borda será mais rápida e eficiente para computação e o núcleo é onde você guarda segredos e configurações e envia dados do núcleo para a borda.

PAVAN TIRUPATI: E a Cloudflare tem núcleo? E se sim, como é implementado?

SERGI ISASI: Desde o primeiro dia, sim. E não falamos muito sobre isso. É meio interessante. Mas se você pensar bem, fomos fundados em 2009 e, portanto, administrar tudo no limite era incrivelmente impraticável em 2009 e, para algumas coisas, impraticável agora.

Então, o que executamos no núcleo? Gerenciamento de configuração - então temos que empurrar o software. e temos que fazer isso de algum lugar, então ainda empurramos o software Cloudflare, todas as nossas novas versões, empurramos nosso código, todos os dias, do nosso núcleo até a borda. E também executamos a configuração do cliente que ainda se comunica com nossos principais data centers. E vai de lá para fora até a borda. E na verdade é uma história interessante aqui do WP Engine e nosso software DNS.

Assim, no início, a Cloudflare executava o PowerDNS, um software DNS de código aberto. E começamos a construir algo que chamamos internamente de RR DNS, nosso próprio software de DNS, em 2013. E um software muito eficiente. Tínhamos algumas zonas com centenas de milhares de registros e tudo estava indo relativamente bem com esses requisitos. E então o WP apareceu e eles disseram que temos mais de um milhão de registros em nossa zona. E a velocidade de atualização, portanto, a capacidade de fazer uma alteração e levá-la ao nosso limite foi incrivelmente crítica, porque significava que um cliente estava sendo integrado e que precisava ter essa experiência. E este foi um caso real para nós. Então, analisamos isso e dissemos: OK, obviamente precisamos retrabalhar como gerenciamos nosso núcleo e enviar esse tráfego para a borda para lidar com o tamanho desse conteúdo, a velocidade e a frequência com que você o atualiza.

Então, em 2016, um de nossos engenheiros de DNS, Tom Arnfeld, perguntou se ele poderia se sentar com o WP Engine para realmente entender o que você queria e por que queria, e como seria em 2017, e como seria em 2022, agora que estamos há cinco anos nisso. E então, o que fizemos em 2017 foi, na verdade, reescrever todas as estruturas de dados para nosso software DNS para fazer com que, a pedido de nosso CEO, os dados fossem movidos da borda como mágica. Na verdade, foi uma daquelas coisas em que tínhamos um cliente com uma necessidade, queríamos atender a essa necessidade, mas tivemos que repensar como movemos os dados do núcleo para a borda.

Outra coisa que ainda fazemos no núcleo é a análise. Portanto, a telemetria vem da borda para o núcleo. Nossos clientes, quando visualizam suas análises, vão para um painel ou uma API, e tudo isso é servido a partir do núcleo.

Com o tempo, o tamanho do cliente e o aumento da sofisticação do ataque realmente nos fizeram repensar como fazíamos a telemetria. Costumávamos executar, por exemplo, todo o nosso software de detecção de DDoS no núcleo. Portanto, a telemetria viria da borda, diria o núcleo, que se parece com um DDoS e enviaria dados de volta para a borda para mitigar. Isso é suficiente para alguns ataques DDoS, mas para outros, precisamos realmente tomar essa decisão no limite. Então, aumentamos nosso sistema Gatebot original, que executa o núcleo com alguns novos sistemas, em meados do ano passado, que na verdade são executados na borda e tomam decisões independentes do núcleo e, em seguida, relatam, adaptando-se continuamente ao ataque superfície.

A última coisa sobre a qual falarei no núcleo é que fazemos a maior parte de nosso aprendizado de máquina no núcleo hoje. Nós nos apoiamos fortemente no aprendizado de máquina para, especificamente, produtos de segurança. Mas queremos fazer mais disso na borda porque vemos, provavelmente, um padrão semelhante com o sistema DDoS. Por isso, fizemos uma parceria com a NVIDIA para começar a executar mais do nosso ML também na borda.

PAVAN TIRUPATI: Sergi, você mencionou DDoS e segurança. Quero me aprofundar um pouco nisso, especificamente porque a segurança é altamente crítica. Quais são algumas das tendências e coisas que você está vendo?

SERGI ISASI: Claro, um recorde quebrado por nós, mas os ataques DDoS estão quebrando recordes. Quebramos esse recorde ano após ano. A razão para isso é que os botnets estão crescendo em tamanho e aproveitando dispositivos mais poderosos. Portanto, se você pensar em como seu telefone celular está muito mais rápido agora ou seu computador em relação ao ano anterior, faz sentido que eles estejam obtendo cada vez mais capacidade para lançar grandes ataques, taxa de transferência tão significativa, lutamos contra um Ataque de “2 terabytes por segundo” há pouco tempo – é o segundo maior de que ouvimos falar – e também ataques mais inteligentes que podem fazer coisas sem muita taxa de transferência, mas talvez muitas solicitações e solicitações caras.

Realmente o que estamos falando aqui é mais sofisticação de ataques. E a estatística que eu acho mais interessante, algo que nós

que acabamos de falar, é que 8% do tráfego em nossa borda é mitigado. Portanto, antes de fazermos qualquer tipo de regra ou algo assim, 8% são descartados completamente, o que significa que, para um cliente que está pensando em fazer segurança na borda, ele pode se livrar rapidamente de muitas transações e interações em seu aplicativo que eles simplesmente não querem ou precisam porque é algum tipo de ataque.

PAVAN TIRUPATI: Sim, e no WP Engine, estamos tentando tornar a Rede Avançada, que é uma de nossas ofertas de rede, padrão para todos os nossos clientes, para que possam aproveitar essa camada adicional de segurança. E também estamos testemunhando um crescimento nunca antes visto com nossa oferta de segurança, GES, que está relacionada – mais sintonizada com os clientes que buscam níveis e camadas adicionais de segurança. E vem com– GES é algo que vem com um firewall de aplicativo da web e o Argo Smart Routing.

Mas uma coisa que quero destacar aqui é que 65% dos clientes do WP Engine atualmente não estão em nenhuma dessas redes. Argo Smart Routing e WAF é algo com o qual eles definitivamente poderiam se beneficiar. Então, você se importaria em expandir um pouco sobre como esse roteamento inteligente e o WAF funcionam na perspectiva do Cloudflare?

SERGI ISASI: Claro. Então Argo é um produto muito interessante. É muito exclusivo do Cloudflare e é algo que é um pouco alucinante se você não estiver familiarizado com ele. Então Argo pega aquela telemetria de que eu estava falando, a telemetria de borda, e realmente procura rotas melhores na Internet. Há um ditado interno, é como o Waze para a internet, que eu acho que funciona. Não é minha analogia favorita, mas é razoável.

Porque às vezes as rotas são ineficientes e não são consistentes. Então, hoje, pode ser mais rápido ir direto para a origem e às vezes não. Às vezes, faz mais sentido irmos de uma borda Cloudflare para outra para contornar algum congestionamento da Internet.

O grande ponto do Argo é que ele reduz a eficiência da última milha do usuário para a borda e da borda para a origem – porque você provavelmente não está servindo todo o seu conteúdo da borda hoje – em 40%. E isso é um aumento enorme basicamente pressionando um botão e não exigindo nenhum tipo de alteração de código para o aplicativo.

PAVAN TIRUPATI: Na verdade, isso é bastante perspicaz. Obrigado, Sergi. Que mudanças você observou em sua base de clientes? Qual é o impacto prático do aumento dos ataques e a superfície real dos ataques?

SERGI ISASI: Então, acho que a grande mudança em 2020 e em 2021 é que começamos a ver o aumento de ataques de ransomware e um tipo diferente de ransomware, então não um que assumiu o controle do endpoint e o criptografou, mas vamos atacar você e derrubá-lo se você não nos pagar.

Em 2020, vimos um pouco disso. Em 2021, vimos um aumento, mas uma mudança de padrão. E a mudança de padrão foi, em vez de encontrar um alvo genérico, foi encontrar um alvo no mesmo setor. Portanto, o interessante é que vimos muitas empresas de IP de locução e teleconferência serem alvos. Meio que faz sentido, certo? Então, como todos estavam trabalhando mais remotamente, esses serviços eram críticos. E era importante que tanto os usuários quanto os provedores permanecessem online, para que o invasor tivesse um alvo muito óbvio ali.

Uma coisa que ainda permanece verdadeira é que a inteligência compartilhada é importante. Enquanto víamos todos os clientes sendo direcionados, víamos os mesmos padrões e o mesmo padrão de ataque indo para esses aplicativos, o que torna mais fácil para alguém como nós que vê esse tráfego - torna mais fácil para nós bloquearmos.

PAVAN TIRUPATI: Sim, previsibilidade ou padrões são realmente bons para entender os dados, então eu entendo isso. Mas como e onde os desenvolvedores desta chamada devem pensar sobre proteção em geral? Qual é o pior cenário que você viu no passado que pode compartilhar aqui?

SERGI ISASI: Claro. Portanto, o pior cenário é um ataque focado. Portanto, se alguém realmente deseja colocá-lo offline, é extremamente difícil lidar com esse tipo de invasor motivado. Portanto, é algo a considerar se você estiver executando um aplicativo que é de alguma forma controverso ou pode ter algum tipo de inimigo. E isso é um monte de coisas hoje em dia.

O ataque que tenho aqui é um exemplo da Adidas com 17,2 milhões de requisições por segundo. Portanto, isso não é taxa de transferência, é apenas uma solicitação HTTP legítima real. Estes não foram amplificados ou falsificados. Portanto, esse invasor tinha acesso a dispositivos suficientes que poderiam fazer essas conexões e fazê-las parecer legítimas ou, na verdade, eram legítimas. Ataque extremamente distribuído. Teve alguma concentração em algumas regiões, mas foi visto na grande maioria das nossas localidades.

E o pior cenário é que a mitigação foi cara. Foi feito na camada 7. Então tivemos que aceitar a conexão. Tivemos que encerrar o SSL - então são vários apertos de mão indo e voltando - antes que pudéssemos nos defender e identificar o ataque contra o tráfego legítimo. Portanto, esse é o tipo de coisa que, se você estiver tentando executar isso em um WAF local ou algo assim, será muito, muito caro apenas encontrar o tráfego, muito menos mitigá-lo.

PAVAN TIRUPATI: Ótimo. Obrigado, Sergi. Continuando com a segurança, durante os tempos de guerra, como estamos testemunhando com a Rússia e a Ucrânia agora, espera-se um aumento nos ataques cibernéticos. Na verdade, a CIA e o FBI emitiram um comunicado conjunto sobre a natureza destrutiva desses ataques e como ativos e dados críticos vulneráveis ​​podem estar durante esses tempos. Eles recomendam que todas as organizações, independentemente do tamanho, adotem uma postura elevada de segurança. E no WP, também estamos vendo essa tendência de alta nos ataques.

Qual é a sua opinião sobre a prontidão para eventos como este? E como podemos nos preparar para tais situações? Alguns dos outros grandes eventos além da guerra Rússia-Ucrânia que vem à mente é o evento Log4shell que testemunhamos no ano passado, que impactou praticamente muitos aplicativos em todo o mundo.

SERGI ISASI: Sim, quero dizer, temos que responder. Esse é o mundo em que estamos. As coisas acontecem, e coisas realmente terríveis acontecem, e temos que reagir a elas. No que diz respeito à Ucrânia, não podemos compartilhar muitas informações, mas uma das coisas que podemos compartilhar é que, embora o tráfego na Ucrânia tenha permanecido relativamente consistente do ponto de vista geral do usuário, vimos as mitigações de firewall aumentarem consideravelmente.

Portanto, passou dos típicos 8% sobre os quais falamos anteriormente para até 30% do total de solicitações. E isso significa que há apenas mais tráfego de ataque misturado ao tráfego regular de usuários. E, novamente, assim como no exemplo anterior, essas são mitigações caras, coisas que precisam ser feitas na camada 7 porque é difícil identificá-las a partir de ataques regulares baseados apenas na camada 4.

Falamos sobre o Log4shell, que provavelmente foi o maior evento de que me lembro em muito tempo. Portanto, isso atingiu bastante a indústria. Lembro-me de muitos indivíduos, tanto na Cloudflare, lendo a discussão interna, e lembro-me de dizer, oh, oh Deus, isso é enorme.

E foi uma vulnerabilidade e um software muito comum que permitiu ao invasor inserir alguns caracteres arbitrários e, em seguida, a presença desses caracteres faria com que o software emitisse uma solicitação git para uma URL que o invasor inseriu. Então todo mundo estava lutando. Você pode não conhecer suas dependências. Esse é o tipo de lição um, é conhecer suas dependências, saber qual software você está executando e qual software esse software está executando.

Mas o importante é que havia muitas façanhas realmente inteligentes aqui. Então, quando estávamos mitigando isso para nossos clientes - e para seus clientes - tínhamos muitas variações diferentes de nossas regras de firewall que precisavam ser implantadas porque havia a presença de conteúdo e diferentes maneiras de codificar esse conteúdo.

Uma das coisas que achei mais interessante sobre o Log4j é que o vimos no pipeline de registro. Portanto, mesmo que você pense que seu aplicativo foi protegido por firewall o suficiente para não receber uma conexão do mundo externo, se você extraísse um evento de log que tivesse esses caracteres, ele ainda faria essa solicitação. Portanto, um simples firewall não era suficiente.

O Edge é importante aqui e muito útil porque permite que você tenha uma maneira rápida e fácil de iniciar os controles, independentemente de ter certeza se está vulnerável ou não. Não há desvantagem em colocar os controles no lugar, o que é outro motivo pelo qual o implementamos até mesmo para nossos clientes gratuitos. Portanto, o ponto de controle único é super útil nesse cenário.

PAVAN TIRUPATI: E quais são algumas das ferramentas ou técnicas que estão disponíveis para os clientes dimensionarem o tráfego nesse cenário?

SERGI ISASI: Claro, para qualquer cenário, temos trabalhadores no Cloudflare. Isso permite que você execute seu código em nossa borda e você pode construir o que quiser e não se preocupar em escalar horizontalmente.

Também lançamos um produto, no início de 2021, chamado Waiting Room. A sala de espera é algo com o qual você provavelmente está familiarizado. Você foi comprar algo e foi colocado em uma fila para decidir se havia o suficiente para comprar. Também pode funcionar para um aplicativo. Você pode se conectar ao site e ter uma boa experiência? Ou você deve esperar?

Este é realmente um produto muito interessante que construímos. Nós o construímos na borda e usando trabalhadores Cloudflare. E isso foi difícil. É provavelmente um produto mais simples de construir no núcleo. Esse não é o DNA da Cloudflare. Podemos construir coisas no limite e, na verdade, estávamos olhando para o dimensionamento. Se você tentar escalar algo no núcleo, torna-se muito mais difícil.

O grande problema que tivemos quando estávamos construindo a sala de espera é o compartilhamento de estado. Então você queria que os usuários tivessem uma experiência de sala de espera, globalmente. E estávamos falando de mais de 200 locais. Isso não é fácil.

Então vou te dar um exemplo. Digamos que haja um show aqui na Bay Area. A maioria dos compradores desse show estará na Bay Area e provavelmente se conectará ao nosso data center em San Jose. No entanto, alguns não são. Você terá um punhado ou uma porcentagem de compradores que estarão em todo o mundo que voam para o show ou talvez estejam viajando naquele momento.

Então, como torná-lo justo? Você não pode ter uma fila para usuários na Bay Area e uma fila para usuários em todos os outros locais. Isso exigiu que pensássemos como podemos compartilhar o estado além da borda. E acho que é aqui que o futuro está indo para o limite.

E usamos nosso próprio produto Durable Objects - você pode vê-lo aqui no slide - para sincronizar e compartilhar o estado em todos os locais. Mas como nós, como indústria, procuramos resolver mais desses problemas na borda, acho que você começará a ver muito mais casos de uso de software na borda, onde o estado de compartilhamento ainda é difícil, e o que você faz sobre consistência, se isso é meio eventual ou imediato? E acho que esse é o futuro do nosso software.

PAVAN TIRUPATI: Ótimo. Obrigado, Sergi. Eu sei, no WP Engine, temos essa mentalidade de ponta para garantir que estamos oferecendo desempenho e segurança aos nossos clientes. Sergi, quais são seus pensamentos finais ou palavras de conselho ou principais considerações ou sugestões para os desenvolvedores da chamada que estão construindo na borda?

SERGI ISASI: Então eu acho que, antes de tudo, você está construindo no lugar certo. E em segundo lugar, acho que é ser criativo. Há muitas coisas que se você tivesse me perguntado, um ano atrás, se poderíamos fazer no limite, eu teria dito, eh, não sei. Eu não acho. E há apenas um ritmo mais rápido de inovação que você encontra aqui e muitos desenvolvedores criativos que estão pensando nos problemas em que você está pensando e apresentando soluções tanto do lado do cliente quanto do produto.

Outra coisa interessante é meio que se comunicar e compartilhar. Vimos muito movimento, principalmente nos Discords dos desenvolvedores, para encontrar maneiras novas e criativas de resolver problemas e criar mais coisas no limite. Acho que, por último, como um plug para Cloudflare, se houver algo que você não possa fazer, encontre um gerente de produto Cloudflare. Envie-nos um e-mail, encontre-nos no Twitter, ou qualquer outra coisa, e deixe-nos saber o que você deseja construir e veremos se podemos ajudá-lo a construí-lo.

PAVAN TIRUPATI: Que legal. E acho que é justo dizer que o edge não é mais um caso extremo, porque se segurança e desempenho são o seu foco, então o edge é o lugar certo.

Então, obrigado, Sergi, por essas ótimas palavras sobre o edge. Espero que vocês tenham achado esta sessão útil. Obrigado por dedicar seu tempo e se juntar a nós. Espero que tenham um bom resto de dia.

APRESENTADOR: E isso é um encerramento para DE{CODE} 2022. Espero que você tenha achado inspirador e esteja saindo com mais experiência em WordPress e novas conexões com a comunidade. Fique de olho no conteúdo gravado no site a partir de sexta-feira para atualizar o que você pode ter perdido ou assistir a um vídeo novamente.

Quero deixar um agradecimento final aos nossos parceiros patrocinadores – Amsive Digital, Box UK, Candyspace, Draw, Elementary Digital, Illustrate Digital, Kanopi Studios, Springbox, Studio Malt, StrategiQ, WebDev Studios e 10Up. Um enorme obrigado por doar para a nossa angariação de fundos DECODE. Nós realmente apreciamos sua generosidade.

Agora, para todos que interagiram conosco em nosso Centro de participantes e em nossas sessões, escolheremos os três primeiros vencedores e informaremos como você pode reivindicar seu prêmio no final do DE{COD}E. Esperamos vê-lo novamente em nossos eventos futuros, pessoalmente ou virtualmente. Mal podemos esperar para trazer a você mais sobre as últimas tendências de desenvolvimento do WordPress e como você pode implementá-las para criar sites WordPress mais rapidamente. Isso é tudo de mim. Muito obrigado por se juntar a nós e cuide-se.