O Que É o Alojamento Serverless

O que é a computação serverless

A computação serverless é um modelo de computação na cloud em que o fornecedor gere automaticamente a infraestrutura de servidores, enquanto você se concentra exclusivamente no código. Apesar do nome, os servidores continuam a existir, mas não tem de os configurar, manter, atualizar ou escalar. O fornecedor trata de tudo isso, enquanto você escreve funções que são executadas em resposta a eventos. Paga apenas pelo tempo de execução do código, e não por um servidor à espera de pedidos.

O conceito de serverless evoluiu a partir da computação na cloud. Dos servidores físicos passámos para as máquinas virtuais, depois para os contentores e, finalmente, para as funções serverless. Cada passo abstraiu mais infraestrutura aos programadores, permitindo-lhes concentrar-se na lógica de negócio. O AWS Lambda, lançado em 2014, foi o primeiro serviço serverless comercial e desencadeou uma revolução na forma como pensamos sobre o alojamento.

Como funciona o serverless

Functions as a Service (FaaS)

O FaaS é o coração da arquitetura serverless. Você escreve uma função que executa uma tarefa específica, por exemplo, processar uma imagem, enviar um email ou criar um PDF. Essa função é empacotada e carregada para a plataforma serverless. Quando ocorre um evento que despoleta a sua função, como um pedido HTTP, o carregamento de um ficheiro ou uma mensagem numa fila, a plataforma inicia automaticamente uma instância da sua função, executa-a e devolve o resultado. Após a execução, a instância é encerrada. Se chegarem 1.000 pedidos em simultâneo, a plataforma inicia 1.000 instâncias em paralelo.

Backend as a Service (BaaS)

O componente BaaS do serverless oferece serviços de backend prontos a usar, como base de dados, autenticação, armazenamento de ficheiros e notificações push, sob a forma de serviços geridos. O Firebase, da Google, é o BaaS mais popular, oferecendo base de dados em tempo real, autenticação, armazenamento na cloud e alojamento num único pacote. O AWS Amplify combina funções Lambda com a base de dados DynamoDB, a autenticação Cognito e o armazenamento S3. O Supabase é uma alternativa de código aberto ao Firebase, com uma base de dados PostgreSQL. O BaaS elimina a necessidade de escrever código de backend padrão para operações comuns.

Arquitetura orientada a eventos

As aplicações serverless são intrinsecamente orientadas a eventos, o que significa que o código é executado apenas quando ocorre um evento específico. Os eventos podem ser pedidos HTTP de utilizadores, alterações na base de dados, o carregamento de um ficheiro para o armazenamento, um horário agendado como uma tarefa cron, uma mensagem numa fila de mensagens ou dados de sensores IoT. Esta arquitetura é naturalmente eficiente, porque os recursos são consumidos apenas quando há trabalho a fazer. No modelo tradicional, o servidor está sempre em funcionamento e consome recursos mesmo quando não há tráfego.

Vantagens do serverless

Escalabilidade automática

As plataformas serverless escalam automaticamente o seu código de zero a milhões de pedidos sem qualquer configuração. Não é necessário definir regras de auto-scaling, definir o número mínimo e máximo de instâncias ou preocupar-se com um balanceador de carga. Se o seu site tiver 10 visitantes à meia-noite e 10.000 durante o pico da tarde, o serverless adapta-se automaticamente. Isto é especialmente útil para aplicações com tráfego imprevisível, como sites de e-commerce durante saldos ou campanhas virais nas redes sociais.

Pagamento por utilização

O alojamento tradicional cobra um preço mensal fixo, independentemente de o servidor estar a funcionar a 1 ou a 100 por cento da capacidade. O serverless cobra apenas pelo tempo de execução do código, normalmente em milissegundos, mais o número de invocações da função. O AWS Lambda, por exemplo, oferece um milhão de invocações gratuitas por mês e 400.000 GB-segundos de tempo de computação gratuito. Para um site pequeno com 50.000 pedidos por mês, o alojamento serverless pode ser praticamente gratuito. Isto é ideal para startups e projetos em fase inicial, onde o orçamento tem de ser cuidadosamente controlado.

Manutenção zero

Não tem de se preocupar com a atualização do sistema operativo, a instalação de patches de segurança, a configuração do servidor web, a gestão de certificados SSL ou a monitorização do hardware. O fornecedor trata de toda a infraestrutura, incluindo a segurança, a redundância e as cópias de segurança. Isto liberta o tempo da sua equipa para o trabalho no produto, em vez da infraestrutura. Para uma equipa pequena ou um programador a solo, isto é uma enorme vantagem, porque elimina a necessidade de conhecimentos de DevOps.

Desvantagens do serverless

O problema do arranque a frio

Quando uma função serverless não é utilizada durante algum tempo, a plataforma encerra a sua instância para poupar recursos. O pedido seguinte tem de iniciar uma nova instância, o que introduz uma latência adicional conhecida como arranque a frio (cold start). Um arranque a frio pode demorar desde 100 milissegundos, para funções Node.js, até vários segundos, para funções Java ou C#. Para aplicações que exigem tempos de resposta consistentemente baixos, o arranque a frio é um problema significativo. As soluções incluem a concorrência provisionada, que mantém as instâncias quentes, mas isso elimina a vantagem do pagamento por utilização.

Dependência do fornecedor (vendor lock-in)

Cada fornecedor de cloud tem o seu próprio ecossistema serverless, com APIs, ferramentas e serviços específicos. Uma aplicação escrita para o AWS Lambda usa o API Gateway, o DynamoDB e o S3, que não têm equivalentes diretos no Google Cloud ou no Azure. A migração para outro fornecedor exige uma reescrita significativa do código. Frameworks como o Serverless Framework ou o Terraform tentam abstrair as diferenças entre fornecedores, mas a portabilidade total é irrealista, porque existem diferenças fundamentais nos serviços e nas APIs.

Limitações de execução

As funções serverless têm limites quanto à duração da execução, à memória e ao tamanho do pacote. O AWS Lambda tem uma duração máxima de 15 minutos por execução, 10 GB de memória e 250 MB para o pacote de implementação. Isto significa que as operações de longa duração, como o processamento de grandes ficheiros de vídeo, o machine learning complexo ou o processamento de dados em lote, não são adequadas para o serverless. A depuração e a monitorização são mais complexas, porque não tem acesso ao servidor — utiliza ferramentas nativas da cloud, como o CloudWatch ou o X-Ray.

Quando utilizar o serverless

Casos de uso ideais

• Backend de API: as APIs REST ou GraphQL com tráfego imprevisível são candidatas perfeitas, porque escalam automaticamente e não custam nada quando não há pedidos.
• Processamento de eventos: processar eventos como o carregamento de imagens, o envio de emails, a geração de relatórios ou o processamento de webhooks.
• Tarefas agendadas: tarefas cron que são executadas periodicamente, como a limpeza da base de dados, a geração de relatórios diários ou a sincronização de dados.
• Chatbots: responder a pedidos de utilizadores em que o tráfego é imprevisível e esporádico.
• Backend de IoT: processar dados de sensores em que o número de dispositivos pode variar de 10 a 10.000.

Quando evitar o serverless

O serverless não é ideal para aplicações com tráfego consistentemente elevado, porque um servidor fixo torna-se mais económico sob carga constante. As aplicações que exigem processos de longa duração, como a renderização de vídeo, as ligações websocket ou o streaming, não cabem dentro dos limites das funções serverless. As aplicações com requisitos específicos de SO, hardware ou software não disponíveis na plataforma serverless exigem alojamento tradicional. As aplicações legadas que utilizam estado entre pedidos são difíceis de migrar, porque as funções serverless são, por natureza, sem estado (stateless).

Serverless vs alojamento tradicional

Comparação para um site pequeno

Para um site pequeno com 10.000 a 50.000 visitas por mês, um plano de alojamento partilhado custa 3 a 10 euros por mês e oferece custos previsíveis, simplicidade e suporte para PHP, WordPress e email. O serverless pode ser gratuito ou custar menos de 1 euro por mês para o mesmo tráfego, mas exige conhecimentos técnicos para a configuração e não suporta plataformas CMS tradicionais. Para os proprietários de sites pequenos que utilizam o WordPress, o alojamento tradicional é a escolha mais prática.

Comparação para uma aplicação grande

Para uma aplicação grande com milhões de pedidos por dia, o alojamento avançado com recursos dedicados custa 50 a 500 euros por mês, mas exige uma equipa de DevOps para a gestão. O serverless escala automaticamente sem intervenção, mas os custos podem crescer rapidamente sob carga elevada constante. Uma abordagem híbrida, em que o tráfego de base é tratado por um servidor tradicional enquanto o serverless absorve os picos, é frequentemente a solução ótima, combinando a previsibilidade de custos com a elasticidade do escalonamento. Na BeoHosting oferecemos planos de alojamento tradicional otimizados para WordPress e aplicações web, com custos previsíveis e suporte técnico completo, o que é uma solução mais prática do que a arquitetura serverless para a maioria dos utilizadores.

Conclusão

O alojamento serverless representa uma evolução da computação na cloud que elimina as preocupações com a infraestrutura e permite a concentração no código e na lógica de negócio. A escalabilidade automática, o pagamento por utilização e a manutenção zero são vantagens poderosas para os casos de uso adequados. No entanto, o problema do arranque a frio, a dependência do fornecedor e os limites de execução tornam o serverless inadequado para todos os tipos de aplicações. Compreender as vantagens e as desvantagens ajuda-o a tomar uma decisão informada sobre se o serverless ou o alojamento tradicional se adequa melhor às suas necessidades.