Este documento ajuda você a avaliar os requisitos do aplicativo e escolher entre o Cloud Run e o Autopilot do Google Kubernetes Engine (GKE), com base em considerações técnicas e organizacionais. Este documento é destinado a arquitetos de nuvem que precisam escolher um ambiente de execução de contêiner de Google Cloud alvo para as cargas de trabalho. Ele pressupõe que você já conheça o Kubernetes e o Google Cloude que tenha algum conhecimento sobre ambientes de execução sem servidor na nuvem, como o Cloud Run, as funções do Cloud Run ou a AWS Lambda.
OGoogle Cloud oferece várias opções de ambiente de execução com uma variedade de recursos. O diagrama a seguir mostra o intervalo de Google Cloud ofertas gerenciadas:
O diagrama mostra estes elementos:
A maioria dos ambientes de execução gerenciados (foco deste guia):
- Cloud Run, que inclui Funções do Cloud Run.
- Autopilot do GKE.
Essas opções são gerenciadas pelo Google, sem o gerenciamento de usuários da infraestrutura de computação subjacente.
Ambientes de execução com a menor quantidade de gerenciamento:
- GKE Standard, que é otimizado para cargas de trabalho empresariais e oferece escalonamento de cluster único de até 65.000 nós.
- Compute Engine, que inclui a família A3 de máquinas virtuais otimizada para aceleradores para cargas de trabalho de machine learning (ML) e computação de alto desempenho (HPC).
Essas opções exigem algum nível de gerenciamento de infraestrutura no nível do usuário, como as máquinas virtuais (VMs) que são a base dos recursos de computação. As VMs no GKE Standard são os nós do cluster do Kubernetes. As VMs no Compute Engine são a oferta de plataforma principal, que pode ser personalizada de acordo com seus requisitos.
Este guia ajuda você a escolher entre os ambientes de execução mais gerenciados, o Cloud Run e o Autopilot do GKE. Para uma visão mais ampla dos ambientes de execução Google Cloud , consulte o guia Google Cloud Opções de hospedagem de aplicativos.
Informações gerais dos ambientes
Esta seção oferece uma visão geral dos recursos do Cloud Run e do Autopilot do GKE. O Cloud Run e o Autopilot do GKE são bem integrados ao Google Cloud, então há muitas semelhanças entre os dois. As duas plataformas oferecem suporte a várias opções de balanceamento de carga com os serviços de balanceamento de carga altamente confiáveis e escalonáveis do Google. Eles também oferecem suporte a redes VPC, Proxy Aware Identity (IAP) e Google Cloud Armor para quando uma rede privada mais granular é um requisito. Ambas as plataformas cobram apenas pelos recursos exatos que você usa nos aplicativos.
Do ponto de vista da entrega de software, como ambientes de execução de contêineres, o Cloud Run e o GKE Autopilot têm suporte de serviços que compõem o Google Cloud ecossistema de contêineres. Esses serviços incluem o Cloud Build, o Artifact Registry, a autorização binária e a entrega contínua com o Cloud Deploy, para garantir que seus aplicativos sejam implantados de forma segura e confiável na produção. Isso significa que você e suas equipes são responsáveis pelas decisões de build e implantação.
Devido à semelhança entre as duas plataformas, é possível aproveitar os pontos fortes de cada uma delas adotando uma abordagem flexível para implantar seus aplicativos, conforme detalhado no guia Usar o GKE e o Cloud Run juntos. As seções a seguir descrevem aspectos exclusivos do Cloud Run e do Autopilot.
Cloud Run
O Cloud Run é uma plataforma de computação gerenciada sem servidor que permite executar seus aplicativos diretamente na infraestrutura escalonável do Google. O Cloud Run oferece automação e escalonamento para dois tipos principais de aplicativos:
- Serviços do Cloud Run: para código que responde a solicitações da Web.
- Jobs do Cloud Run: para código que executa uma ou mais tarefas em segundo plano e sai quando o trabalho é concluído.
Com esses dois modelos de implantação, o Cloud Run pode oferecer suporte a uma ampla gama de arquiteturas de aplicativos, além de permitir a aplicação de práticas recomendadas e permitir que os desenvolvedores se concentrem no código.
O Cloud Run também oferece suporte à implantação do código do aplicativo das seguintes origens:
- Funções leves individuais
- Aplicativos completos do código-fonte
- Aplicativos conteinerizados
O Cloud Run incorpora um recurso de build e implantação que oferece suporte a FaaS e à capacidade de criar a partir da origem, além do recurso de ambiente de execução de contêineres pré-criado. Quando você usa o Cloud Run dessa maneira, as etapas de criação e implantação da imagem do contêiner do aplicativo que será executada são totalmente automáticas e não exigem configuração personalizada.
Autopilot do GKE
O Autopilot do GKE é o modo de operação padrão e recomendado para clusters no GKE. O Autopilot permite executar aplicativos no Kubernetes sem a sobrecarga de gerenciamento de infraestrutura. Quando você usa o Autopilot, o Google gerencia os principais aspectos da configuração do cluster, incluindo provisionamento e escalonamento de nós, postura de segurança padrão e outras configurações pré-configuradas. Com o Autopilot gerenciando os recursos de nó, você paga apenas pelos recursos que são solicitados pelas cargas de trabalho. O Autopilot monitora e otimiza continuamente os recursos de infraestrutura para garantir o melhor ajuste, além de oferecer um SLA para suas cargas de trabalho.
O Autopilot do GKE oferece suporte a cargas de trabalho que podem não ser adequadas para o Cloud Run. Por exemplo, o GKE Autopilot geralmente oferece suporte a cargas de trabalho de longa duração ou com estado.
Escolher um ambiente de execução
Em geral, se as características da sua carga de trabalho forem adequadas para uma plataforma gerenciada, o ambiente de execução sem servidor do Cloud Run será o ideal. O uso do Cloud Run pode resultar em menos infraestrutura para gerenciar, menos configuração autogerenciada e, portanto, menor sobrecarga operacional. A menos que você queira ou precise especificamente do Kubernetes, recomendamos que você considere primeiro o serverless como seu ambiente de execução de destino. Embora o Kubernetes ofereça a abstração poderosa de uma plataforma aberta, o uso dele aumenta a complexidade. Se você não precisar do Kubernetes, recomendamos considerar se o aplicativo é adequado para a tecnologia sem servidor. Se houver critérios que tornem sua carga de trabalho menos adequada para a computação serverless, recomendamos o uso do Autopilot.
As seções a seguir fornecem mais detalhes sobre alguns dos critérios que podem ajudar a responder a essas perguntas, principalmente a questão de saber se a carga de trabalho é adequada para a computação serverless. Dada a semelhança entre o Autopilot e o Cloud Run, conforme descrito nas seções anteriores, a migração entre as plataformas é uma tarefa simples quando não há nenhum problema técnico ou outro obstáculo. Para saber mais sobre as opções de migração, consulte Migrar do Cloud Run para o GKE e Migrar do Kubernetes para o Cloud Run.
Ao escolher um ambiente de execução para sua carga de trabalho, é preciso considerar considerações técnicas e organizacionais. Considerações técnicas são características do aplicativo ou do Google Cloud ambiente de execução. As considerações organizacionais são características não técnicas da sua organização ou equipe que podem influenciar sua decisão.
Considerações técnicas
Algumas das considerações técnicas que vão influenciar sua escolha de plataforma são as seguintes:
- Controle e configurável: granularidade de controle do ambiente de execução.
- Gerenciamento e roteamento de tráfego de rede: capacidade de configuração de interações pela rede.
- Escalonabilidade horizontal e vertical: suporte para o crescimento dinâmico e redução da capacidade.
- Suporte a aplicativos com estado: recursos para armazenar estados persistentes.
- Arquitetura da CPU: oferece suporte a diferentes tipos de CPU.
- Deslocamento de acelerador (GPUs e TPUs): capacidade de transferir a computação para hardware dedicado.
- Alta capacidade de memória, CPU e outros recursos: nível de vários recursos consumidos.
- Dependência explícita do Kubernetes: requisitos para o uso da API Kubernetes.
- RBAC complexo para multilocação: suporte para compartilhar recursos agrupados.
- Tempo limite máximo da tarefa do contêiner: duração da execução de aplicativos ou componentes de longa duração.
As seções a seguir detalham essas considerações técnicas para ajudar você a escolher um ambiente de execução.
Controle e capacidade de configuração
Em comparação com o Cloud Run, o Autopilot do GKE oferece um controle mais granular do ambiente de execução para suas cargas de trabalho. No contexto de um pod, o Kubernetes oferece muitas primitivas configuráveis que podem ser ajustadas para atender aos requisitos do aplicativo. As opções de configuração incluem nível de privilégio, parâmetros de qualidade de serviço, gerenciadores personalizados para eventos do ciclo de vida do contêiner e compartilhamento de namespace de processo entre vários contêineres.
O Cloud Run oferece suporte direto a um subconjunto da API Pod do Kubernetes, que é descrito no YAML de referência do objeto de serviço do Cloud Run e no YAML de referência do objeto de job do Cloud Run. Esses guias de referência podem ajudar você a avaliar as duas plataformas com seus requisitos de aplicativo.
O contrato de contêiner para o ambiente de execução do Cloud Run é relativamente simples e atende à maioria das cargas de trabalho de serviço. No entanto, o contrato especifica alguns requisitos que precisam ser atendidos. Se o aplicativo ou as dependências dele não atenderem a esses requisitos ou se você precisar de um nível mais preciso de controle sobre o ambiente de execução, o Autopilot pode ser mais adequado.
Se você quiser reduzir o tempo gasto com a configuração e a administração, escolha o Cloud Run como seu ambiente de execução. O Cloud Run tem menos opções de configuração do que o Autopilot. Por isso, ele pode ajudar a maximizar a produtividade do desenvolvedor e reduzir o overhead operacional.
Gerenciamento e roteamento de tráfego de rede
O Cloud Run e o Autopilot do GKE se integram ao Cloud Load Balancing do Google Cloud. No entanto, o GKE Autopilot também oferece um conjunto rico e poderoso de primitivas para configurar o ambiente de rede para comunicações entre serviços. As opções de configuração incluem permissões granulares e segregação na camada de rede usando namespaces e políticas de rede, remapeamento de porta e descoberta de serviço DNS integrada no cluster. O GKE Autopilot também oferece suporte à API Gateway, que é altamente configurável e flexível. Essa funcionalidade oferece um controle poderoso sobre a forma como o tráfego é roteado para e entre os serviços no cluster.
Como o Autopilot é altamente configurável, ele pode ser a melhor opção se você tiver vários serviços com um alto grau de codependência de rede ou requisitos complexos sobre como o tráfego é roteado entre os componentes do aplicativo. Um exemplo desse padrão é um aplicativo distribuído que é decomposto em vários microsserviços com padrões complexos de interdependência. Nesses casos, as opções de configuração de rede do Autopilot podem ajudar a gerenciar e controlar as interações entre os serviços.
Escalonabilidade horizontal e vertical
O Cloud Run e o Autopilot do GKE oferecem suporte ao escalonamento horizontal manual e automático para serviços e jobs. O escalonamento horizontal aumenta a capacidade de processamento quando necessário e remove a capacidade de processamento adicional quando não é necessária. Para uma carga de trabalho típica, o Cloud Run geralmente pode ser escalonar horizontalmente mais rapidamente do que o Autopilot do GKE para responder a picos no número de solicitações por segundo. Por exemplo, a demonstração em vídeo "What's New in Serverless Compute?" mostra o Cloud Run escalonando de zero para mais de 10.000 instâncias em aproximadamente 10 segundos. Para aumentar a velocidade do escalonamento horizontal no Kubernetes (com um custo extra), o Autopilot permite provisionar capacidade extra de computação.
Se o aplicativo não puder ser escalonado adicionando mais instâncias para aumentar o nível de recursos disponíveis, talvez ele seja mais adequado para o Autopilot. O Autopilot oferece suporte ao escalonamento vertical para variar dinamicamente a quantidade de capacidade de processamento disponível sem aumentar o número de instâncias em execução do aplicativo.
O Cloud Run pode escalonar automaticamente seus apps para zero de réplicas enquanto eles não estão sendo usados, o que é útil para determinados casos de uso que têm foco especial na otimização de custos. Devido às características de como os aplicativos podem ser dimensionados para zero, há várias etapas de otimização que podem ser realizadas para minimizar o tempo entre a chegada de uma solicitação e o momento em que o aplicativo está em execução e pode processar a solicitação.
Suporte a aplicativos com estado
O Autopilot oferece suporte completo ao Kubernetes Volume, com suporte de discos persistentes que permitem executar uma ampla variedade de implantações com estado, incluindo bancos de dados autogerenciados. O Cloud Run e o Autopilot do GKE permitem que você se conecte a outros serviços, como o Filestore e os buckets do Cloud Storage. Eles também incluem a capacidade de montar buckets de armazenamento de objetos no sistema de arquivos com o Cloud Storage FUSE.
O Cloud Run usa um sistema de arquivos na memória, que pode não ser uma boa opção para aplicativos que exigem um sistema de arquivos local persistente. Além disso, o sistema de arquivos local na memória é compartilhado com a memória do aplicativo. Portanto, o sistema de arquivos temporário e o uso da memória do aplicativo e do contêiner contribuem para esgotar o limite de memória. É possível evitar esse problema se você usar um volume na memória dedicado com um limite de tamanho.
Um serviço ou contêiner de job do Cloud Run tem um tempo limite máximo de tarefas. Um contêiner em execução em um pod em um cluster do Autopilot pode ser reprogramado, sujeito a qualquer restrição configurada com orçamentos de interrupção de pod (PDBs, na sigla em inglês). No entanto, os pods podem ser executados por até sete dias quando são protegidos contra remoção causada por upgrades automáticos de nós ou eventos de redução de escala. Normalmente, o tempo limite da tarefa é mais provável que seja uma consideração para cargas de trabalho em lote no Cloud Run. Para cargas de trabalho de longa duração e tarefas em lote que não podem ser concluídas dentro da duração máxima da tarefa, o Autopilot pode ser a melhor opção.
Arquitetura da CPU
Todas as Google Cloud plataformas de computação oferecem suporte à arquitetura de CPU x86. O Cloud Run não oferece suporte a processadores de arquitetura Arm, mas o Autopilot oferece suporte a nós gerenciados com suporte da arquitetura Arm. Se a carga de trabalho exigir a arquitetura Arm, você precisará usar o Autopilot.
Desativação do acelerador
O Autopilot oferece suporte ao uso de GPUs e de TPUs, incluindo a capacidade de consumir recursos reservados. O Cloud Run oferece suporte ao uso de GPUs com algumas limitações.
Altos requisitos de memória, CPU e outros recursos
Em comparação com os limites de solicitação de recursos do Autopilot do GKE, os recursos de CPU e memória máximos que podem ser consumidos por um único serviço ou job do Cloud Run (uma única instância) são limitados. Dependendo das características das suas cargas de trabalho, o Cloud Run pode ter outros limites que restringem os recursos disponíveis. Por exemplo, o tempo limite de inicialização e o número máximo de conexões de saída podem ser limitados com o Cloud Run. Com o Autopilot, alguns limites podem não ser aplicados ou podem ter valores permitidos mais altos.
Dependência explícita no Kubernetes
Alguns aplicativos, bibliotecas ou frameworks podem ter uma dependência explícita no Kubernetes. A dependência do Kubernetes pode ser resultado de um dos seguintes:
- Os requisitos do aplicativo (por exemplo, o aplicativo chama APIs do Kubernetes ou usa recursos personalizados do Kubernetes).
- Os requisitos das ferramentas usadas para configurar ou implantar o aplicativo (como o Helm).
- Os requisitos de suporte de um criador ou fornecedor terceirizado.
Nesses cenários, o Autopilot é o ambiente de execução de destino porque o Cloud Run não oferece suporte ao Kubernetes.
RBAC complexo para multilocação
Se a sua organização tiver estruturas organizacionais ou requisitos de multitenência particularmente complexos, use o Autopilot para aproveitar o controle de acesso baseado em função (RBAC) do Kubernetes. Para uma opção mais simples, use os recursos de segurança e segregação integrados ao Cloud Run.
Considerações organizacionais
Confira a seguir algumas considerações organizacionais que vão influenciar sua escolha de ambiente:
- Estratégia técnica ampla: a direção técnica da sua organização.
- Como aproveitar o ecossistema do Kubernetes: interesse em aproveitar a comunidade OSS.
- Ferramentas internas atuais: uso de determinadas ferramentas.
- Perfis da equipe de desenvolvimento: conjuntos de habilidades e experiência dos desenvolvedores.
- Suporte operacional: os recursos e o foco das equipes de operações.
As seções a seguir detalham essas considerações organizacionais para ajudar você a escolher um ambiente.
Estratégia técnica ampla
Organizações ou equipes podem ter estratégias acordadas para preferir determinadas tecnologias em vez de outras. Por exemplo, se uma equipe tem um acordo para padronizar onde possível em serverless ou Kubernetes, esse acordo pode influenciar ou até determinar um ambiente de execução de destino.
Se uma determinada carga de trabalho não for adequada para o ambiente de execução especificado na estratégia, você poderá fazer uma ou mais das seguintes ações, com as ressalvas:
- Reprojetar a carga de trabalho. No entanto, se a carga de trabalho não for adequada, isso poderá resultar em desempenho, custo, segurança ou outras características não ideais.
- Registrar a carga de trabalho como uma exceção à direção estratégica. No entanto, se as exceções forem usadas em excesso, isso poderá resultar em um portfólio de tecnologias heterogêneo.
- Reconsidere a estratégia. No entanto, isso pode resultar em sobrecarga de políticas que pode impedir ou bloquear o progresso.
Como aproveitar o ecossistema do Kubernetes
Como parte da estratégia técnica ampla descrita anteriormente, as organizações ou equipes podem decidir selecionar o Kubernetes como a plataforma de escolha devido ao ecosistema significativo e em crescimento. Essa escolha é diferente de selecionar o Kubernetes devido a dependências técnicas do aplicativo, conforme descrito na seção anterior Dependência explícita no Kubernetes. A consideração de usar o ecossistema do Kubernetes enfatiza uma comunidade ativa, ferramentas de terceiros ricas e padrões e portabilidade fortes. Aproveitar o ecossistema do Kubernetes pode acelerar a velocidade de desenvolvimento e reduzir o tempo de lançamento.
Ferramentas internas
Em alguns casos, pode ser vantajoso usar os ecossistemas de ferramentas existentes na sua organização ou equipe (em qualquer um dos ambientes). Por exemplo, se você estiver usando o Kubernetes, pode optar por continuar usando ferramentas de implantação, como o ArgoCD, ferramentas de segurança e políticas, como o Gatekeeper, e o gerenciamento de pacotes, como o Helm. As ferramentas atuais podem incluir regras estabelecidas para a automação de compliance organizacional e outras funcionalidades que podem ser caras ou exigir um longo tempo de lead para implementação em um ambiente de destino alternativo.
Perfis de equipes de desenvolvimento
Uma equipe de aplicativo ou carga de trabalho pode ter experiência anterior com o Kubernetes que pode acelerar a velocidade e a capacidade da equipe de entregar no Autopilot. Pode levar algum tempo para que uma equipe se torne proficiente em um novo ambiente de execução. Dependendo do modelo operacional, isso pode reduzir a confiabilidade da plataforma durante o período de capacitação.
Para uma equipe em crescimento, a capacidade de contratação pode influenciar a escolha de plataforma de uma organização. Em alguns mercados, as habilidades em Kubernetes podem ser escassas e, portanto, exigem um prêmio de contratação. A escolha de um ambiente como o Cloud Run pode ajudar a simplificar o processo de contratação e permitir um crescimento mais rápido da equipe dentro do seu orçamento.
Suporte operacional
Ao escolher um ambiente de execução, considere a experiência e as habilidades das equipes de SRE, DevOps e plataformas e de outros funcionários operacionais. As capacidades das equipes operacionais para oferecer suporte eficaz ao ambiente de produção são cruciais do ponto de vista da confiabilidade. Também é fundamental que as equipes operacionais ofereçam suporte a ambientes de pré-produção para garantir que a velocidade do desenvolvedor não seja prejudicada por inatividade, dependência de processos manuais ou mecanismos de implantação desajeitados.
Se você usa o Kubernetes, uma equipe central de operações ou de engenharia de plataforma pode processar upgrades do Autopilot Kubernetes. Embora os upgrades sejam automáticos, a equipe operacional normalmente os monitora de perto para garantir o mínimo de interrupções nas cargas de trabalho. Algumas organizações escolhem fazer upgrade manual das versões do plano de controle. O GKE Enterprise também inclui recursos para agilizar e simplificar o gerenciamento de aplicativos em vários clusters.
Ao contrário do Autopilot, o Cloud Run não exige sobrecarga de gerenciamento contínua nem upgrades do plano de controle. Ao usar o Cloud Run, você pode simplificar seus processos operacionais. Ao selecionar um único ambiente de execução, você pode simplificar ainda mais seus processos de operações. Se você optar por usar vários ambientes de execução, é necessário garantir que a equipe tenha capacidade, recursos e interesse em oferecer suporte a esses ambientes.
Seleção
Para iniciar o processo de seleção, converse com as várias partes interessadas. Para cada aplicação, monte um grupo de trabalho que consista de desenvolvedores, equipe operacional, representantes de qualquer grupo central de governança de tecnologia, usuários e consumidores de aplicativos internos, equipes de segurança e otimização financeira na nuvem e outras funções ou grupos na sua organização que possam ser relevantes. Você pode circular uma pesquisa de coleta de informações para comparar as características do aplicativo e compartilhar os resultados antes da sessão. Recomendamos que você selecione um pequeno grupo de trabalho que inclua apenas as partes interessadas necessárias. Talvez nem todos os representantes sejam necessários para cada sessão de trabalho.
Também pode ser útil incluir representantes de outras equipes ou grupos que tenham experiência na criação e execução de aplicativos no Autopilot ou no Cloud Run, ou em ambos. Use as considerações técnicas e organizacionais deste documento para orientar a conversa e avaliar a adequação do seu aplicativo para cada uma das plataformas em potencial.
Recomendamos que você agende um check-in após alguns meses para confirmar ou rever a decisão com base nos resultados da implantação do aplicativo no novo ambiente.
A seguir
- Saiba mais sobre esses ambientes de execução com o GKE Autopilot Qwik Start e o laboratório do Cloud Run.
- Leia mais sobre como migrar do Cloud Run para o GKE e do Kubernetes para o Cloud Run.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.
Colaboradores
Autor: Henry Bell | Arquiteto de soluções em nuvem
Outros colaboradores:
- Marco Ferrari | Arquiteto de soluções do Cloud
- Gari Singh | Gerente de produtos de saída
- Maridi (Raju) Makaraju | Líder de tecnologia de suporte
- Parag Doshi | Arquiteto corporativo fundamental
- Daniel Stamer | Engenheiro de clientes, nativos digitais
- Steren Giannini | Gerente de produto do grupo
- Victor Szalvay | Gerente sênior de produtos
- William Denniss | Gerente de produto do grupo