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

Google Cloud fornece ferramentas, produtos, orientação e serviços profissionais para ajudar na migração de cargas de trabalho sem servidor do Amazon Web Services (AWS) Lambda para o Google Cloud. Embora Google Cloud forneça vários serviços para desenvolver e implantar aplicativos sem servidor, este documento se concentra na migração para o Cloud Run, um ambiente de execução sem servidor. O AWS Lambda e o Cloud Run compartilham semelhanças, como provisionamento automático de recursos, escalonamento pelo provedor de nuvem e modelo de preços de pagamento por utilização.

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, oferece orientação para quem avalia os possíveis benefícios e o processo de tal migração.

Este documento faz parte de uma série sobre como migrar 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 Google Cloud e da AWS, consulte Comparar os serviços da AWS e do Azure com Google Cloud os serviços.

Nessa 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 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. Planeje e crie uma base no Google Cloud.
  3. Migre cargas de trabalho e dados para o Google Cloud.
  4. Otimize seu Google Cloud ambiente.

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 seu plano de migração, consulte Migrar para Google Cloud: práticas recomendadas para validar um plano de migração.

A migração de cargas de trabalho sem servidor geralmente se estende além da simples transferência de funções de um provedor de nuvem para outro. Como os aplicativos baseados na nuvem dependem de uma web interconectada de serviços, a migração da AWS para a Google Cloud pode exigir a substituição dos serviços dependentes da AWS por Google Cloud serviços. Por exemplo, considere um cenário em que a função do Lambda interage com o Amazon SQS e o Amazon SNS. Para migrar essa função, você provavelmente precisará adotar o Pub/Sub e o Cloud Tasks para conseguir uma funcionalidade semelhante.

A migração também oferece uma oportunidade valiosa para você analisar minuciosamente as decisões de design e arquitetura do seu aplicativo sem servidor. Nessa revisão, você pode descobrir oportunidades para fazer o seguinte:

  • Otimize com Google Cloud recursos integrados: analise se os Google Cloud serviços oferecem vantagens exclusivas ou se alinham melhor aos requisitos do seu aplicativo.
  • Simplifique sua arquitetura: avalie se a simplificação é possível consolidando as funcionalidades ou usando serviços de forma diferente no Google Cloud.
  • Melhorar a economia: avalie as possíveis diferenças de custo da execução do aplicativo refatorado na infraestrutura fornecida no Google Cloud.
  • Melhorar a eficiência do código: refatore o código junto com o processo de migração.

