O que é a 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, backends de IoT, processamento de dados em lote e stream, bots de bate-papo e muito mais.


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

Cloud Functions

Funções e eventos sem servidor

Cloud Functions

Uma 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 Web e back-ends 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 que podem ser invocados por solicitações HTTP. O Cloud Run está disponível como uma plataforma totalmente gerenciada em que o usuário paga apenas pelo que usa. Esse recurso também pode ser utilizado como complemento do GKE.

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 backends 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 o Python 2.7 e o 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 segmentar 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 que agrupa APIs e serviços.

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 no GKE, você executa facilmente as cargas de trabalho sem servidor e com monitoramento de estado. Por exemplo, é possível implantar o MongoDB do Marketplace no seu cluster GKE para usar como repositório de documentos para as cargas de trabalho sem servidor. O GKE oferece a flexibilidade de executar qualquer processo no seu cluster, e você consegue usar o Cloud Run para implantar também cargas de trabalho sem servidor.

Comparação de produtos

Ambiente padrão do App Engine Cloud Functions Cloud Run (Beta)1 Cloud Run no GKE (Beta)1
Artefato de implantação App Função Contêiner Contêiner
Escalonamento para zero Verificação Verificação Verificação Pods2
Nível gratuito Verificação Verificação Verificação
WebSockets 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, Users API 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 Verificação
Domínio personalizado Verificação Verificação Verificação
Tempo limite da solicitação 1 minuto3 9 minutos 15 minutos 15 minutos
GPUs e TPUs Verificação
Conectividade VPC VerificaçãoBeta1 Previsto 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 escalonado para 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.

Se a arquitetura incluir componentes sem ajuste automático de escala ou sem servidor, aqueles com escalonamento automática poderão gerar uma sobrecarga. Use um tópico Cloud Pub/Sub e defina a propriedade "max_instances" no Cloud Functions para enfileirar chamadas para componentes sem escalonamento automático.
Muitos produtos do GCP oferecem um nível gratuito que abrange grande parte do uso de recursos para aplicativos leves de baixo tráfego. Use o Cloud Functions para configurar facilmente os limites de faturamento.
Veja mais informações neste tutorial.
O Cloud Functions foi projetado para lidar apenas com uma solicitação por instância, garantindo que toda a capacidade de computação e memória seja alocada à solicitação. Essa ação pode deixar o escalonamento rápido com o Cloud Functions mais lento. Já o ambiente padrão do Google App Engine, o Cloud Run e o Cloud Run no GKE podem lidar com várias solicitações simultâneas por instância. Isso significa que esses serviços podem ser escalonados mais rapidamente ao lidar com mais tráfego por instância, mas todas as solicitações em uma instância precisam compartilhar recursos.
O Cloud Run é compatível com a API de código aberto e o ambiente de execução Knative. Dessa maneira, é possível mover cargas de trabalho sem servidor no Cloud Run, Cloud Run no GKE ou no seu próprio cluster Kubernetes. Você consegue até mesmo começar a executar as cargas de trabalho no Cloud Run e passar a usar o Cloud Run no GKE se precisar de recursos específicos do GKE, como tipos de máquinas personalizados ou acesso a VPC.