O que é computação sem servidor?

A computação sem servidor representa uma mudança de paradigma no desenvolvimento de aplicativos. Com ela, os desenvolvedores se concentram apenas em escrever código sem precisar se preocupar com a infraestrutura. Essa opção também oferece muitas vantagens em relação à computação tradicional, incluindo o escalonamento automático e o pagamento apenas pelos recursos utilizados, além de não precisar de nenhum gerenciamento de servidores nem de provisionamento antecipado. Essas vantagens tornam a computação sem servidor ideal para casos de uso como aplicativos HTTP sem estado, Web, dispositivos móveis, back-ends de IoT, processamento de dados em lote e stream, bots de chat e muito mais.


Portfólio de computação sem servidor do GCP

Cloud Functions

Funções e eventos sem servidor

Cloud Functions

Uma plataforma de computação orientada a eventos para conectar e estender facilmente serviços em nuvem do Google e de terceiros, além de criar aplicativos que variam de zero a escalas planetárias.

Saiba mais  
Ambiente padrão do App Engine

Aplicativos HTTP sem servidor

Ambiente padrão do App Engine

Uma plataforma de aplicativos sem servidor totalmente gerenciada para back-ends Web e de API. Use as linguagens de desenvolvimento mais conhecidas sem se preocupar com o gerenciamento da infraestrutura.

Saiba mais  
Cloud Run

Contêineres sem servidor

Cloud Run

Uma plataforma de computação sem servidor que permite executar contêineres sem estado, invocáveis por meio de solicitações HTTP. O Cloud Run está disponível como uma plataforma totalmente gerenciada em que o usuário paga apenas pelo que usa. Também está disponível como parte do Anthos.

Saiba mais  

Qual plataforma de computação sem servidor é ideal para você?

Opções sem servidor

* O ambiente padrão do App Engine é compatível com Node.js, Python, Java, Go e PHP.

* O Cloud Functions é compatível com Node.js, Python e Go.

Casos de uso

Aplicativo da Web

Aplicativos da Web

O ambiente padrão do Google App Engine é ideal para aplicativos da Web com poucas operações em Node.js, Python, PHP, Java e Go. Escreva seus aplicativos de maneira padrão e idiomática usando qualquer biblioteca de linguagem. A implantação rápida e a capacidade de resposta de escalonamento fazem com que o ambiente padrão do Google App Engine seja ideal para cargas de trabalho com muitos picos.

Processamento de back-end assíncrono

Processamento de back-end assíncrono

O Cloud Functions responde a eventos de dados na nuvem e realiza processamento básico, como o redimensionamento de imagens enviadas para o Cloud Storage ou a validação de dados quando valores são modificados no banco de dados do Firestore.

Back-ends para dispositivos móveis

Back-ends para dispositivos móveis

Para back-ends tradicionais de API REST para aplicativos móveis, o ambiente padrão do App Engine é uma plataforma de aplicativos que monitora, atualiza e escalona o ambiente de hospedagem. Tudo o que você precisa fazer é escrever o código do serviço de back-end para dispositivos móveis. O Firebase oferece um conjunto de serviços avançados de back-end que se integram diretamente ao seu app para dispositivos móveis: bancos de dados NoSQL em tempo real, autenticação, hospedagem, armazenamento de arquivos e muito mais. O Firebase integra-se ao Cloud Functions para que você se conecte com facilidade aos demais serviços do Google Cloud Platform.

APIs

APIs

Se você estiver criando uma API simples (um pequeno conjunto de funções para acesso via HTTP ou Cloud Pub/Sub), recomendamos usar o Cloud Functions. Ele foi criado para cargas de trabalho intermitentes, e o paradigma de programação (funções) ajuda a manter organizado o código de back-end em pequena escala. No caso de APIs mais complexas (como uma API REST com várias rotas), recomendamos o uso do ambiente padrão do App Engine, já que é mais fácil organizar várias funções nele. Se você depende do Cloud Endpoints para gerenciar APIs, recomendamos usar o ambiente padrão do App Engine com Python 2.7 e Java 8, já que ele oferece suporte ao Cloud Endpoints.

Operações periódicas

Operações periódicas

O Cloud Scheduler pode enviar solicitações HTTP programadas para disparar operações de acordo com um cronograma. Ele também pode visar especificamente o App Engine ou endpoints HTTP, como o Cloud Functions e o Cloud Run.

Prototipagem rápida e agrupamento de APIs

Prototipagem rápida e agrupamento de APIs

Em projetos de pequena escala ou “hackathon” que envolvem prototipagem rápida e/ou o agrupamento de várias APIs e serviços, recomendamos o uso do Cloud Functions. O paradigma de programação dele permite o rápido desenvolvimento de aplicativos de pequena escala e/ou "código de cola" que agrupa APIs e serviços existentes.

Como executar contêineres que não dependem do provedor

Como executar contêineres que não dependem do provedor

Os contêineres do Docker são padrão do setor e podem ser executados em qualquer nuvem ou no local. O Cloud Run pode executar contêineres no formato solicitação-resposta sem servidor. Recomendamos o uso do Cloud Run, a menos que você precise de hardware personalizado, como GPUs, ou de um cluster Kubernetes. Nesses casos, é possível executar o Cloud Run no GKE no seu cluster do Google Kubernetes Engine.

Combine cargas de trabalho sem servidor e com estado

Combine cargas de trabalho sem servidor e com estado

Com o Cloud Run for Anthos, você executa facilmente as cargas de trabalho sem servidor e com estado. É possível, por exemplo, implantar o MongoDB do Marketplace no cluster do Anthos GKE para usar como repositório de documentos para as cargas de trabalho sem servidor. O Anthos garante a flexibilidade para executar o que for necessário no cluster do Kubernetes, e você pode usar o Cloud Run for Anthos para implantar cargas de trabalho sem servidor paralelamente.

Comparação de produtos

Ambiente padrão do App Engine Cloud Functions Cloud Run Cloud Run for Anthos
Artefato de implantação App Função Contêiner Contêiner
Redução a zero Marca de verificação Marca de verificação Marca de verificação Pods2
Nível gratuito Marca de verificação Marca de verificação Marca de verificação
WebSockets Marca de verificação
Linguagens Java, Node.js, Python, Go, PHP Node.js, Python, Go Todas Todas
Controles de acesso Oauth 2.0, CICP, Firebase Authentication, Login do Google, API Users Permissões do IAM do chamador Permissões do IAM do chamador, CICP, Login do Google, Firebase Authentication Apenas cluster, apenas VPC
HTTP/2 e gRPC Marca de verificação
Domínio personalizado Marca de verificação Marca de verificação Marca de verificação
Tempo limite da solicitação 1 minuto3 9 minutos 15 minutos 15 minutos
GPUs e TPUs Marca de verificação
Conectividade VPC Marca de verificação Marca de verificaçãoBeta1 Prevista Marca de verificação

1. A versão Beta do software não tem SLA.

2. O Cloud Run no GKE ajusta o número de pods para zero. O número de nós por cluster não pode ser reduzido a zero, e esses nós são cobrados na ausência de solicitações.

3. Escalonamento automático: prazo de 60 segundos para solicitações HTTP.

Dicas avançadas e práticas recomendadas

Veja alguns outros fatores a considerar.