Planeje sua migração estrategicamente. Não veja sua migração como um exercício de re-hospedagem (migração 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 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 entender 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 Google Cloud: avaliar e descobrir suas cargas de trabalho. As seções a seguir são baseadas nas informações desse documento.

Crie um inventário das cargas de trabalho do AWS Lambda

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

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

Depois de criar seu inventário, recomendamos que você colete informações sobre cada carga de trabalho do AWS Lambda no inventário. Para cada carga de trabalho, concentre-se nos aspectos que ajudam a antecipar possíveis atritos. Além disso, analise essa carga de trabalho para entender como você pode precisar modificá-la e suas dependências 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 do código-fonte
  • Os artefatos de implantação
  • Invocação, gatilhos e saídas
  • Os ambientes de execução e de execução
  • A configuração da carga de trabalho
  • Os controles de acesso e as permissões
  • Os requisitos regulatórios e de compliance
  • Os processos operacionais e de implantação

Caso de uso e design

A coleta de 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 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:

  • Tenha insights sobre o caso de uso específico que a carga de trabalho atende e identifique quaisquer dependências com outros sistemas, recursos ou processos.
  • Analisar o design e a arquitetura da carga de trabalho.
  • Avaliar os requisitos de latência da carga de trabalho.

Repositório de códigos-fonte

Registrar 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. A criação desse inventário envolve o rastreamento da base do código, que normalmente é armazenada em sistemas de controle de versão, como o Git, ou em plataformas de desenvolvimento, como GitHub ou GitLab. O inventário do código-fonte é essencial para os processos de DevOps, como pipelines de integração contínua e desenvolvimento contínuo (CI/CD), porque esses processos também precisarão ser atualizados quando você migrar 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 para entender se você precisa 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 em que a carga de trabalho será implantada.
  • 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, gatilhos e saídas

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

  • Os acionadores e os mapeamentos de origem do evento que invocam a carga de trabalho.
  • Se a carga de trabalho oferece suporte a invocações síncronas e assíncronas.
  • URLs de carga de trabalho e endpoints HTTP(S).

As cargas de trabalho do AWS Lambda podem interagir com outros recursos e sistemas. Você precisa saber quais recursos consomem as saídas das cargas de trabalho do AWS Lambda e como esses recursos 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 processados pela carga de trabalho.
  • Como a carga de trabalho do AWS Lambda e as extensões interagem com as APIs do AWS Lambda ou outras APIs da AWS.

Para funcionar, as 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 persistentes, por exemplo, usando o armazenamento de dados efêmero e o Amazon Elastic File System (EFS).

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

O AWS Lambda oferece suporte a 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.
  • 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.
  • Qualquer modificação aplicada ao ambiente de execução.

Configuração da carga de trabalho

Para configurar as cargas de trabalho à medida que elas são migradas 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, colete 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 de quantidade de memória disponível e o tempo máximo de execução permitido.
  • Se a carga de trabalho está usando o AWS Lambda SnapStart, simultaneidade reservada ou simultaneidade provisionada para reduzir a latência.
  • As variáveis de ambiente que você configurou, bem como as que o AWS Lambda configura e a carga de trabalho delas.
  • As tags e o controle de acesso baseado em atributos.
  • A máquina de estado para lidar com condições excepcionais.
  • as imagens 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 controle 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 de execução e as permissões.
  • A configuração do gerenciamento de identidade e acesso que a carga de trabalho e as camadas dela 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, certifique-se de entender os requisitos regulatórios e de conformidade fazendo o seguinte:

  • Avalie todos os requisitos regulatórios e de conformidade que a carga de trabalho precisa atender.
  • Determine se a carga de trabalho atende a esses requisitos.
  • Determine se há requisitos futuros que precisarão ser atendidos.

Os requisitos regulatórios e de conformidade podem ser independentes do provedor de nuvem que você está usando e também podem ter um impacto na migração. Por exemplo, pode ser necessário garantir que o tráfego de dados e de rede permaneça 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ê está gerando esses artefatos ajuda a garantir que os artefatos gerados sejam adequados para implantação em Google Cloud.

  • Armazene os artefatos. Se você produzir artefatos armazenados em um Artifact Registry no ambiente de origem, precisará disponibilizar os artefatos no ambiente Google Cloud . Para fazer isso, use estratégias como as seguintes:

    • Estabelecer um canal de comunicação entre os ambientes: torne os artefatos no ambiente de origem acessíveis no ambiente Google Cloud de destino.
    • 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 criando infraestrutura como um repositório de artefatos antes que seja necessário implementar processos de build de artefatos no ambiente Google Cloudde 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 destino permite que você se concentre na migração sem precisar implementar processos de criação de artefato 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 seus processos de implantação sejam compatíveis com 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 funcionam apenas com o ambiente de origem, talvez seja necessário refatorá-los para de destino ao ambiente 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 no ambiente de execução funcionem em 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 as outras atividades da fase de avaliação, conforme descrito em Migrar para Google Cloud: avalie e descubra suas 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:

  • Ofereça suporte às cargas de trabalho no seu ambiente Google Cloud .
  • Conecte o ambiente de origem e o ambiente 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 Google Cloud: planejar e criar sua base.

Migre 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 o ambiente do Cloud Run.
  2. Se necessário, refatore as cargas de trabalho do AWS Lambda para torná-las compatíveis com o Cloud Run.
  3. Refatore seus processos operacionais e de implantação para implantar e observar suas cargas de trabalho no Cloud Run.
  4. Migre os dados necessários para as 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 os recursos do AWS Lambda em comparação com 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 as decisões de design e refatoração, conforme destacado nas seções a seguir.

Projetar, provisionar e configurar o ambiente do Cloud Run

A primeira etapa da fase de migração é projetar seu ambiente do Cloud Run para que ele seja compatível com as 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. Projetar a configuração dos recursos do Cloud Run.
  3. Provisionar e configurar 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 certo do Cloud Run 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 conteinerizado, 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 esses recursos principais do Cloud Run:

Recurso do AWS Lambda Recurso do Cloud Run
Função do AWS Lambda que é 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 que foi programada para execução, como as de tarefas em segundo plano e em lote. Job do Cloud Run executado até a conclusão.

Além dos serviços e jobs, o Cloud Run fornece outros recursos que estendem os 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, projete 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 gatilhos 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.

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

Acionadores de serviço e 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 fornece uma variedade de opções para acionar e executar as cargas de trabalho baseadas em eventos que são usadas no AWS Lambda. Além disso, o Cloud Run oferece opções para usar para streaming de cargas de trabalho e jobs programados.

Ao migrar suas cargas de trabalho, geralmente é útil entender primeiro quais gatilhos e mecanismos estão disponíveis no Cloud Run. Essas informações ajudam na sua compreensão de como o Cloud Run funciona. Em seguida, é possível usar esse entendimento para determinar quais recursos do Cloud Run são comparáveis aos recursos 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 ajudar você a 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 correto.

Recurso do AWS Lambda Recurso do Cloud Run
Acionador de HTTPS (URLs de função) Invocação de HTTPS
Gatilho HTTP/2 (parcialmente compatível com o uso de um gateway de API externo) Invocação HTTP/2 (com suporte nativo)
WebSockets (com suporte ao uso de gateway de API externo) WebSockets (com suporte nativo)
N/A (conexões gRPC não são compatíveis) Conexões gRPC
Invocação assíncrona Integração com o Cloud Tasks
Invocação programada Integração com o Cloud Scheduler
Acionador baseado em eventos em um formato de evento reservado Invocação baseada em eventos no formato CloudEvents
Integração do Amazon SQS e do Amazon SNS Integração do Pub/Sub
Funções de etapa do AWS Lambda Integração com fluxos de trabalho
Configuração de recursos do Cloud Run

Para complementar as decisões de design que você tomou para acionar e executar as cargas de trabalho migradas, o Cloud Run é compatível com 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, é possível entender melhor como o Cloud Run funciona. Para isso, primeiro é preciso compreender todas as opções de configuração disponíveis no Cloud Run. Esse entendimento ajuda você a comparar os recursos do AWS Lambda com os recursos semelhantes do Cloud Run e a determinar como refatorar as cargas de trabalho.

Para saber mais sobre as configurações fornecidas pelos serviços do Cloud Run, 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/A (incompatí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 de 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
SnapStart do AWS Lambda 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
As montagens de volume do S3 não são compatíveis Montagens de volume do Cloud Storage
AWS Secrets Manager em cargas de trabalho do AWS Lambda Secrets
URLs de carga de trabalho e endpoints HTTP(S) URLs atribuídos automaticamente
Integrações do Cloud Run com Google Cloud produtos
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 também 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 exibir. 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 reduzir significativamente os custos, já que a CPU e a memória da instância são compartilhadas pelas solicitações simultâneas, mas elas são faturadas apenas 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 as cargas de trabalho migradas. O Cloud Run é compatível com várias opções de configuração para ajudar a proteger o ambiente e definir papéis e permissões para as 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 funcionarão 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 fornecidos pelo Cloud Run, use os seguintes recursos:

Para 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 os recursos de segurança corretos.

Recurso do AWS Lambda Recurso do Cloud Run
Controle de acesso com acesso e gerenciamento de identidade da AWS Controle de acesso com o IAM de Google Cloud
Papel de execução Papel do IAM deGoogle Cloud
Limites de permissão Permissões do IAM e públicos-alvo personalizados deGoogle Cloud
Controles de governança Organization Policy Service
Assinatura de código Autorização binária
Acesso total à VPC Controles de acesso granulares 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:

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 contêm 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 os seguintes:

  • Arquitetura. Considere como a carga de trabalho foi projetada em termos de arquitetura. Por exemplo, as 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 as cargas de trabalho em que as duas lógicas sã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 as 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 as 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 suposições sobre o ambiente de execução. Para esses tipos de cargas de trabalho, talvez seja necessário atender às mesmas suposiçõ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, será necessário instalá-los no ambiente de execução do Cloud Run que hospedará essa carga de trabalho.
  • Injeção de configuração. Considere se a carga de trabalho é compatível com o uso de variáveis de ambiente e secrets para injetar (definir) a configuração. Uma carga de trabalho compatível com esse tipo de injeção pode exigir menos refatoração em comparação com cargas de trabalho compatíveis com 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 as APIs do Cloud Run.
  • Error Reporting. Considere se a carga de trabalho informa erros usando a saída padrão e os fluxos de erros. Uma carga de trabalho que realiza esse relatório de erros pode exigir menos refatoração em comparação com cargas de trabalho que relatam 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 seu ambiente 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 pretende projetar e implementar processos semelhantes em Google Cloud. Por exemplo, é possível refatorar esses processos para usar o Cloud Build, o Cloud Deploy e o Gerenciador de infraestrutura.
  • Talvez você tenha implementado esses processos em outro ambiente de terceiros fora do ambiente de origem. Nesse caso, é necessário refatorar esses processos para visar o ambiente 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 as cargas de trabalho no ambiente Google Cloud de destino. Por exemplo, é possível começar implantando um pequeno subconjunto das cargas de trabalho em Google Cloud, usando artefatos armazenados no Artifact Registry. Em seguida, você aumenta gradualmente o número de cargas de trabalho implantadas em Google Cloud, até 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 eventuais reversões devido a problemas imprevistos durante a migração, é possível armazenar imagens de contêiner nos repositórios de artefatos atuais em Google Cloud enquanto a migração para Google Cloud está em andamento. Por fim, como parte da desativação do ambiente de origem, é possível refatorar os processos de criação da imagem do contêiner para armazenar artefatos somente emGoogle Cloud .

Embora isso possa não ser essencial para o sucesso de uma migração, talvez seja necessário migrar suas versões anteriores dos artefatos do ambiente de origem para os repositórios de artefatos em 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 o ambiente do Cloud Run de maneira constante e eficaz.

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 executar 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 terá uma compreensão do tamanho e da complexidade dos dados. Se você estima que precisará de um esforço substancial para migrar esses dados, recomendamos que considere a migração de dados como parte de um projeto separado e dedicado.

Validar os resultados da migração

A validação da migração de cargas de trabalho não é um evento único, mas um processo contínuo. Você precisa manter o foco no teste e na validação antes, durante e depois de migrar do AWS Lambda para o Cloud Run.

Para ajudar a 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 do teste em cada marco de migração e realize testes de integração completos.
  • Após as migrações, faça os seguintes testes:
    • Teste de referência: 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 apontar para problemas de migração ou configuração.
    • Teste funcional: garanta que a lógica principal das suas cargas de trabalho permaneça consistente. Para isso, crie e execute casos de teste que abordem vários cenários de entrada e saída esperados em ambos os 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 perfeita, resolva discrepâncias como erros e limitações de recursos.

Otimize seu Google Cloud ambiente

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 seu Google Cloud ambiente, consulte Migrar para Google Cloud: otimizar seu ambiente e Google Cloud Framework bem arquitetado: otimização de desempenho.

A seguir

Colaboradores

Autores:

Outros colaboradores: