O que é computação sem servidor?

Quando se trata de criar aplicativos, os desenvolvedores normalmente têm uma série de outras tarefas de gerenciamento de servidor que precisam executar para implantar o código, como definir recursos para processamento e armazenamento, aplicar patches, balanceamento de carga e muito mais. Todos esses itens extras levam a tempos de provisionamento mais longos e mais sobrecarga operacional que, no fim, desacelera as equipes de desenvolvimento. 

A computação sem servidor tenta fornecer uma experiência "sem servidor" invisível para os desenvolvedores, eliminando a necessidade de pensar nos servidores ou em qualquer coisa que um aplicativo possa precisar executar. Em vez disso, o provedor de serviços faz todo o trabalho nos bastidores para garantir que você tenha os recursos para executar seu código e atender aos requisitos sem ser cobrado por capacidade ociosa. 

Pense na computação sem servidor como levar água para sua casa. Você pode cavar o próprio poço, testar a qualidade da água, instalar e manter todo o encanamento externo necessário para executá-lo na casa. Ou você pode se conectar ao principal sistema de abastecimento da sua cidade. Basta ligar a torneira de água e pegar a quantidade de água que quiser exatamente quando precisar, e a cidade enviará uma fatura mensal com a quantidade exata de água que você consome. 

Da mesma forma, os provedores de nuvem ativam automaticamente os recursos de infraestrutura e os ambientes de execução necessários para executar seus aplicativos sem servidor e reduzem automaticamente o escalonamento a zero quando a execução é concluída. Normalmente, você é cobrado com base nos recursos durante o tempo de execução. No entanto, isso pode variar de acordo com o serviço e o fornecedor. 

Mas não é o caso de outros tipos de computação em nuvem não fornecem recursos sob demanda com pagamento por utilização? É verdade que modelos de serviço na nuvem comoInfrastructure as a Service (IaaS) ePlataforma como serviço (PaaS) também oferecem acesso sob demanda a recursos de computação.

No entanto, a infraestrutura em nuvem alocada para você permanece ativa mesmo que não seja usada. Também é sua responsabilidade escalonar a capacidade do servidor ou configurar seus aplicativos para aumentar ou diminuir a escala em resposta à demanda do usuário. 

Por outro lado, as arquiteturas sem servidor são orientadas a eventos. Nesse modelo, o provedor só fornece recursos quando um evento aciona a execução do seu código e faz o escalonamento automático e instantâneo das solicitações.

Na computação em nuvem sem servidor, geralmente há dois tipos de serviços: funções como serviço (FaaS) e back-end como serviço (BaaS). 

• O FaaS fornece os recursos de computação necessários para executar a lógica do aplicativo em resposta às solicitações. Esses elementos de lógica (ou funções) são executados em contêineres totalmente gerenciados pelo provedor de serviços de nuvem. Os aplicativos sem servidor normalmente são divididos em funções únicas que realizam uma ação em resposta a um evento. 
• O BaaS oferece toda a funcionalidade de back-end de aplicativos da Web ou móveis como serviço, como serviços de autenticação, gerenciamento de banco de dados, armazenamento em nuvem, notificações push e hospedagem. O BaaS também elimina a necessidade de gerenciar servidores, contêineres ou máquinas virtuais. 

No desenvolvimento, o termo "sem servidor" é geralmente usado para descrever ofertas FaaS. No entanto, é importante observar que, tecnicamente, o FaaS é um subconjunto da tecnologia sem servidor. A computação sem servidor inclui qualquer tipo de serviço em que o gerenciamento, a configuração, o escalonamento e o faturamento do servidor são abstraídos do usuário final. Isso pode incluir bancos de dados, armazenamento, streaming de eventos, mensagens e gateways de API.

Alguns dos exemplos de computação sem servidor mais comuns e emergentes incluem:

• Caso de uso: sincronizar leads/clientes de forma integrada entre diferentes aplicativos de negócios (por exemplo, CRM para automação de marketing)
• Solução sem servidor: uma função do Cloud Run acionada por HTTP recebe webhooks do sistema de origem (por exemplo, Salesforce), transforma os dados e chama a API do sistema de destino (por exemplo, HubSpot), geralmente usando o Secret Manager para credenciais
• Produtos sem servidor do Google Cloud: Cloud Run functions e Secret Manager

• Caso de uso: automatizar a geração e distribuição de relatórios de rotina
• Solução sem servidor: um job do Cloud Scheduler aciona uma função do Cloud Run pelo Pub/Sub diariamente. A função consulta um data warehouse (por exemplo, o BigQuery), processa os dados em um relatório e envia o relatório por uma API de e-mail
• Produtos sem servidor do Google Cloud: Cloud Scheduler, Pub/Sub, Cloud Run functions e BigQuery

• Caso de uso: reduzir os custos de nuvem identificando e gerenciando automaticamente recursos de computação inativos
• Solução sem servidor: um job noturno do Cloud Scheduler aciona uma função do Cloud Run pelo Pub/Sub. Essa função usa a API Compute Engine e o Cloud Monitoring para identificar instâncias ociosas e as interrompe ou exclui automaticamente, registrando as ações no Cloud Logging
• Produtos sem servidor do Google Cloud: Cloud Scheduler, Pub/Sub, Cloud Run functions, Cloud Monitoring e Cloud Logging

• Caso de uso: processar e enriquecer dados de streaming de alto volume (por exemplo, atividade do usuário) para insights e ações imediatas
• Solução sem servidor: os eventos de clickstream do usuário são transmitidos para o Pub/Sub. Uma função do Cloud Run (ou serviço do Cloud Run) consome esses eventos, os enriquece com dados do Firestore e publica os dados enriquecidos em outro tópico do Pub/Sub para análise em tempo real no BigQuery ou recomendações personalizadas
• Produtos sem servidor do Google Cloud: Pub/Sub, Cloud Run functions, Cloud Run, Firestore e BigQuery

• Caso de uso: automatizar a criação, o teste e a implantação de microsserviços após mudanças no código
• Solução sem servidor: um gatilho do Cloud Build monitora um repositório Git (por exemplo, o Cloud Source Repositories). Após o commit do código, o Cloud Build executa testes, cria uma imagem de contêiner no Artifact Registry e implanta automaticamente a nova versão no Cloud Run
• Produtos sem servidor do Google Cloud: Cloud Build, Cloud Run, Artifact Registry e Cloud Source Repositories

• Caso de uso: gerar automaticamente variantes de imagem otimizadas (por exemplo, miniaturas, formatos diferentes) após o upload
• Solução sem servidor: uma função do Cloud Run é ativada quando uma nova imagem é enviada para um bucket do Cloud Storage. Essa função processa a imagem (redimensionamento, conversão de formato), salva as novas versões de volta no Cloud Storage e atualiza os metadados no Firestore
• Produtos sem servidor do Google Cloud: Cloud Storage, Cloud Run functions e Firestore

• Caso de uso: realizar inferências de IA em tempo real usando LLMs como Llama 3.1, Gemma 2, Mistral e outros
• Solução sem servidor: o Cloud Run se integra a modelos de IA, como a API Gemini, endpoints da Vertex AI ou modelos hospedados em um serviço do Cloud Run habilitado para GPU. Ele também pode atuar como um endpoint de API escalonável e hospedar agentes de IA
• Produtos sem servidor do GCP: Cloud Run, Cloud Storage, Firestore

Uma das maiores desvantagens da computação sem servidor é que ela ainda é uma tecnologia relativamente nova. Por isso, ele ainda não é adequado para atender a todos os casos de uso em potencial. 

Também está claro que algumas das atuais fraquezas serão resolvidas com o tempo, à medida que a computação sem servidor continua a evoluir. Muito trabalho já está sendo feito em implementações de código aberto de sem servidor e maneiras de tornar os serviços em nuvem mais abertos para tornar as soluções portáteis em diferentes plataformas e ambientes. 

• Adequação limitada do caso de uso: as arquiteturas sem servidor nem sempre são adequadas para aplicativos com requisitos específicos, como processos de longa duração ou necessidades de latência muito baixa
• Restrições de desempenho: as funções sem servidor podem ter inicializações a frio (execução inicial atrasada) e limitações no tempo de execução e na memória
• Dependência de um fornecedor: migrar aplicativos sem servidor entre provedores de nuvem pode ser complexo devido a diferenças nas APIs e configurações
• Visibilidade reduzida do servidor: os desenvolvedores têm visibilidade limitada da infraestrutura, o que dificulta a solução de problemas de desempenho ou a otimização da utilização de recursos
• Inicialização lenta: às vezes, as funções sem servidor podem passar por uma "inicialização a frio", em que há um atraso na invocação da função, o que pode afetar a latência