A computação sem servidor oferece uma série de benefícios aos desenvolvedores web, incluindo escalabilidade, tempo de colocação no mercado mais rápido e despesas menores. No entanto, em alguns casos, esses benefícios podem ser superados por outras preocupações.
Após ler este artigo, você será capaz de:
Conteúdo relacionado
O que é computação sem servidor?
Sem servidor x containers
Sem servidor e Javascript
Computação de borda
Função como serviço (FaaS)
Assine o theNET, uma recapitulação mensal feita pela Cloudflare dos insights mais populares da internet.
Copiar o link do artigo
A computação sem servidor oferece uma série de vantagens sobre a infraestrutura tradicional baseada em nuvem ou centrada em servidores. Para muitos desenvolvedores, as arquiteturas sem servidor oferecem maior escalabilidade, maior flexibilidade e tempo de lançamento mais rápido, tudo isso a um custo reduzido. Com as arquiteturas sem servidor, os desenvolvedores não precisam se preocupar em comprar, provisionar e gerenciar servidores de back-end. Entretanto, a computação sem servidor não é uma solução mágica para todos os desenvolvedores de aplicativos web.
A computação sem servidor é uma arquitetura em que um fornecedor oferece serviços de back-end conforme necessário. Para saber mais sobre computação sem servidor, veja O que é computação sem servidor?
Embora a computação "sem servidor" ocorra de fato nos servidores, os desenvolvedores nunca precisam lidar com os servidores. Eles são gerenciados pelo fornecedor. Isso pode reduzir o investimento necessário em DevOps, o que diminui as despesas e também libera os desenvolvedores para criar e expandir seus aplicativos sem serem limitados pela capacidade do servidor.
Da mesma forma que em um plano de telefone pré-pago, os desenvolvedores são cobrados apenas pelo que utilizam. O código só é executado quando as funções de back-end são necessárias para o aplicativo sem servidor, e o código é automaticamente expandido conforme a necessidade. O provisionamento é dinâmico, preciso e em tempo real. Alguns serviços são tão precisos que suas cargas são divididas em incrementos de 100 milissegundos. Em comparação, em uma arquitetura tradicional totalmente baseada em servidor, os desenvolvedores precisam projetar antecipadamente quanta capacidade de servidor eles precisarão e depois adquirir essa capacidade, quer a utilizem ou não.
Imagine se os correios pudessem, como em um passe de mágica, aumentar e reduzir o número de caminhões de entrega à vontade, aumentando o tamanho de sua frota quando a quantidade de correspondência aumentasse (digamos, um pouco antes do Dia das Mães) e diminuindo sua frota nos momentos em que fosse necessário fazer menos entregas. Isso é basicamente o que os aplicativos sem servidor conseguem fazer.
Os aplicativos construídos com uma infraestrutura sem servidor serão dimensionados automaticamente conforme a base de usuários ou o uso aumentam. Se uma função precisar ser executada em várias instâncias, os servidores do fornecedor irão inicializá-las, executá-las e encerrá-las conforme necessário, geralmente usando containers. (A função será inicializada mais rapidamente se houver sido executada recentemente. Consulte "O desempenho pode ser afetado" abaixo.) Como resultado, um aplicativo sem servidor será capaz de lidar com um número excepcionalmente alto de solicitações tão bem quanto ao processar uma única solicitação de um único usuário. Um aplicativo estruturado tradicionalmente com uma quantidade fixa de espaço no servidor pode ficar sobrecarregado com um aumento repentino do uso.
Ao usar uma infraestrutura sem servidor, não há necessidade de carregar o código para os servidores ou de fazer qualquer configuração de back-end para liberar uma versão de um aplicativo que funcione. Os desenvolvedores podem muito rapidamente fazer o upload de bits de código e lançar um novo produto. Eles podem carregar o código de uma só vez ou uma função por vez, já que o aplicativo não é uma pilha monolítica única, mas sim um conjunto de funções fornecidas pelo fornecedor.
Isso também torna possível atualizar, corrigir, consertar ou adicionar rapidamente novos recursos a um aplicativo. Não é necessário fazer alterações em todo o aplicativo; em vez disso, os desenvolvedores podem atualizar o aplicativo usando uma função por vez.
Como o aplicativo não está hospedado em um servidor de origem, seu código pode ser executado em qualquer lugar. Portanto, é possível, dependendo do fornecedor utilizado, executar funções do aplicativo em servidores que estejam próximos ao usuário final. Isso reduz a latência porque as solicitações do usuário não precisam mais viajar até um servidor de origem. O Cloudflare Workers possibilita esse tipo de redução de latência sem servidor.
É difícil replicar o ambiente sem servidor a fim de ver como o código irá realmente funcionar depois de implementado. A depuração é mais complicada porque os desenvolvedores não têm visibilidade dos processos de back-end e porque o aplicativo é dividido em funções separadas e menores. O Cloudflare Workers Playground é uma sandbox que ajuda a reduzir o atrito nos testes e na depuração.
Quando os fornecedores executam todo o back-end, pode não ser possível verificar completamente sua segurança, o que pode ser um problema, especialmente para aplicativos que lidam com dados pessoais ou sensíveis.
Como as empresas não têm seus próprios servidores físicos distintos, os provedores sem servidor frequentemente executarão códigos de vários de seus clientes em um único servidor a qualquer momento. Essa questão de compartilhar máquinas com outras partes é conhecida como "multilocação" (pense em várias empresas tentando alugar e trabalhar em um único escritório ao mesmo tempo). A multilocação pode afetar o desempenho do aplicativo e, se os servidores multi-inquilinos não forem configurados corretamente, isso pode acarretar a exposição dos dados. A multilocação tem pouco ou nenhum impacto para as redes em que a sandbox funciona corretamente e tem uma infraestrutura poderosa o suficiente. Por exemplo, o Cloudflare executa uma rede de 15 Tbps com excesso de capacidade suficiente para mitigar a degradação do serviço, e todas as funções sem servidor hospedadas pela Cloudflare são executadas em sua própria sandbox (pelo motor V8 do Chrome).
Isso limita os tipos de aplicativos que podem funcionar de forma econômica em uma arquitetura sem servidor. Como os provedores sem servidor cobram pelo tempo de execução do código, pode custar mais caro executar um aplicativo com processos de longa duração em uma infraestrutura sem servidor do que em uma infraestrutura tradicional.
Como não está sendo executado constantemente, o código sem servidor pode precisar ser "inicializado" quando for utilizado. Esse tempo de inicialização pode degradar o desempenho. Entretanto, se parte do código for usado regularmente, o provedor sem servidor o manterá pronto para ser ativado: uma solicitação para esse código pronto para uso é chamada de "inicialização a quente". Uma solicitação de código que não é usado há algum tempo é chamada de "inicialização a frio".
O Cloudflare Workers evita amplamente o problema de inicialização a frio usando o motor V8 do Chrome, que na maioria dos casos é capaz de inicializar e executar o código JavaScript em menos de 5 milissegundos. Se o código já estiver em execução, o tempo de resposta será inferior a um milissegundo. Saiba mais sobre o desempenho de diferentes plataformas sem servidor.
Permitir que um fornecedor forneça todos os serviços de back-end para um aplicativo inevitavelmente aumenta a confiança nesse fornecedor. Configurar uma arquitetura sem servidor com um fornecedor pode dificultar a troca de fornecedores, se necessário, especialmente porque cada fornecedor oferece recursos e fluxos de trabalho ligeiramente diferentes. (Os Workers da Cloudflare são mais fáceis de migrar porque são escritos em JavaScript e escritos na service workers API amplamente utilizada).
Os desenvolvedores que desejam diminuir o tempo de colocação no mercado e construir aplicativos leves e flexíveis que possam ser expandidos ou atualizados rapidamente podem se beneficiar muito da computação sem servidor.
Arquiteturas sem servidor reduzirão os custos para aplicativos com uso inconsistente, com períodos de pico que se alternam com períodos de pouco ou nenhum tráfego. Para esses aplicativos, comprar um servidor ou um bloco de servidores que funcionam constantemente e estão sempre disponíveis, mesmo quando não são utilizados, pode ser um desperdício de recursos. Uma configuração sem servidor responderá instantaneamente quando necessário e não incorrerá em custos quando não estiver em uso.
Além disso, os desenvolvedores que desejam enviar algumas ou todas as funções de seus aplicativos para que fiquem próximas dos usuários finais a fim de reduzir a latência exigirão pelo menos uma arquitetura parcialmente sem servidor, pois para fazer isso é necessário mover alguns processos para fora do servidor de origem.
Há casos em que faz mais sentido, tanto do ponto de vista de custo quanto do ponto de vista da arquitetura do sistema, usar servidores dedicados autogerenciados ou oferecidos como serviço. Por exemplo, grandes aplicativos com uma carga de trabalho razoavelmente constante e previsível podem exigir uma configuração tradicional e, nesses casos, a configuração tradicional provavelmente é mais barata.
Além disso, pode ser proibitivamente difícil migrar aplicativos legados para uma nova infraestrutura com uma arquitetura completamente diferente.
O Cloudflare Workers é um produto que permite aos desenvolvedores escrever funções em JavaScript e implantá-las na borda de rede da Cloudflare. Isso torna possível executar o código do aplicativo em uma arquitetura sem servidor o mais próximo possível do usuário final, minimizando a latência.