Há cerca de quatro anos, anunciamos o Cloudflare Workers, uma plataforma sem servidor que é executada diretamente na borda.
Ao longo desta semana, vamos falar sobre as muitas formas pelas quais a Cloudflare está ajudando a tornar mais rápidos os aplicativos que já existem na web. Mas se hoje for o dia em que você decidir dar vida à sua ideia, desenvolver seu projeto na borda da Cloudflare e implantá-lo diretamente nos tubos da internet é a melhor maneira de garantir que seu aplicativo sempre seja rápido, para todos os usuários, independentemente da sua localização.
Já se passaram alguns anos desde que falamos sobre a comparação entre o Cloudflare Workers e outras plataformas sem servidor quando se trata de desempenho, então decidimos que era hora de uma atualização. Embora a maior parte do nosso trabalho na plataforma Workers nos últimos anos tenha sido tornar a plataforma mais poderosa: introduzindo novos recursos, APIs, armazenamento, depuração e ferramentas de observabilidade, o desempenho não foi negligenciado.
Hoje, o Workers está 30% mais rápido do que há três anos no P90. Também está 210% mais rápido que o Lambda@Edge e 298% mais rápido que o Lambda.
E também eliminamos partidas a frio.
Como você mede o desempenho de plataformas sem servidor?
No passado, executei centenas de benchmarks de desempenho entre CDNs e a fórmula é simples: usamos uma ferramenta chamada Catchpoint, que faz solicitações de nós de todo o mundo para o mesmo ativo e envia relatórios sobre o tempo que levou para cada um retornar uma resposta.
Medir o desempenho sem servidor é um pouco diferente. Como o que você está comparando é o desempenho de computação, em vez de um ativo estático, queríamos garantir que todas as funções executassem a mesma operação.
Em nosso blog de 2018 sobre testes de velocidade, fizemos com que cada função simplesmente retornasse ao horário atual. Para os fins deste teste, os produtos "sem servidor" que não conseguiram atender aos critérios mínimos para realizar essa tarefa foram desqualificados. Os produtos sem servidor usados nesta rodada de testes executaram a mesma função, com complexidade computacional idêntica, para garantir resultados precisos e justos.
Também é importante observar o que estamos medindo. O motivo pelo qual o desempenho é importante é que ele afeta a experiência dos clientes finais reais. Não importa qual seja a origem da latência: DNS, congestionamento de rede, inicializações a frio... o cliente não se importa com a origem, mas sim em perder tempo esperando que seu aplicativo seja carregado.
Portanto, é importante medir o desempenho em termos da experiência do usuário final, de ponta a ponta, e é por isso que usamos referências globais para medir o desempenho.
O resultado abaixo mostra os testes executados em 50 nós em todo o mundo, na América do Norte, América do Sul, Europa, Ásia e Oceania.
Azul: Cloudflare Workers Vermelho: Lambda@Edge Verde: Lambda
Como você pode ver pelos resultados, não importa onde os usuários estejam no mundo, quando se trata de velocidade, o Workers pode garantir a melhor experiência para os clientes.
No caso do Workers, obter o melhor desempenho em todo o mundo não requer nenhum esforço adicional por parte dos desenvolvedores. Os desenvolvedores não precisam fazer nenhum balanceamento de carga adicional ou configuração de regiões. Cada implantação é ativada instantaneamente na extensa rede de borda da Cloudflare.
Mesmo que você não esteja tentando se dirigir a um público global e sua base de clientes esteja convenientemente localizada na costa leste dos Estados Unidos, o Workers é capaz de garantir a resposta mais rápida a todas as solicitações.
Acima, temos os resultados de Washington, DC, o mais próximo possível de us-east-1. E, novamente, sem nenhuma otimização, o Workers é 34% mais rápido.
Por quê?
O que define o desempenho de uma plataforma sem servidor?
Além do desempenho do próprio código, do ponto de vista do usuário final, o desempenho de um aplicativo sem servidor é fundamentalmente uma função de duas variáveis: a distância que um aplicativo é executado do usuário e o tempo que o próprio tempo de execução leva para processar. A percepção de que a distância do usuário está se tornando um gargalo cada vez maior para o desempenho dos aplicativos está fazendo com que muitos fornecedores de sem servidor se aprofundem cada vez mais na borda. A execução de aplicativos na borda, mais perto do usuário final, aumenta o desempenho. À medida que o 5G fica on-line, essa tendência só continuará a acelerar.
No entanto, muitos fornecedores de nuvem no espaço sem servidor se deparam com um problema crítico ao abordar a questão quando competem por um desempenho mais rápido. E isso é: a arquitetura legada que eles estão usando para construir suas ofertas não funciona bem com as limitações inerentes da borda.
Como o objetivo por trás do modelo sem servidor é abstrair intencionalmente a arquitetura subjacente, nem todos entendem com clareza como provedores de nuvem legados, como o AWS, criaram ofertas sem servidor como o Lambda. Os provedores de nuvem legados oferecem ofertas sem servidor, criando um processo conteinerizado para seu código. O provedor escala automaticamente todos os diferentes processos em segundo plano. Toda vez que um contêiner é ativado, todo o tempo de execução da linguagem é ativado com ele, não apenas o seu código.
Para ajudar a abordar o primeiro gráfico, que mede o desempenho global, os fornecedores estão tentando se afastar de sua arquitetura grande e centralizada (alguns data centers grandes) para um mundo distribuído na borda (um número maior de data centers menores em todo o mundo mundo) para diminuir a distância entre aplicativos e usuários finais. Mas há um problema com sua abordagem: data centers menores significam menos máquinas e menos memória. Cada vez que os fornecedores buscam uma estratégia de pequenos, mas muitos data centers, para operar mais perto da borda, a probabilidade de ocorrer uma inicialização a frio em qualquer processo individual aumenta.
Isto cria efetivamente um teto de desempenho para aplicativos sem servidor em arquiteturas baseadas em contêineres. Se os fornecedores legados com pequenos data centers moverem seu aplicativo para mais perto da borda (e dos usuários), haverá menos servidores, menos memória e é mais provável que um aplicativo precise de uma inicialização a frio. Para reduzir a probabilidade disso, eles voltaram a usar um modelo mais centralizado, mas isso significa executar seus aplicativos em um dos poucos grandes data centers centralizados. Esses data centers centralizados maiores, por definição, quase sempre estarão mais distantes de seus usuários.
Você pode ver isso em ação no gráfico acima, observando os resultados dos testes executados no Lambda@Edge. Apesar da proximidade reduzida com o usuário final, o desempenho do p90 é mais lento do que o do Lambda, pois os contêineres precisam acelerar com mais frequência.
Arquiteturas sem servidor construídas em contêineres podem se mover para cima e para baixo na fronteira, mas, em última análise, não há muito que possam fazer para mudar essa curva da fronteira.
O que torna o Workers tão rápido?
O Workers foi projetado desde o início para ser um modelo sem servidor que prioriza a borda. Como a Cloudflare começou com uma rede de borda distribuída, em vez de tentar forçar a computação de grandes data centers centralizados para a borda, trabalhar com essas restrições nos forçou a inovar.
Em um de nossos posts anteriores no blog, discutimos como essa inovação se traduziu em uma nova mudança de paradigma com a arquitetura do Workers sendo construída em isolados V8 leves que podem ser ativados rapidamente, sem introduzir uma inicialização a frio em todas as solicitações.
A execução de isolados não apenas nos deu uma vantagem pronta para uso, mas à medida que o V8 fica melhor, nossa plataforma também melhora. Por exemplo, quando o V8 anunciou o Liftoff, um compilador para WASM, todos os WASM do Workers ficaram mais rápidos instantaneamente.
Da mesma forma, sempre que são feitas melhorias na rede da Cloudflare (por exemplo, quando adicionamos novos data centers) ou na pilha (por exemplo, compatibilidade com novos protocolos mais rápidos como HTTP/3), o Workers se beneficia instantaneamente.
Além disso, estamos sempre buscando melhorias no próprio Workers para tornar a plataforma ainda mais rápida. Por exemplo, no ano passado, lançamos uma melhoria que ajudou a eliminar partidas a frio para nossos clientes.
Uma grande vantagem que ajuda o Workers a identificar e abordar as lacunas de desempenho é a escala na qual ele opera. Hoje, o Workers atende centenas de milhares de desenvolvedores, de amadores a empresas em todo o mundo, atendendo a milhões de solicitações por segundo. Sempre que fazemos melhorias para um único cliente, toda a plataforma fica mais rápida.
Desempenho que importa
O objetivo final do modelo sem servidor é permitir que os desenvolvedores se concentrem no que fazem de melhor: criar experiências para seus usuários. Escolher uma plataforma sem servidor que possa oferecer o melhor desempenho pronta para uso significa uma coisa a menos com que os desenvolvedores precisam se preocupar. Se você gasta seu tempo otimizando para inicializações a frio, não está gastando seu tempo criando o melhor recurso para seus clientes.
Assim como os desenvolvedores desejam criar a melhor experiência para seus usuários melhorando o desempenho de seus aplicativos, também estamos constantemente nos esforçando para melhorar a experiência dos desenvolvedores que criam no Workers .
Da mesma forma que os clientes não querem esperar por respostas lentas, os desenvolvedores não querem esperar por ciclos de implantação lentos.
É aqui que a plataforma Workers se destaca mais uma vez.
Qualquer implantação no Cloudflare Workers leva menos de um segundo para se propagar globalmente, então você não quer perder tempo esperando a implantação do seu código e os usuários podem ver as alterações o mais rápido possível.
Claro, não é apenas o tempo de implantação em si que é importante, mas a eficiência do ciclo completo de desenvolvimento, e é por isso que estamos sempre buscando aprimorá-lo em cada etapa: desde a inscrição até a depuração.
Não acredite apenas na nossa palavra.
Nem é preciso dizer que, por mais que tentemos permanecer neutros, sempre seremos um pouco tendenciosos. Felizmente, você não precisa acreditar no que dizemos.
Convidamos você a se inscrever e implantar seu primeiro Worker hoje mesmo, só alguns minutos!