Migre do AWS para Google Cloud: migre do AWS Lambda para o Cloud Run

Last reviewed 2024-10-21 UTC

Google Cloud oferece ferramentas, produtos, orientações e serviços profissionais para ajudar na migração de cargas de trabalho sem servidor do Amazon Web Services (AWS) Lambda para Google Cloud. Embora a Google Cloud ofereça vários serviços nos quais pode desenvolver e implementar aplicações sem servidor, este documento centra-se na migração para o Cloud Run, um ambiente de tempo de execução sem servidor. O AWS Lambda e o Cloud Run partilham semelhanças, como o aprovisionamento automático de recursos, o escalamento pelo fornecedor de nuvem e um modelo de preços de pagamento por utilização.

Este documento ajuda a conceber, implementar e validar um plano para migrar cargas de trabalho sem servidor do AWS Lambda para o Cloud Run. Além disso, oferece orientações para quem está a avaliar as potenciais vantagens e o processo de tal migração.

Este documento faz parte de uma série de vários artigos sobre a migração da AWS para a Google Cloud , que inclui os seguintes documentos:

Para mais informações sobre como escolher o ambiente de tempo de execução sem servidor certo para a lógica empresarial, consulte o artigo Selecione um ambiente de tempo de execução de contentores gerido. Para uma associação abrangente entre os serviços da AWS e os serviços da Google Cloud Google, consulte o artigo Compare os serviços da AWS e do Azure aos serviços da Google Cloud Google.

Para esta migração para Google Cloud, recomendamos que siga a estrutura de migração descrita no artigo Migrar para Google Cloud: introdução.

O diagrama seguinte ilustra o caminho do seu percurso de migração.

Caminho de migração com quatro fases.

Pode migrar do ambiente de origem para o ambiente de destino Google Cloud numa série de iterações. Por exemplo, pode migrar algumas cargas de trabalho primeiro e outras mais tarde. Para cada iteração de migração separada, segue as fases da estrutura de migração geral:

  1. Avalie e descubra as suas cargas de trabalho e dados.
  2. Planeie e crie uma base em Google Cloud.
  3. Migre as suas cargas de trabalho e dados para o Google Cloud.
  4. Otimize o seu Google Cloud ambiente.

Para mais informações sobre as fases desta estrutura, consulte o artigo Migre para Google Cloud: comece.

Para criar um plano de migração eficaz, recomendamos que valide cada passo do plano e se certifique de que tem uma estratégia de reversão. Para ajudar a validar o seu plano de migração, consulte o artigo Migre para Google Cloud: práticas recomendadas para validar um plano de migração.

A migração de cargas de trabalho sem servidor vai muito além da simples transferência de funções de um fornecedor de nuvem para outro. Uma vez que as aplicações baseadas na nuvem dependem de uma rede interligada de serviços, a migração do AWS para o Google Cloud pode exigir a substituição dos serviços AWS dependentes por serviços Google Cloud . Por exemplo, considere um cenário em que a sua função Lambda interage com o Amazon SQS e o Amazon SNS. Para migrar esta função, é provável que tenha de adotar o Pub/Sub e o Cloud Tasks para alcançar uma funcionalidade semelhante.

A migração também representa uma oportunidade valiosa para rever minuciosamente a arquitetura e as decisões de design da sua aplicação sem servidor. Através desta revisão, pode descobrir oportunidades para fazer o seguinte:

  • Otimize com Google Cloud funcionalidades incorporadas: explore se os Google Cloud serviços oferecem vantagens únicas ou se se alinham melhor com os requisitos da sua aplicação.
  • Simplifique a sua arquitetura: avalie se é possível simplificar consolidando a funcionalidade ou usando os serviços de forma diferente no Google Cloud.
  • Melhore a rentabilidade: avalie as potenciais diferenças de custos da execução da sua aplicação refatorada na infraestrutura fornecida no Google Cloud.
  • Melhore a eficiência do código: refatore o código juntamente com o processo de migração.

Planeie a migração de forma estratégica. Não veja a migração como um exercício de rehost (lift and shift). Use a migração como uma oportunidade para melhorar o design geral e a qualidade do código da sua aplicação sem servidor.

Avalie o ambiente de origem

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

A fase de avaliação é fundamental para o sucesso da sua migração. Tem de adquirir conhecimentos profundos sobre as cargas de trabalho que quer migrar, os respetivos requisitos, as respetivas dependências e o seu ambiente atual. Tem de compreender o seu ponto de partida para planear e executar com êxito uma Google Cloud migração.

A fase de avaliação consiste nas seguintes tarefas:

  1. Crie um inventário abrangente das suas cargas de trabalho.
  2. Catalogue as suas cargas de trabalho de acordo com as respetivas propriedades e dependências.
  3. Forme e eduque as suas equipas sobre Google Cloud.
  4. Crie experiências e provas de conceito em Google Cloud.
  5. Calcular o custo total de propriedade (TCO) do ambiente de destino.
  6. Escolha a estratégia de migração para as suas cargas de trabalho.
  7. Escolha as ferramentas de migração.
  8. Defina o plano de migração e a linha cronológica.
  9. Valide o seu plano de migração.

Para mais informações sobre a fase de avaliação e estas tarefas, consulte o artigo Migre para Google Cloud: avalie e descubra as suas cargas de trabalho. As secções seguintes baseiam-se nas informações desse documento.

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

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

Para criar o inventário das suas cargas de trabalho do AWS Lambda, recomendamos que implemente um mecanismo de recolha de dados com base nas APIs AWS, nas ferramentas para programadores da AWS e na interface de linha de comandos da AWS.

Depois de criar o inventário, recomendamos que recolha informações sobre cada carga de trabalho do AWS Lambda no inventário. Para cada carga de trabalho, foque-se nos aspetos que ajudam a antecipar potenciais atritos. Além disso, analise essa carga de trabalho para compreender como pode ter de modificar a carga de trabalho e as respetivas dependências antes de migrar para o Cloud Run. Recomendamos que comece por recolher dados sobre os seguintes aspetos de cada carga de trabalho do AWS Lambda:

  • O exemplo de utilização e o design
  • O repositório de código-fonte
  • Os artefactos de implementação
  • A invocação, os acionadores e os resultados
  • Os ambientes de execução e de tempo de execução
  • A configuração da carga de trabalho
  • Os controlos de acesso e as autorizações
  • Os requisitos regulamentares e de conformidade
  • Os processos de implementação e operacionais

Exemplo de utilização e design

A recolha de informações sobre o exemplo de utilização e a conceção das cargas de trabalho ajuda a identificar uma estratégia de migração adequada. Estas informações também ajudam a compreender se precisa de modificar as cargas de trabalho e as respetivas dependências antes da migração. Para cada carga de trabalho, recomendamos que faça o seguinte:

  • Obter estatísticas sobre o exemplo de utilização específico que a carga de trabalho serve e identificar quaisquer 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ódigo-fonte

Inventariar o código-fonte das suas funções do AWS Lambda ajuda se precisar de refatorar as suas cargas de trabalho do AWS Lambda para compatibilidade com o Cloud Run. A criação deste inventário envolve o acompanhamento da base de código, que normalmente é armazenada em sistemas de controlo 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 a integração contínua e os pipelines de desenvolvimento contínuo (CI/CD), porque estes processos também têm de ser atualizados quando migra para o Cloud Run.

Artefactos de implementação

Saber que artefactos de implementação são necessários para a carga de trabalho é outro componente que ajuda a compreender se pode ter de refatorizar as suas cargas de trabalho do AWS Lambda. Para identificar os artefactos de implementação de que a carga de trabalho precisa, recolha as seguintes informações:

  • O tipo de pacote de implementação para implementar 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 das quais a carga de trabalho depende.
  • Os qualificadores que configurou para especificar versões e alias.
  • A versão da carga de trabalho implementada.

Invocação, acionadores e resultados

O AWS Lambda suporta vários mecanismos de invocação, como acionadores, e diferentes modelos de invocação, como a invocação síncrona e a invocação assíncrona. Para cada carga de trabalho do AWS Lambda, recomendamos que recolha as seguintes informações relacionadas com acionadores e invocações:

  • Os acionadores e os mapeamentos de origens de eventos que invocam a carga de trabalho.
  • Indica se a carga de trabalho suporta invocações síncronas e assíncronas.
  • Os URLs da carga de trabalho e os pontos finais HTTP(S).

As suas cargas de trabalho do AWS Lambda podem interagir com outros recursos e sistemas. Tem de saber que recursos consomem os resultados das suas cargas de trabalho do AWS Lambda e como esses recursos consomem esses resultados. Estes conhecimentos ajudam a determinar se tem de modificar algo que possa depender desses resultados, como outros sistemas ou cargas de trabalho. Para cada carga de trabalho do AWS Lambda, recomendamos que recolha 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 registos de informações para invocações assíncronas.
  • O formato dos eventos que a carga de trabalho processa.
  • Como a sua carga de trabalho do AWS Lambda e as respetivas extensões interagem com as APIs do AWS Lambda ou outras APIs da AWS.

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

  • Se a carga de trabalho acede a nuvens privadas virtuais (VPCs) ou a outras redes privadas.
  • Como a carga de trabalho armazena dados persistentes, por exemplo, através do armazenamento de dados efémeros e do Amazon Elastic File System (EFS).

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

O AWS Lambda suporta vários ambientes de execução para as 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 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 no qual a carga de trabalho é executada.

Se as suas cargas de trabalho do AWS Lambda forem executadas em ambientes de tempo de execução específicos do idioma, 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 do idioma.
  • Todas as modificações que aplicou ao ambiente de tempo de execução.

Configuração da carga de trabalho

Para configurar as suas cargas de trabalho à medida que as migra do AWS Lambda para o Cloud Run, recomendamos que avalie como configurou cada carga de trabalho do AWS Lambda.

Para cada carga de trabalho do AWS Lambda, recolha informações sobre as seguintes definições de simultaneidade e escalabilidade:

  • Os controlos de simultaneidade.
  • As definições de escalabilidade.
  • A configuração das instâncias da carga de trabalho, em termos da quantidade de memória disponível e do tempo de execução máximo permitido.
  • Se a carga de trabalho está a usar o AWS Lambda SnapStart, a concorrência reservada ou a concorrência aprovisionada para reduzir a latência.
  • As variáveis de ambiente que configurou, bem como as que o AWS Lambda configura e das quais a carga de trabalho depende.
  • As etiquetas e o controlo de acesso baseado em atributos.
  • A máquina de estados para processar condições excecionais.
  • As imagens de base e os ficheiros de configuração (como o Dockerfile) para pacotes de implementação que usam imagens de contentores.

Controlos de acesso e autorizações

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

  • A função de execução e as autorizações.
  • A configuração de gestão de identidades e acessos que a carga de trabalho e as respetivas camadas usam para aceder a outros recursos.
  • A configuração de gestão de identidade e acesso que outras contas e serviços usam para aceder à carga de trabalho.
  • Os controlos de governação.

Conformidade e requisitos regulamentares

Para cada carga de trabalho do AWS Lambda, certifique-se de que compreende os respetivos requisitos regulamentares e de conformidade fazendo o seguinte:

  • Avalie todos os requisitos regulamentares e de conformidade que a carga de trabalho tem de cumprir.
  • Determine se a carga de trabalho está atualmente a cumprir estes requisitos.
  • Determinar se existem requisitos futuros que têm de ser cumpridos.

Os requisitos regulamentares e de conformidade podem ser independentes do fornecedor de nuvem que está a usar, e estes requisitos também podem ter um impacto na migração. Por exemplo, pode ter de garantir que os dados e o tráfego de rede permanecem dentro dos limites de determinadas geografias, como a União Europeia (UE).

Avalie os seus processos de implementação e operacionais

É importante ter uma compreensão clara do funcionamento dos processos de implementação e operacionais. Estes processos são uma parte fundamental das práticas que preparam e mantêm o seu ambiente de produção e as cargas de trabalho que são executadas nesse ambiente.

Os seus processos de implementação e operacionais podem criar os artefactos de que as suas cargas de trabalho precisam para funcionar. Por conseguinte, deve recolher informações sobre cada tipo de artefacto. Por exemplo, um artefacto pode ser um pacote do sistema operativo, um pacote de implementação de aplicações, uma imagem do sistema operativo, uma imagem de contentor ou outra coisa.

Além do tipo de artefacto, considere como conclui as seguintes tarefas:

  • Desenvolva as suas cargas de trabalho. Avalie os processos que as equipas de desenvolvimento têm em vigor para criar as suas cargas de trabalho. Por exemplo, como é que as suas equipas de desenvolvimento estão a conceber, programar e testar as suas cargas de trabalho?
  • Gere os artefactos que implementa no seu ambiente de origem. Para implementar as suas cargas de trabalho no ambiente de origem, pode gerar artefactos implementáveis, como imagens de contentores ou imagens de sistemas operativos, ou pode personalizar artefactos existentes, como imagens de sistemas operativos de terceiros, instalando e configurando software. A recolha de informações sobre como está a gerar estes artefactos ajuda a garantir que os artefactos gerados são adequados para implementação noGoogle Cloud.

  • Armazenar os artefactos. Se produzir artefactos que armazena num registo de artefactos no seu ambiente de origem, tem de disponibilizar os artefactos no seu ambiente de destino. Google Cloud Pode fazê-lo através de estratégias como as seguintes:

    • Estabeleça um canal de comunicação entre os ambientes: torne os artefactos no ambiente de origem acessíveis a partir do ambiente de destinoGoogle Cloud .
    • Refatore o processo de criação de artefactos: conclua uma refatoração menor do seu ambiente de origem para que possa armazenar artefactos no ambiente de origem e no ambiente de destino. Esta abordagem suporta a sua migração através da criação de infraestrutura, como um repositório de artefactos, antes de ter de implementar processos de compilação de artefactos no ambiente de destino. Google CloudPode implementar esta abordagem diretamente ou basear-se na abordagem anterior de estabelecer primeiro um canal de comunicação.

    A disponibilidade de artefactos nos ambientes de origem e de destino permite-lhe concentrar-se na migração sem ter de implementar processos de criação de artefactos no ambiente de destino Google Cloud como parte da migração.

  • Leia e assine o código. Como parte dos processos de compilação de artefactos, pode estar a usar a análise de código para ajudar a proteger-se contra vulnerabilidades comuns e a exposição não intencional da rede, bem como a assinatura de código para ajudar a garantir que apenas o código fidedigno é executado nos seus ambientes.

  • Implemente artefactos no seu ambiente de origem. Depois de gerar artefactos implementáveis, pode implementá-los no seu ambiente de origem. Recomendamos que avalie cada processo de implementação. A avaliação ajuda a garantir que os seus processos de implementação são compatíveis com o Google Cloud. Também ajuda a compreender o esforço necessário para, eventualmente, refatorar os processos. Por exemplo, se os seus processos de implementação funcionarem apenas com o ambiente de origem, pode ter de refatorá-los para segmentar o ambiente de destino. Google Cloud

  • Injetar configuração de tempo de execução. Pode estar a injetar a configuração de tempo de execução para clusters, ambientes de tempo de execução ou implementações de cargas 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 ajudar a garantir que os processos de injeção de configuração de tempo de execução funcionam no Google Cloud, recomendamos que avalie como está a configurar as cargas de trabalho que são executadas no seu ambiente de origem.

  • Registo, monitorização e criação de perfis. Avalie os processos de registo, monitorização e criação de perfis que tem implementados para monitorizar o estado do ambiente de origem, as métricas de interesse e a forma como está a consumir os dados fornecidos por estes processos.

  • Autenticação. Avalie a forma como está a fazer a autenticação no seu ambiente de origem.

  • Aprovisione e configure os seus recursos. Para preparar o ambiente de origem, pode ter concebido e implementado processos que aprovisionam e configuram recursos. Por exemplo, pode estar a usar o Terraform juntamente com ferramentas de gestão de configuração para aprovisionar e configurar recursos no seu ambiente de origem.

Conclua a avaliação

Depois de criar os inventários a partir do seu ambiente AWS Lambda, conclua o resto das atividades da fase de avaliação, conforme descrito em Migrar para Google Cloud: avalie e descubra as suas cargas de trabalho.

Planeie e crie a sua base

Na fase de planeamento e criação, aprovisiona e configura a infraestrutura para fazer o seguinte:

  • Suporte as suas cargas de trabalho no seu Google Cloud ambiente.
  • Ligue o ambiente de origem e o ambiente Google Cloud para concluir a migração.

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

  1. Crie uma hierarquia de recursos.
  2. Configure Google Cloud's Identity and Access Management (IAM).
  3. Configure a faturação
  4. Configure a conetividade de rede.
  5. Reforce a sua segurança.
  6. Configure o registo, a monitorização e os alertas.

Para mais informações sobre cada uma destas tarefas, consulte o artigo Migre para o Google Cloud: planeie e crie a sua base.

Migre as suas cargas de trabalho do AWS Lambda

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

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

Para ajudar a evitar problemas durante a migração e a estimar o esforço necessário para a migração, recomendamos que avalie a comparação entre as funcionalidades do AWS Lambda e as funcionalidades semelhantes do Cloud Run. As funcionalidades do AWS Lambda e do Cloud Run podem parecer semelhantes quando as compara. No entanto, as diferenças na conceção e implementação das funcionalidades nos dois fornecedores de nuvem podem ter efeitos significativos na sua migração do AWS Lambda para o Cloud Run. Estas diferenças podem influenciar as suas decisões de design e refatoração, conforme realçado nas secções seguintes.

Crie, aprovisione e configure o seu ambiente do Cloud Run

O primeiro passo da fase de migração é criar o seu ambiente do Cloud Run para que possa suportar as cargas de trabalho que está a migrar do AWS Lambda.

Para conceber corretamente o seu ambiente do Cloud Run, use os dados que recolheu durante a fase de avaliação sobre cada carga de trabalho do AWS Lambda. Estes dados ajudam a fazer o seguinte:

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

Escolha os recursos do Cloud Run certos

Para cada carga de trabalho do AWS Lambda a migrar, escolha o recurso do Cloud Run certo para implementar as suas cargas de trabalho. O Cloud Run suporta os seguintes recursos principais:

  • Serviços do Cloud Run: um recurso que aloja um ambiente de runtime em contentores, expõe um ponto final único e dimensiona automaticamente a infraestrutura subjacente de acordo com a procura.
  • Tarefas do Cloud Run: um recurso que executa um ou mais contentores até à conclusão.

A tabela seguinte resume como os recursos do AWS Lambda são mapeados para estes 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 Websites e aplicações Web, APIs e microsserviços, processamento de dados de streaming e arquiteturas orientadas por eventos. Serviço do Cloud Run que pode invocar com acionadores.
Função AWS Lambda agendada para execução, como as funções para tarefas em segundo plano e tarefas em lote. Tarefa do Cloud Run que é executada até à conclusão.

Além dos serviços e das tarefas, o Cloud Run oferece recursos adicionais que expandem estes recursos principais. Para mais informações sobre todos os recursos do Cloud Run disponíveis, consulte o modelo de recursos do Cloud Run.

Crie a configuração dos recursos do Cloud Run

Antes de aprovisionar e configurar os recursos do Cloud Run, planeie a respetiva configuração. Determinadas opções de configuração do AWS Lambda, como limites de recursos e limites de tempo de pedido, são comparáveis a opções de configuração do Cloud Run semelhantes. As secções seguintes descrevem as opções de configuração disponíveis no Cloud Run para acionadores de serviços e execução de tarefas, configuração de recursos e segurança. Estas secções também realçam as opções de configuração do AWS Lambda que são comparáveis às do Cloud Run.

Acionadores de serviços do Cloud Run e execução de tarefas

Os acionadores de serviços e a execução de tarefas são as principais decisões de design que tem de considerar quando migra as 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 que são usadas no AWS Lambda. Além disso, o Cloud Run oferece opções que pode usar para cargas de trabalho de streaming e tarefas agendadas.

Quando migra os seus fluxos de trabalho, é frequentemente útil compreender primeiro que acionadores e mecanismos estão disponíveis no Cloud Run. Estas informações ajudam a compreender como funciona o Cloud Run. Em seguida, pode usar esta compreensão para determinar que funcionalidades do Cloud Run são comparáveis às funcionalidades do AWS Lambda e que funcionalidades do Cloud Run podem ser usadas ao refatorar essas cargas de trabalho.

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

Para saber mais sobre os mecanismos de execução de tarefas que o Cloud Run oferece, use os seguintes recursos:

Para ajudar a compreender que 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 seguinte. Para cada recurso do Cloud Run que precisa de aprovisionar, certifique-se de que escolhe o mecanismo de invocação ou execução correto.

Funcionalidade do AWS Lambda Funcionalidade do Cloud Run
Acionador HTTPS (URLs de funções) Invocações HTTPS
Acionador HTTP/2 (parcialmente suportado através de um gateway de API externo) Invocações HTTP/2 (suportadas nativamente)
WebSockets (suportados através do gateway da API externo) WebSockets (suportados nativamente)
N/A (ligações gRPC não suportadas) Ligações gRPC
Invocação assíncrona Integração do Cloud Tasks
Invocação agendada Integração do Cloud Scheduler
Acionador baseado em eventos num formato de evento proprietário Invocações baseadas em eventos no formato CloudEvents
Integração do Amazon SQS e Amazon SNS Integração do Pub/Sub
Funções escalonadas do AWS Lambda Integração de fluxos de trabalho
Configuração de recursos do Cloud Run

Para complementar as decisões de design que tomou para acionar e executar as cargas de trabalho migradas, o Cloud Run suporta várias opções de configuração que lhe permitem ajustar vários aspetos do ambiente de tempo de execução. Estas opções de configuração consistem em serviços de recursos e tarefas.

Como mencionado anteriormente, pode compreender melhor o funcionamento do Cloud Run desenvolvendo primeiro uma compreensão de todas as opções de configuração disponíveis no Cloud Run. Esta compreensão ajuda a comparar as funcionalidades do AWS Lambda com funcionalidades semelhantes do Cloud Run e a determinar como refatorar as 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 as tarefas que o Cloud Run oferece, use os seguintes recursos:

Para ajudar a compreender que opções de configuração do Cloud Run são comparáveis às opções de configuração do AWS Lambda, use a tabela seguinte. Para cada recurso do Cloud Run que precisa de aprovisionar, certifique-se de que escolhe as opções de configuração corretas.

Funcionalidade do AWS Lambda Funcionalidade do Cloud Run
Simultaneidade aprovisionada Instâncias mínimas
Concorrência reservada por instância
(O conjunto de concorrência é partilhado entre as funções do AWS Lambda na sua conta da AWS.)		 Máximo de instâncias por serviço
N/A (não suportado, um pedido é mapeado para uma instância) Pedidos simultâneos por instância
N/A (depende da atribuição de memória) Atribuição de CPU
Definições de escalabilidade Dimensionamento automático de instâncias para serviços
Paralelismo para tarefas
Configuração da instância (CPU, memória) Limites de CPU e memória
Tempo de execução máximo Tempo limite de pedido para serviços
Tempo limite de tarefas para empregos
AWS Lambda SnapStart Aumento da CPU no arranque
Variáveis de ambiente Variáveis de ambiente
Armazenamento de dados temporário Montagens de volumes na memória
Ligações do Amazon Elastic File System Montagens de volumes NFS
As montagens de volume S3 não são suportadas Montagens de volumes do Cloud Storage
AWS Secrets Manager em cargas de trabalho do AWS Lambda Secrets
URLs de cargas de trabalho e pontos finais HTTP(S) URLs atribuídos automaticamente
Integrações do Cloud Run com Google Cloud produtos
Sessões persistentes (com um balanceador de carga externo) Afinidade de sessão
Qualificadores Revisões

Além das funcionalidades indicadas na tabela anterior, também deve considerar as diferenças entre a forma como o AWS Lambda e o Cloud Run aprovisionam instâncias do ambiente de execução. O AWS Lambda aprovisiona uma única instância para cada pedido concorrente. No entanto, o Cloud Run permite-lhe definir o número de pedidos simultâneos que uma instância pode publicar. Ou seja, o comportamento de aprovisionamento do AWS Lambda é equivalente a definir o número máximo de pedidos simultâneos por instância como 1 no Cloud Run. Definir o número máximo de pedidos simultâneos para mais de 1 pode poupar significativamente custos, porque a CPU e a memória da instância são partilhadas pelos pedidos simultâneos, mas só são faturadas uma vez. A maioria das frameworks HTTP foi concebida para processar pedidos em paralelo.

Segurança e controlo de acesso do Cloud Run

Quando cria os seus recursos do Cloud Run, também tem de decidir os controlos de segurança e de acesso de que precisa para as suas cargas de trabalho migradas. O Cloud Run suporta várias opções de configuração para ajudar a proteger o seu ambiente, e para definir funções e autorizações para as suas cargas de trabalho do Cloud Run.

Esta secção realça os controlos de segurança e acesso disponíveis no Cloud Run. Estas informações ajudam a compreender como as cargas de trabalho migradas vão funcionar no Cloud Run e a identificar as opções do Cloud Run de que pode precisar se refatorar essas cargas de trabalho.

Para saber mais acerca dos mecanismos de autenticação que o Cloud Run oferece, use os seguintes recursos:

Para saber mais sobre as funcionalidades de segurança que o Cloud Run oferece, use os seguintes recursos:

Para ajudar a compreender que controlos de segurança e acesso do Cloud Run são comparáveis aos disponíveis no AWS Lambda, use a tabela seguinte. Para cada recurso do Cloud Run que precisa de aprovisionar, certifique-se de que escolhe os controlos de acesso e as funcionalidades de segurança adequados.

Funcionalidade do AWS Lambda Funcionalidade do Cloud Run
Controlo de acesso com a gestão de identidade e acesso da AWS Controlo de acesso com o IAM do Google Cloud
Função de execução Google Cloud's função de IAM
Limites de autorizações Autorizações de IAM doGoogle Cloude públicos-alvo personalizados
Controlos de governação Serviço de políticas da organização
Assinatura de código Autorização binária
Acesso total à VPC Controlos de acesso de saída da VPC detalhados

Aprovisione e configure recursos do Cloud Run

Depois de escolher os recursos do Cloud Run para implementar as suas cargas de trabalho, aprovisiona e configura esses recursos. Para mais informações sobre o aprovisionamento de recursos do Cloud Run, consulte o seguinte:

Refatore cargas de trabalho do AWS Lambda

Para migrar as suas cargas de trabalho do AWS Lambda para o Cloud Run, pode ter de as refatorar. Por exemplo, se uma carga de trabalho baseada em eventos aceitar acionadores que contenham eventos do Amazon CloudWatch, pode ter de refatorar essa carga de trabalho para que aceite eventos no formato CloudEvents.

Existem 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 é concebida em termos de arquitetura. Por exemplo, as cargas de trabalho do AWS Lambda que tenham separado claramente a lógica empresarial da lógica de acesso às APIs específicas da AWS podem exigir menos refatoração em comparação com as cargas de trabalho em que as duas lógicas estão misturadas.
  • Idempotência. Considere se a carga de trabalho é idempotente relativamente às respetivas entradas. Uma carga de trabalho idempotente para entradas pode exigir menos refatoração em comparação com cargas de trabalho que precisam de manter o estado sobre as entradas que já processaram.
  • 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 suportados pelo Cloud Run para armazenar dados, consulte as opções de armazenamento do Cloud Run.
  • Ambiente de tempo de execução. Considere se a carga de trabalho faz pressupostos sobre o respetivo ambiente de tempo de execução. Para estes tipos de cargas de trabalho, pode ter de satisfazer as mesmas suposições no ambiente de execução do Cloud Run ou refatorar a carga de trabalho se não puder assumir 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, tem de instalá-los no ambiente de execução do Cloud Run que vai alojar essa carga de trabalho.
  • Injeção de configuração. Considere se a carga de trabalho suporta a utilização de variáveis de ambiente e segredos para injetar (definir) a respetiva configuração. Uma carga de trabalho que suporte este tipo de injeção pode exigir menos refatoração em comparação com cargas de trabalho que suportam outros mecanismos de injeção de configuração.
  • APIs. Considere se a carga de trabalho interage com as APIs AWS Lambda. Uma carga de trabalho que interage com estas APIs pode ter de ser refatorada para usar as APIs Cloud e as APIs Cloud Run.
  • Relatórios de erros. Considere se a carga de trabalho comunica erros através de streams de saída e erro padrão. Uma carga de trabalho que faça este tipo de relatório de erros pode exigir menos refatoração em comparação com cargas de trabalho que comunicam erros através de outros mecanismos.

Para mais informações sobre o desenvolvimento e a otimização de cargas de trabalho do Cloud Run, consulte os seguintes recursos:

Refatore os processos de implementação e operacionais

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

  • Aprovisione e configure recursos no seu Google Cloud ambiente em vez de aprovisionar recursos no seu ambiente de origem.
  • Crie e configure cargas de trabalho e implemente-as no Google Cloud em vez de as implementar no seu ambiente de origem.

Recolheu informações sobre estes processos durante a fase de avaliação anteriormente neste processo.

O tipo de refatoração que tem de considerar para estes processos depende de como os concebeu e implementou. A refatoração também depende do estado final que quer para cada processo. Por exemplo, considere o seguinte:

  • Pode ter implementado estes processos no seu ambiente de origem e pretender criar e implementar processos semelhantes no Google Cloud. Por exemplo, pode refatorar estes processos para usar o Cloud Build, o Cloud Deploy e o Infrastructure Manager.
  • Pode ter implementado estes processos noutro ambiente de terceiros fora do seu ambiente de origem. Neste caso, tem de refatorar estes processos para segmentar o seu ambiente Google Cloud em vez do ambiente de origem.
  • Uma combinação das abordagens anteriores.

A refatoração dos processos de implementação e operacionais pode ser complexa e exigir um esforço significativo. Se tentar realizar estas tarefas como parte da migração da carga de trabalho, a migração da carga de trabalho pode tornar-se mais complexa e expô-lo a riscos. Depois de avaliar a implementação e os processos operacionais, é provável que compreenda o respetivo design e complexidade. Se estimar que precisa de um esforço substancial para refatorar a implementação e os processos operacionais, recomendamos que considere refatorar estes processos como parte de um projeto separado e dedicado.

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

Este documento centra-se nos processos de implementação que produzem os artefactos a implementar e implementam-nos no ambiente de tempo de execução de destino. A estratégia de refatoração depende muito da complexidade destes processos. A lista seguinte descreve uma possível estratégia de refatoração geral:

  1. Aprovisione repositórios de artefactos em Google Cloud. Por exemplo, pode usar o Artifact Registry para armazenar artefactos e criar dependências.
  2. Refatore os processos de compilação para armazenar artefactos no ambiente de origem e no Artifact Registry.
  3. Refatore os processos de implementação para implementar as cargas de trabalho no ambiente de destinoGoogle Cloud . Por exemplo, pode começar por implementar um pequeno subconjunto das suas cargas de trabalho no Google Cloud, usando artefactos armazenados no Artifact Registry. Em seguida, aumenta gradualmente o número de cargas de trabalho implementadas em Google Cloudaté que todas as cargas de trabalho a migrar sejam executadas emGoogle Cloud.
  4. Refatore os processos de compilação para armazenar artefactos apenas no Artifact Registry.
  5. Se necessário, migre versões anteriores dos artefactos para implementação a partir dos repositórios no ambiente de origem para o Artifact Registry. Por exemplo, pode copiar imagens de contentores para o Artifact Registry.
  6. Desative os repositórios no seu ambiente de origem quando já não precisar deles.

Para facilitar as reversões eventuais devido a problemas inesperados durante a migração, pode armazenar imagens de contentores nos seus repositórios de artefactos atuais enquanto a migração para o Google Container Registry estiver em curso. Google Cloud Google Cloud Por último, como parte da desativação do ambiente de origem, pode refatorar os processos de criação de imagens de contentores para armazenar artefactosGoogle Cloud apenas.

Embora possa não ser crucial para o sucesso de uma migração, pode ter de migrar as versões anteriores dos seus artefactos do ambiente de origem para os repositórios de artefactos no Google Cloud. Por exemplo, para suportar a reversão das suas cargas de trabalho para pontos arbitrários no tempo, pode ter de migrar versões anteriores dos seus artefactos para o Artifact Registry. Para mais informações, consulte Migre imagens de um registo de terceiros.

Se estiver a usar o Artifact Registry para armazenar os seus artefactos, recomendamos que configure controlos para ajudar a proteger os seus repositórios de artefactos, como o controlo de acesso, a prevenção de exfiltração de dados, a análise de vulnerabilidades e a autorização binária. Para mais informações, consulte o artigo Controle o acesso e proteja os artefactos.

Refatorar processos operacionais

Como parte da migração para o Cloud Run, recomendamos que refatore os seus processos operacionais para monitorizar constante e eficazmente o seu ambiente do Cloud Run.

O Cloud Run integra-se com os seguintes serviços operacionais:

Migre dados

A fase de avaliação anterior neste processo deve ter ajudado a determinar se as cargas de trabalho do AWS Lambda que está a migrar dependem ou produzem dados que residem no seu ambiente da AWS. Por exemplo, pode ter determinado que precisa de 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 a migração de dados da AWS para o Google Cloud, consulte o artigo Migre da AWS para o Google Cloud: comece já.

Tal como acontece com a refatoração dos processos de implementação e operacionais, a migração de dados da AWS para o Google Cloud pode ser complexa e exigir um esforço significativo. Se tentar realizar estas tarefas de migração de dados como parte da migração das suas cargas de trabalho do AWS Lambda, a migração pode tornar-se complexa e expô-lo a riscos. Depois de analisar os dados a migrar, é provável que tenha uma compreensão do tamanho e da complexidade dos dados. Se estimar que precisa de um esforço substancial para migrar estes dados, recomendamos que considere migrar os dados como parte de um projeto separado e dedicado.

Valide os resultados da migração

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

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

  • Antes de iniciar a fase de migração, refatore os seus exemplos de teste existentes para ter em conta o Google Cloud ambiente de destino.
  • Durante a migração, valide os resultados dos testes em cada marco da migração e realize testes de integração exaustivos.
  • Após as migrações, faça os seguintes testes:
    • Testes de base: estabeleça referências de desempenho da carga de trabalho original no AWS Lambda, como o tempo de execução, a utilização de recursos e as taxas de erro em diferentes cargas. Replique estes testes no Cloud Run para identificar discrepâncias que possam indicar problemas de migração ou configuração.
    • Testes funcionais: certifique-se de que a lógica essencial das suas cargas de trabalho permanece consistente criando e executando exemplos de testes que abrangem vários cenários de entrada e saída esperados em ambos os ambientes.
    • Testes de carga: aumente gradualmente o tráfego para avaliar o desempenho e a escalabilidade do Cloud Run em condições reais. Para ajudar a garantir uma migração perfeita, resolva as discrepâncias, como erros e limitações de recursos.

Otimize o seu Google Cloud ambiente

A otimização é a última fase da migração. Nesta fase, itera nas tarefas de otimização até que o ambiente de destino cumpra os requisitos de otimização. Os passos de cada iteração são os seguintes:

  1. Avalie o seu ambiente, equipas e ciclo de otimização atuais.
  2. Estabeleça os seus requisitos e objetivos de otimização.
  3. Otimize o seu ambiente e as suas equipas.
  4. Ajuste o ciclo de otimização.

Repete esta sequência até atingir os seus objetivos de otimização.

Para mais informações sobre a otimização do seu Google Cloud ambiente, consulte Migrar para Google Cloud: otimize o seu ambiente e Google Cloud Framework bem arquitetado: otimização do desempenho.

O que se segue?

Colaboradores

Autores:

Outros colaboradores: