Migrar da AWS para o Google Cloud: migrar do AWS Lambda para o Cloud Run

Last reviewed 2024-10-21 UTC

OGoogle Cloud fornece ferramentas, produtos, orientações e serviços profissionais para ajudar na migração de cargas de trabalho sem servidor do AWS Lambda para o Google Cloud. Embora o Google Cloud forneça vários serviços em que é possível desenvolver e implantar aplicativos sem servidor, este documento se concentra na migração para oCloud Run, um ambiente de execução sem servidor. O AWS Lambda e o Cloud Run têm semelhanças, como provisionamento automático de recursos, escalonamento pelo provedor de nuvem e um modelo de preços de pagamento por uso.

Neste documento, ajudamos você a projetar, implementar e validar um plano para migrar cargas de trabalho sem servidor do AWS Lambda para o Cloud Run. Além disso, ele oferece orientações para quem está avaliando os possíveis benefícios e o processo de uma migração desse tipo.

Este documento faz parte de uma série com várias partes sobre migração da AWS para Google Cloud que inclui os seguintes documentos:

Para mais informações sobre como escolher o ambiente de execução sem servidor certo para sua lógica de negócios, consulte Selecionar um ambiente de execução de contêiner gerenciado. Para um mapeamento abrangente entre os serviços da AWS e do Google Cloud , consulte comparar os serviços da AWS e do Azure com os serviços do Google Cloud .

Para essa migração para Google Cloud, recomendamos que você siga o framework de migração descrito em Migrar para Google Cloud: primeiros passos.

No diagrama a seguir, veja o caminho da sua jornada de migração.

Caminho de migração com quatro fases.

É possível migrar do seu ambiente de origem para Google Cloud em uma série de iterações. Por exemplo, é possível migrar algumas cargas de trabalho primeiro e outras mais tarde. Para cada iteração de migração separada, siga as fases do framework de migração geral:

  1. Avaliar e descobrir suas cargas de trabalho e seus dados.
  2. Planejar e criar uma base no Google Cloud.
  3. Migre suas cargas de trabalho e dados para o Google Cloud.
  4. Otimize seu ambiente Google Cloud .

Para mais informações sobre as fases desse framework, consulte Migrar para Google Cloud: primeiros passos.

Para elaborar um plano de migração eficaz, recomendamos que você valide cada etapa do plano e use uma estratégia de reversão. Para ajudar você a validar o plano de migração, consulte Migrar para o Google Cloud: práticas recomendadas para validar um plano de migração.

A migração de cargas de trabalho sem servidor geralmente vai além da movimentação de funções de um provedor de nuvem para outro. Como os aplicativos baseados na nuvem dependem de uma rede interconectada de serviços, a migração da AWS para o Google Cloud pode exigir a substituição dos serviços dependentes da AWS por serviços do Google Cloud . Por exemplo, considere um cenário em que sua função do Lambda interage com o Amazon SQS e o Amazon SNS. Para migrar essa função, provavelmente será necessário adotar o Pub/Sub e o Cloud Tasks para alcançar uma funcionalidade semelhante.

A migração também oferece uma oportunidade valiosa para revisar completamente a arquitetura e as decisões de design do seu aplicativo sem servidor. Com essa análise, você pode descobrir oportunidades para fazer o seguinte:

  • Otimize com os Google Cloud recursos integrados: veja se os serviços doGoogle Cloud oferecem vantagens exclusivas ou se alinham melhor aos requisitos do seu aplicativo.
  • Simplifique sua arquitetura: avalie se é possível otimizar consolidando funcionalidades ou usando serviços de maneira diferente noGoogle Cloud.
  • Melhorar a eficiência de custos: avalie as possíveis diferenças de custo de executar o aplicativo refatorado na infraestrutura fornecida no Google Cloud.
  • Melhorar a eficiência do código: refatore seu código durante o processo de migração.

Planeje sua migração de forma estratégica. Não veja sua migração como um exercício de rehost (lift-and-shift). Use a migração como uma chance de melhorar o design geral e a qualidade do código do seu aplicativo sem servidor.

Avaliar o ambiente de origem

Na fase de avaliação, você determina os requisitos e as dependências para migrar seu ambiente de origem para o Google Cloud.

A fase de avaliação é fundamental para o sucesso da migração. Você precisa ter um excelente conhecimento das cargas de trabalho que quer migrar, dos requisitos, das dependências e do ambiente atual. Você precisa saber seu ponto de partida para planejar e executar uma migração do Google Cloud.

A fase de avaliação consiste nas tarefas a seguir:

  1. Criar um inventário abrangente das suas cargas de trabalho.
  2. Catalogar suas cargas de trabalho de acordo com as propriedades e dependências delas.
  3. Treine e instrua suas equipes sobre o Google Cloud.
  4. Crie experimentos e provas de conceito no Google Cloud.
  5. Calcule o custo total de propriedade (TCO) do ambiente de destino.
  6. Escolha a estratégia de migração para suas cargas de trabalho.
  7. Escolha as ferramentas de migração.
  8. Defina o plano e o cronograma de migração.
  9. Valide seu plano de migração.

Para mais informações sobre a fase de avaliação e essas tarefas, consulte Migrar para o Google Cloud: avaliar e descobrir suas cargas de trabalho. As seções a seguir são baseadas nas informações desse documento.

Criar um inventário das suas cargas de trabalho do AWS Lambda

Para definir o escopo da migração, crie um inventário e colete informações sobre suas cargas de trabalho do AWS Lambda.

Para criar o inventário das suas cargas de trabalho do AWS Lambda, recomendamos que você implemente um mecanismo de coleta de dados com base nas APIs e ferramentas de desenvolvedor da AWS e na interface de linha de comando da AWS.

Depois de criar o inventário, recomendamos coletar informações sobre cada carga de trabalho do AWS Lambda nele. Para cada carga de trabalho, concentre-se em aspectos que ajudam a antecipar possíveis atritos. Além disso, analise essa carga de trabalho para entender como você pode precisar modificar a carga de trabalho e as dependências dela antes de migrar para o Cloud Run. Recomendamos que você comece coletando dados sobre os seguintes aspectos de cada carga de trabalho do AWS Lambda:

  • O caso de uso e o design
  • O repositório de código-fonte
  • Os artefatos de implantação
  • A invocação, os acionadores e as saídas
  • Os ambientes de execução e de tempo de execução
  • A configuração da carga de trabalho
  • Os controles de acesso e as permissões
  • Os requisitos regulatórios e de conformidade
  • Os processos operacionais e de implantação

Caso de uso e design

Reunir informações sobre o caso de uso e o design das cargas de trabalho ajuda a identificar uma estratégia de migração adequada. Essas informações também ajudam você a entender se é necessário modificar as cargas de trabalho e as dependências delas antes da migração. Para cada carga de trabalho, recomendamos que você faça o seguinte:

  • Entenda o caso de uso específico atendido pela carga de trabalho e identifique dependências com outros sistemas, recursos ou processos.
  • Analise o design e a arquitetura da carga de trabalho.
  • Avalie os requisitos de latência da carga de trabalho.

Repositório de códigos-fonte

Inventariar o código-fonte das funções do AWS Lambda ajuda se você precisar refatorar as cargas de trabalho do AWS Lambda para compatibilidade com o Cloud Run. Para criar esse inventário, é necessário rastrear a base de código, que geralmente é armazenada em sistemas de controle de versões, como o Git, ou em plataformas de desenvolvimento, como o GitHub ou o GitLab. O inventário do seu código-fonte é essencial para os processos de DevOps, como pipelines de integração contínua e desenvolvimento contínuo (CI/CD), porque eles também precisam ser atualizados quando você migra para o Cloud Run.

Artefatos de implantação

Saber quais artefatos de implantação são necessários para a carga de trabalho é outro componente que ajuda a entender se é preciso refatorar as cargas de trabalho do AWS Lambda. Para identificar os artefatos de implantação necessários para a carga de trabalho, colete as seguintes informações:

  • O tipo de pacote de implantação para implantar a carga de trabalho.
  • Qualquer camada do AWS Lambda que contenha código adicional, como bibliotecas e outras dependências.
  • Todas as extensões do AWS Lambda de que a carga de trabalho depende.
  • Os qualificadores que você configurou para especificar versões e aliases.
  • A versão da carga de trabalho implantada.

Invocação, acionadores e saídas

O AWS Lambda é compatível com vários mecanismos de invocação, como gatilhos, e diferentes modelos de invocação, como invocação síncrona e assíncrona. Para cada carga de trabalho do AWS Lambda, recomendamos que você colete as seguintes informações relacionadas a gatilhos e invocações:

  • Os gatilhos e os mapeamentos de origem de eventos que invocam a carga de trabalho.
  • Se a carga de trabalho aceita invocações síncronas e assíncronas.
  • Os URLs de carga de trabalho e os endpoints HTTP(S).

Suas cargas de trabalho do AWS Lambda podem interagir com outros recursos e sistemas. É preciso saber quais recursos consomem as saídas das suas cargas de trabalho do AWS Lambda e como eles consomem essas saídas. Esse conhecimento ajuda você a determinar se precisa modificar algo que possa depender dessas saídas, como outros sistemas ou cargas de trabalho. Para cada carga de trabalho do AWS Lambda, recomendamos que você colete as seguintes informações sobre outros recursos e sistemas:

  • Os recursos de destino para os quais a carga de trabalho pode enviar eventos.
  • Os destinos que recebem registros de informações para invocações assíncronas.
  • O formato dos eventos que a carga de trabalho processa.
  • Como sua carga de trabalho do AWS Lambda e as extensões interagem com as APIs do AWS Lambda ou outras APIs da AWS.

Para funcionar, suas cargas de trabalho do AWS Lambda podem armazenar dados persistentes e interagir com outros serviços da AWS. Para cada carga de trabalho do AWS Lambda, recomendamos que você colete as seguintes informações sobre dados e outros serviços:

  • Se a carga de trabalho acessa nuvens privadas virtuais (VPCs) ou outras redes privadas.
  • Como a carga de trabalho armazena dados permanentes, como o uso de armazenamento de dados temporários e o Amazon Elastic File System (EFS).

Ambientes de execução e de execução

O AWS Lambda é compatível com vários ambientes de execução para suas cargas de trabalho. Para mapear corretamente os ambientes de execução do AWS Lambda para os ambientes de execução do Cloud Run, recomendamos que você avalie o seguinte para cada carga de trabalho do AWS Lambda:

  • O ambiente de execução da carga de trabalho.
  • A arquitetura do conjunto de instruções do processador do computador em que a carga de trabalho é executada.

Se as cargas de trabalho do AWS Lambda forem executadas em ambientes de execução específicos da linguagem, considere o seguinte para cada carga de trabalho do AWS Lambda:

  • O tipo, a versão e o identificador exclusivo do ambiente de execução específico da linguagem.
  • Todas as modificações aplicadas ao ambiente de execução.

Configuração da carga de trabalho

Para configurar as cargas de trabalho ao migrá-las do AWS Lambda para o Cloud Run, recomendamos que você avalie como configurou cada carga de trabalho do AWS Lambda.

Para cada carga de trabalho do AWS Lambda, reúna informações sobre as seguintes configurações de simultaneidade e escalonabilidade:

  • Os controles de simultaneidade.
  • As configurações de escalonabilidade.
  • A configuração das instâncias da carga de trabalho, em termos da quantidade de memória disponível e do tempo máximo de execução permitido.
  • Se a carga de trabalho está usando o AWS Lambda SnapStart, a simultaneidade reservada ou a simultaneidade provisionada para reduzir a latência.
  • As variáveis de ambiente que você configurou, bem como as que o AWS Lambda configura e de que a carga de trabalho depende.
  • As tags e o controle de acesso baseado em atributos.
  • A máquina de estado para processar condições excepcionais.
  • As imagens de base e os arquivos de configuração (como o Dockerfile) para pacotes de implantação que usam imagens de contêiner.

Controles de acesso e permissões

Como parte da sua avaliação, recomendamos que você avalie os requisitos de segurança das cargas de trabalho do AWS Lambda e a configuração delas em termos de controles e gerenciamento de acesso. Essas informações são essenciais se você precisar implementar controles semelhantes no seu ambiente Google Cloud . Para cada carga de trabalho, considere o seguinte:

  • O papel e as permissões de execução.
  • A configuração de gerenciamento de identidade e acesso que a carga de trabalho e as camadas usam para acessar outros recursos.
  • A configuração de gerenciamento de identidade e acesso que outras contas e serviços usam para acessar a carga de trabalho.
  • Os controles de governança.

Requisitos regulatórios e de conformidade

Para cada carga de trabalho do AWS Lambda, entenda os requisitos regulamentares e de conformidade fazendo o seguinte:

  • Avalie todos os requisitos regulamentares e de compliance que a carga de trabalho precisa atender.
  • Determine se a carga de trabalho atende a esses requisitos.
  • Determine se há requisitos futuros que precisam ser atendidos.

Os requisitos regulamentares e de compliance podem ser independentes do provedor de nuvem que você está usando e podem afetar a migração também. Por exemplo, talvez seja necessário garantir que os dados e o tráfego de rede permaneçam dentro dos limites de determinadas regiões geográficas, como a União Europeia (UE).

Avaliar os processos operacionais e de implantação

É fundamental ter um entendimento claro de como seus processos operacionais e de implantação funcionam. Eles são parte fundamental das práticas que preparam e mantêm o ambiente de produção e as cargas de trabalho executadas nele.

Os processos operacionais e de implantação podem criar os artefatos necessários para as cargas de trabalho funcionarem. Portanto, colete informações sobre cada tipo de artefato. Por exemplo, um artefato pode ser um pacote de sistema operacional, um pacote de implantação de aplicativo, uma imagem do sistema operacional, uma imagem de contêiner ou qualquer outra coisa.

Além do tipo de artefato, considere como você conclui as seguintes tarefas:

  • Desenvolva seus workloads. Avalie os processos que as equipes de desenvolvimento têm para criar suas cargas de trabalho. Por exemplo, como suas equipes de desenvolvimento projetam, codificam e testam suas cargas de trabalho?
  • Gerar os artefatos implantados no ambiente de origem. Para implantar as cargas de trabalho no ambiente de origem, você pode gerar artefatos implantáveis, como imagens de contêiner ou do sistema operacional, ou personalizar artefatos existentes, como imagens de sistema operacional de terceiros, instalando e configurando software. A coleta de informações sobre como você gera esses artefatos ajuda a garantir que os artefatos gerados sejam adequados para implantação no Google Cloud.

  • Armazene os artefatos. Se você produzir artefatos armazenados em um registro de artefatos no ambiente de origem, será necessário disponibilizá-los no ambiente do Google Cloud . Para fazer isso, use estratégias como as seguintes:

    • Estabeleça um canal de comunicação entre os ambientes: torne os artefatos no ambiente de origem acessíveis pelo ambiente de destino Google Cloud .
    • Refatorar o processo de compilação do artefato: conclua uma pequena refatoração do ambiente de origem para que seja possível armazenar artefatos nos ambientes de origem e de destino. Essa abordagem oferece suporte à migração por meio da criação de uma infraestrutura como um repositório de artefatos antes da implementação dos processos de compilação de artefatos no ambiente Google Cloud de destino. É possível implementar essa abordagem diretamente ou aproveitar a abordagem anterior de estabelecer um canal de comunicação primeiro.

    Ter artefatos disponíveis nos ambientes de origem e de destino permite que você se concentre na migração sem precisar implementar processos de criação de artefatos no ambiente de destino Google Cloud como parte da migração.

  • Ler e assinar o código. Como parte dos processos de build de artefatos, você pode usar a verificação de código para se proteger contra vulnerabilidades comuns e exposição não intencional à rede, além de assinar o código para garantir que apenas códigos confiáveis sejam executados nos seus ambientes.

  • Implante artefatos no ambiente de origem. Depois de gerar artefatos implantáveis, você pode implantá-los no ambiente de origem. Recomendamos que você avalie cada processo de implantação. A avaliação ajuda a garantir que os processos de implantação sejam compatíveis com o Google Cloud. Isso também ajuda você a entender o esforço necessário para refatorar os processos. Por exemplo, se os processos de implantação funcionarem apenas com o ambiente de origem, talvez seja necessário refatorá-los para segmentar o ambiente do Google Cloud .

  • Injetar a configuração do ambiente de execução. Talvez você esteja injetando a configuração do ambiente de execução para clusters, ambientes de execução ou implantações de carga de trabalho específicos. A configuração pode inicializar variáveis de ambiente e outros valores de configuração, como segredos, credenciais e chaves. Para garantir que os processos de injeção de configuração do ambiente de execução funcionem no Google Cloud, recomendamos que você avalie como está configurando as cargas de trabalho executadas no ambiente de origem.

  • Geração de registros, monitoramento e criação de perfis. Avalie os processos de registro, monitoramento e criação de perfil que você tem para monitorar a integridade do ambiente de origem, as métricas de interesse e como você consome os dados fornecidos por esses processos.

  • Autenticação. Avalie como você está fazendo a autenticação no seu ambiente de origem.

  • Provisione e configure seus recursos. Para preparar o ambiente de origem, é possível que você tenha projetado e implementado processos que provisionem e configurem recursos. Por exemplo, você pode usar o Terraform com ferramentas de gerenciamento de configuração para provisionar e configurar recursos no ambiente de origem.

Concluir a avaliação

Depois de criar os inventários do ambiente do AWS Lambda, conclua o restante das atividades da fase de avaliação, conforme descrito em Migrar para o Google Cloud: avaliar e descobrir cargas de trabalho.

Planejar e criar sua base

Na fase de planejamento e criação, você provisiona e configura a infraestrutura para fazer o seguinte:

  • Oferecer suporte às cargas de trabalho no ambiente Google Cloud .
  • Conecte os ambientes de origem e do Google Cloud para concluir a migração.

A fase de criação e planejamento é composta pelas seguintes tarefas:

  1. Crie uma hierarquia de recursos.
  2. Configure o Identity and Access Management (IAM) do Google Cloud.
  3. Configure o faturamento.
  4. Configurar a conectividade de rede.
  5. Aumentar sua segurança.
  6. Configurar a geração de registros, o monitoramento e os alertas.

Para mais informações sobre cada uma dessas tarefas, consulte Migrar para o Google Cloud: planejar e criar sua base.

Migrar suas cargas de trabalho do AWS Lambda

Para migrar suas cargas de trabalho do AWS Lambda para o Cloud Run, faça o seguinte:

  1. Projete, provisione e configure seu ambiente do Cloud Run.
  2. Se necessário, refatore suas cargas de trabalho do AWS Lambda para torná-las compatíveis com o Cloud Run.
  3. Refatore os processos operacionais e de implantação para implantar e observar as cargas de trabalho no Cloud Run.
  4. Migre os dados necessários para suas cargas de trabalho do AWS Lambda.
  5. Valide os resultados da migração em termos de funcionalidade, desempenho e custo.

Para evitar problemas durante a migração e estimar o esforço necessário para a migração, recomendamos que você avalie como os recursos do AWS Lambda se comparam aos recursos semelhantes do Cloud Run. Os recursos do AWS Lambda e do Cloud Run podem parecer semelhantes quando comparados. No entanto, as diferenças no design e na implementação dos recursos nos dois provedores de nuvem podem ter efeitos significativos na migração do AWS Lambda para o Cloud Run. Essas diferenças podem influenciar suas decisões de design e refatoração, conforme destacado nas seções a seguir.

Projetar, provisionar e configurar seu ambiente do Cloud Run

A primeira etapa da fase de migração é projetar seu ambiente do Cloud Run para que ele possa oferecer suporte às cargas de trabalho que você está migrando do AWS Lambda.

Para projetar corretamente seu ambiente do Cloud Run, use os dados coletados durante a fase de avaliação sobre cada carga de trabalho do AWS Lambda. Esses dados ajudam você a fazer o seguinte:

  1. Escolha os recursos certos do Cloud Run para implantar sua carga de trabalho.
  2. Projete a configuração dos recursos do Cloud Run.
  3. Provisione e configure os recursos do Cloud Run.

Escolher os recursos certos do Cloud Run

Para cada carga de trabalho do AWS Lambda a ser migrada, escolha o recurso do Cloud Run certo para implantar suas cargas de trabalho. O Cloud Run é compatível com os seguintes recursos principais:

  • Serviços do Cloud Run: um recurso que hospeda um ambiente de execução em contêineres, expõe um endpoint exclusivo e escalona automaticamente a infraestrutura subjacente de acordo com a demanda.
  • Jobs do Cloud Run: um recurso que executa um ou mais contêineres até a conclusão.

A tabela a seguir resume como os recursos do AWS Lambda são mapeados para os principais recursos do Cloud Run:

Recurso do AWS Lambda Recurso do Cloud Run
Função do AWS Lambda acionada por um evento, como os usados para sites e aplicativos da Web, APIs e microsserviços, processamento de dados de streaming e arquiteturas orientadas a eventos. Serviço do Cloud Run que pode ser invocado com gatilhos.
Função do AWS Lambda programada para execução, como as de tarefas em segundo plano e jobs em lote. Job do Cloud Run que é executado até a conclusão.

Além de serviços e jobs, o Cloud Run oferece outros recursos que estendem esses recursos principais. Para mais informações sobre todos os recursos disponíveis do Cloud Run, consulte Modelo de recursos do Cloud Run.

Projetar a configuração dos recursos do Cloud Run

Antes de provisionar e configurar os recursos do Cloud Run, você precisa projetar a configuração deles. Algumas opções de configuração do AWS Lambda, como limites de recursos e tempos limite de solicitação, são comparáveis a opções de configuração semelhantes do Cloud Run. As seções a seguir descrevem as opções de configuração disponíveis no Cloud Run para acionadores de serviço e execução de jobs, configuração de recursos e segurança. Essas seções também destacam as opções de configuração do AWS Lambda que são comparáveis às do Cloud Run.

Gatilhos de serviço e execução de jobs do Cloud Run

Os gatilhos de serviço e a execução de jobs são as principais decisões de design que você precisa considerar ao migrar suas cargas de trabalho do AWS Lambda. O Cloud Run oferece várias opções para acionar e executar as cargas de trabalho baseadas em eventos usadas no AWS Lambda. Além disso, o Cloud Run oferece opções que podem ser usadas para cargas de trabalho de streaming e jobs programados.

Ao migrar suas cargas de trabalho, é útil entender primeiro quais gatilhos e mecanismos estão disponíveis no Cloud Run. Essas informações ajudam você a entender como o Cloud Run funciona. Em seguida, use esse entendimento para determinar quais recursos do Cloud Run são comparáveis aos do AWS Lambda e quais recursos do Cloud Run podem ser usados ao refatorar essas cargas de trabalho.

Para saber mais sobre os gatilhos de serviço fornecidos pelo Cloud Run, use os seguintes recursos:

Para saber mais sobre os mecanismos de execução de jobs fornecidos pelo Cloud Run, use os seguintes recursos:

Para entender quais mecanismos de invocação ou execução do Cloud Run são comparáveis aos mecanismos de invocação do AWS Lambda, use a tabela a seguir. Para cada recurso do Cloud Run que você precisa provisionar, escolha o mecanismo de invocação ou execução certo.

Recurso do AWS Lambda Recurso do Cloud Run
Gatilho HTTPS (URLs de função) Chamada HTTPS
Gatilho HTTP/2 (parcialmente compatível usando um gateway de API externo) Invocação HTTP/2 (com suporte nativo)
WebSockets (compatível com o uso de um gateway de API externo) WebSockets (com suporte nativo)
N/A (conexões gRPC não compatíveis) Conexões gRPC
Invocação assíncrona Integração do Cloud Tasks
Invocação programada Integração com o Cloud Scheduler
Gatilho baseado em eventos em um formato de evento proprietário Invocação com base em eventos no formato CloudEvents
Integração do Amazon SQS e do Amazon SNS Integração do Pub/Sub
AWS Lambda Step Functions Integração com o Workflows
Configuração de recursos do Cloud Run

Para complementar as decisões de design tomadas para acionar e executar as cargas de trabalho migradas, o Cloud Run oferece várias opções de configuração que permitem ajustar vários aspectos do ambiente de execução. Essas opções de configuração consistem em serviços e jobs de recursos.

Como mencionado anteriormente, para entender melhor como o Cloud Run funciona, primeiro é preciso conhecer todas as opções de configuração disponíveis no serviço. Essa compreensão ajuda você a comparar recursos do AWS Lambda com recursos semelhantes do Cloud Run e a determinar como refatorar suas cargas de trabalho.

Para saber mais sobre as configurações que os serviços do Cloud Run oferecem, use os seguintes recursos:

Para saber mais sobre os jobs que o Cloud Run oferece, use os seguintes recursos:

Para entender quais opções de configuração do Cloud Run são comparáveis às opções de configuração do AWS Lambda, use a tabela a seguir. Para cada recurso do Cloud Run que você precisa provisionar, escolha as opções de configuração corretas.

Recurso do AWS Lambda Recurso do Cloud Run
Simultaneidade provisionada Instâncias mínimas
Simultaneidade reservada por instância
(O pool de simultaneidade é compartilhado entre as funções do AWS Lambda na sua conta da AWS.)		 Número máximo de instâncias por serviço
Não aplicável (não compatível, uma solicitação é mapeada para uma instância) Solicitações simultâneas por instância
N/A (depende da alocação de memória) Alocação de CPU
Configurações de escalonabilidade Escalonamento automático de instâncias para serviços
Paralelismo para jobs
Configuração da instância (CPU, memória) Limites de CPU e memória
Tempo máximo de execução Tempo limite da solicitação para serviços
Tempo limite da tarefa para jobs
AWS Lambda SnapStart Otimização da CPU de inicialização
Variáveis de ambiente Variáveis de ambiente
Armazenamento de dados temporário Montagens de volumes na memória
Conexões do Amazon Elastic File System Montagens de volumes NFS
Não há suporte para montagens de volume do S3 Montagens de volumes do Cloud Storage
AWS Secrets Manager em workloads do AWS Lambda Secrets
URLs de carga de trabalho e endpoints HTTP(S) URLs atribuídos automaticamente
Integrações do Cloud Run com produtos Google Cloud
Sessões fixas (usando um balanceador de carga externo) afinidade da sessão
Qualificadores Revisões

Além dos recursos listados na tabela anterior, considere as diferenças entre como o AWS Lambda e o Cloud Run provisionam instâncias do ambiente de execução. O AWS Lambda provisiona uma única instância para cada solicitação simultânea. No entanto, o Cloud Run permite definir o número de solicitações simultâneas que uma instância pode atender. Ou seja, o comportamento de provisionamento do AWS Lambda é equivalente a definir o número máximo de solicitações simultâneas por instância como 1 no Cloud Run. Definir o número máximo de solicitações simultâneas como mais de 1 pode economizar custos significativamente, porque a CPU e a memória da instância são compartilhadas pelas solicitações simultâneas, mas só são cobradas uma vez. A maioria dos frameworks HTTP é projetada para processar solicitações em paralelo.

Segurança e controle de acesso do Cloud Run

Ao projetar seus recursos do Cloud Run, você também precisa decidir sobre os controles de segurança e acesso necessários para suas cargas de trabalho migradas. O Cloud Run oferece várias opções de configuração para ajudar você a proteger seu ambiente e definir papéis e permissões para suas cargas de trabalho do Cloud Run.

Esta seção destaca os controles de segurança e acesso disponíveis no Cloud Run. Essas informações ajudam você a entender como as cargas de trabalho migradas vão funcionar no Cloud Run e a identificar as opções do Cloud Run que podem ser necessárias se você refatorar essas cargas de trabalho.

Para saber mais sobre os mecanismos de autenticação fornecidos pelo Cloud Run, use os seguintes recursos:

Para saber mais sobre os recursos de segurança oferecidos pelo Cloud Run, use os seguintes recursos:

Para ajudar você a entender quais controles de segurança e acesso do Cloud Run são comparáveis aos disponíveis no AWS Lambda, use a tabela a seguir. Para cada recurso do Cloud Run que você precisa provisionar, escolha os controles de acesso e recursos de segurança certos.

Recurso do AWS Lambda Recurso do Cloud Run
Controle de acesso com o AWS Identity Access and Management Controle de acesso com o IAM do Google Cloud
Função de execução Papel do IAM deGoogle Cloud
Limites de permissão Permissões do IAM e públicos-alvo personalizados doGoogle Cloud
Controles de governança Organization Policy Service
Assinatura de código Autorização binária
Acesso total à VPC Controles granulares de acesso de saída da VPC

Provisionar e configurar recursos do Cloud Run

Depois de escolher os recursos do Cloud Run para implantar suas cargas de trabalho, provisione e configure esses recursos. Para mais informações< sobre o provisionamento de recursos do Cloud Run, consulte o seguinte:

Refatorar cargas de trabalho do AWS Lambda

Para migrar suas cargas de trabalho do AWS Lambda para o Cloud Run, talvez seja necessário refatorá-las. Por exemplo, se uma carga de trabalho baseada em eventos aceitar gatilhos que contenham eventos do Amazon CloudWatch, talvez seja necessário refatorar essa carga de trabalho para que ela aceite eventos no formato CloudEvents.

Há vários fatores que podem influenciar a quantidade de refatoração necessária para cada carga de trabalho do AWS Lambda, como:

  • Arquitetura. Considere como a carga de trabalho é projetada em termos de arquitetura. Por exemplo, cargas de trabalho do AWS Lambda que separaram claramente a lógica de negócios da lógica para acessar APIs específicas da AWS podem exigir menos refatoração em comparação com cargas de trabalho em que as duas lógicas estão misturadas.
  • Idempotência. Considere se a carga de trabalho é idempotente em relação às entradas. Uma carga de trabalho idempotente para entradas pode exigir menos refatoração em comparação com cargas de trabalho que precisam manter o estado sobre quais entradas já foram processadas.
  • Estado. Considere se a carga de trabalho é sem estado. Uma carga de trabalho sem estado pode exigir menos refatoração em comparação com cargas de trabalho que mantêm o estado. Para mais informações sobre os serviços compatíveis com o Cloud Run para armazenar dados, consulte Opções de armazenamento do Cloud Run.
  • Ambiente de execução. Considere se a carga de trabalho faz alguma suposição sobre o ambiente de execução. Para esses tipos de cargas de trabalho, talvez seja necessário atender às mesmas proposições no ambiente de execução do Cloud Run ou refatorar a carga de trabalho se não for possível presumir o mesmo para o ambiente de execução do Cloud Run. Por exemplo, se uma carga de trabalho exigir que determinados pacotes ou bibliotecas estejam disponíveis, instale-os no ambiente de execução do Cloud Run que vai hospedar essa carga de trabalho.
  • Injeção de configuração. Considere se a carga de trabalho aceita o uso de variáveis de ambiente e secrets para injetar (definir) a configuração. Uma carga de trabalho que oferece suporte a esse tipo de injeção pode exigir menos refatoração em comparação com cargas de trabalho que oferecem suporte a outros mecanismos de injeção de configuração.
  • APIs. Considere se a carga de trabalho interage com as APIs do AWS Lambda. Uma carga de trabalho que interage com essas APIs pode precisar ser refatorada para usar as APIs do Cloud e do Cloud Run.
  • Relatórios de erros. Considere se a carga de trabalho gera relatórios de erros usando fluxos de saída e erro padrão. Uma carga de trabalho que faz esse tipo de relatório de erros pode exigir menos refatoração em comparação com cargas de trabalho que informam erros usando outros mecanismos.

Para mais informações sobre como desenvolver e otimizar cargas de trabalho do Cloud Run, consulte os seguintes recursos:

Refatorar os processos operacionais e de implantação

Depois de refatorar as cargas de trabalho, refatore os processos operacionais e de implantação para fazer o seguinte:

  • Provisione e configure recursos no ambiente do Google Cloud , em vez de provisionar recursos no ambiente de origem.
  • Crie e configure cargas de trabalho e implante-as no Google Cloud em vez de implantá-las no ambiente de origem.

Você coletou informações sobre esses processos durante a fase de avaliação anterior.

O tipo de refatoração que você precisa considerar para esses processos depende de como você os projetou e implementou. A refatoração também depende do estado final desejado para cada processo. Por exemplo, considere o seguinte:

  • Talvez você tenha implementado esses processos no ambiente de origem e queira projetar e implementar processos semelhantes no Google Cloud. Por exemplo, é possível refatorar esses processos para usar o Cloud Build, o Cloud Deploy e o Infrastructure Manager.
  • Talvez você tenha implementado esses processos em outro ambiente de terceiros fora do ambiente de origem. Nesse caso, é necessário refatorar esses processos para definir como destino o ambiente do Google Cloud em vez do ambiente de origem.
  • Uma combinação das abordagens anteriores.

A refatoração de processos operacionais e de implantação pode ser complexa e exigir um esforço significativo. Se você tentar realizar essas tarefas como parte da migração de carga de trabalho, a migração de carga de trabalho poderá se tornar mais complexa e expor você a riscos. Depois de avaliar os processos operacionais e de implantação, você provavelmente entenderá o design e a complexidade deles. Se você acredita que requer um esforço significativo para refatorar seus processos operacionais e de implantação, recomendamos considerar a refatoração desses processos como parte de um projeto dedicado e separado.

Para mais informações sobre como projetar e implementar processos de implantação no Google Cloud, consulte:

Este documento se concentra nos processos de implantação que produzem os artefatos a serem implantados e os implantam no ambiente de execução de destino. A estratégia de refatoração depende muito da complexidade desses processos. A lista a seguir descreve uma possível estratégia geral de refatoração:

  1. Provisione repositórios de artefatos em Google Cloud. Por exemplo, é possível usar o Artifact Registry para armazenar artefatos e criar dependências.
  2. Refatore seus processos de build para armazenar artefatos no ambiente de origem e no Artifact Registry.
  3. Refatore os processos de implantação para implantar cargas de trabalho no ambiente de destino Google Cloud . Por exemplo, você pode começar implantando um pequeno subconjunto das suas cargas de trabalho no Google Cloudusando artefatos armazenados no Artifact Registry. Em seguida, aumente gradualmente o número de cargas de trabalho implantadas em Google Cloudaté que todas as cargas de trabalho a serem migradas sejam executadas em Google Cloud.
  4. Refactorize seus processos de build para armazenar artefatos apenas no Artifact Registry.
  5. Se necessário, migre versões anteriores dos artefatos a serem implantado dos repositórios no ambiente de origem para o Artifact Registry. Por exemplo, é possível copiar imagens de contêiner para o Artifact Registry.
  6. Desative os repositórios no ambiente de origem quando não precisar mais deles.

Para facilitar as revisões devido a problemas inesperados durante a migração, é possível armazenar imagens de contêiner nos repositórios de artefatos atuais no Google Cloud enquanto a migração para Google Cloud estiver em andamento. Por fim, como parte da desativação do ambiente de origem, é possível refatorar os processos de criação de imagens de contêiner para armazenar artefatos apenas no Google Cloud .

Embora não seja crucial para o sucesso de uma migração, talvez seja necessário migrar as versões anteriores dos artefatos do ambiente de origem para os repositórios de artefatos no Google Cloud. Por exemplo, para oferecer suporte ao reversão de cargas de trabalho para pontos arbitrários no tempo, talvez seja necessário migrar versões anteriores dos artefatos para o Artifact Registry. Para mais informações, consulte Migrar imagens de um registro de terceiros.

Se você estiver usando o Artifact Registry para armazenar artefatos, recomendamos que configure controles para ajudar a proteger seus repositórios de artefatos, como controle de acesso, prevenção de exfiltração de dados, verificação de vulnerabilidade e autorização binária. Para mais informações, consulte Controlar o acesso e proteger artefatos.

Refatorar processos operacionais

Como parte da migração para o Cloud Run, recomendamos que você refatore seus processos operacionais para monitorar constantemente e de maneira eficaz seu ambiente do Cloud Run.

O Cloud Run se integra aos seguintes serviços operacionais:

Migrar dados

A fase de avaliação anterior neste processo deve ter ajudado você a determinar se as cargas de trabalho do AWS Lambda que você está migrando dependem ou produzem dados que residem no seu ambiente da AWS. Por exemplo, você pode ter determinado que precisa migrar dados do AWS S3 para o Cloud Storage ou do Amazon RDS e Aurora para o Cloud SQL e o AlloyDB para PostgreSQL. Para mais informações sobre como migrar dados da AWS para o Google Cloud, consulte Migrar da AWS para o Google Cloud: primeiros passos.

Assim como a refatoração de processos operacionais e de implantação, a migração de dados da AWS para o Google Cloud pode ser complexa e exigir um esforço significativo. Se você tentar realizar essas tarefas de migração de dados como parte da migração das cargas de trabalho do AWS Lambda, a migração poderá se tornar complexa e expor você a riscos. Depois de analisar os dados a serem migrados, você provavelmente vai entender o tamanho e a complexidade deles. Se você acredita que requer um esforço significativo para migrar esses dados, recomendamos considerar a migração como parte de um projeto dedicado e separado.

Validar os resultados da migração

A validação da migração da carga de trabalho não é um evento único, mas um processo contínuo. É necessário manter o foco em testes e validação antes, durante e depois da migração do AWS Lambda para o Cloud Run.

Para garantir uma migração bem-sucedida com desempenho ideal e interrupções mínimas, recomendamos que você use o processo a seguir para validar as cargas de trabalho que está migrando do AWS Lambda para o Cloud Run:

  • Antes de iniciar a fase de migração, refatore os casos de teste atuais para considerar o ambiente Google Cloud de destino.
  • Durante a migração, valide os resultados dos testes em cada marco e faça testes de integração completos.
  • Após as migrações, faça os seguintes testes:
    • Teste de comparativo de mercado: estabeleça comparativos de mercado de desempenho da carga de trabalho original no AWS Lambda, como tempo de execução, uso de recursos e taxas de erro em diferentes cargas. Replique esses testes no Cloud Run para identificar discrepâncias que possam indicar problemas de migração ou configuração.
    • Teste funcional: garanta que a lógica principal das suas cargas de trabalho permaneça consistente criando e executando casos de teste que abranjam vários cenários de entrada e saída esperados nos dois ambientes.
    • Teste de carga: aumente gradualmente o tráfego para avaliar o desempenho e a escalonabilidade do Cloud Run em condições reais. Para garantir uma migração tranquila, resolva as discrepâncias, como erros e limitações de recursos.

Otimizar seu ambiente Google Cloud

A otimização é a última fase da migração. Nesta fase, você repete as tarefas de otimização até que o ambiente de destino atenda aos requisitos de otimização. As etapas de cada iteração são as seguintes:

  1. Avaliar o ambiente, as equipes e o ciclo de otimização atuais.
  2. Estabeleça suas metas e requisitos de otimização.
  3. Otimize o ambiente e as equipes.
  4. Ajustar o loop de otimização.

Repita essa sequência até alcançar suas metas de otimização.

Para mais informações sobre como otimizar o ambiente do Google Cloud , consulte Migrar para o Google Cloud: otimizar o ambiente e Google Cloud Estrutura bem arquitetada: otimização de performance.

A seguir

Colaboradores

Autores:

Outros colaboradores: