OGoogle Cloud oferece ferramentas, produtos, orientações e serviços profissionais para ajudar na migração de cargas de trabalho sem servidor do Lambda da Amazon Web Services (AWS) para o Google Cloud. Embora o Google Cloud forneça vários serviços em que você pode desenvolver e implantar aplicativos sem servidor, este documento se concentra na migração para o Cloud Run, um ambiente de execução sem servidor. A 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.
Este documento ajuda você a projetar, implementar e validar um plano para migrar cargas de trabalho sem servidor da AWS Lambda para o Cloud Run. Além disso, oferece orientação para quem está avaliando os possíveis benefícios e o processo dessa migração.
Este documento faz parte de uma série com várias partes sobre a migração da AWS para Google Cloud que inclui os seguintes documentos:
- Primeiros passos
- Migrar do Amazon EC2 para o Compute Engine
- Migrar do Amazon S3 para o Cloud Storage
- Migrar do Amazon EKS para o Google Kubernetes Engine
- Migrar do Amazon RDS e do Amazon Aurora para MySQL para o Cloud SQL para MySQL
- Migrar do Amazon RDS e do Amazon Aurora para PostgreSQL para o Cloud SQL para PostgreSQL e o AlloyDB para PostgreSQL
- Migrar do Amazon RDS para SQL Server para o Cloud SQL para SQL Server
- Migrar do AWS Lambda para o Cloud Run (este documento)
Para mais informações sobre como escolher o ambiente de execução serverless 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 serviços da AWS e do Azure com 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.
É possível migrar do seu ambiente de origem para o 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:
- Avaliar e descobrir suas cargas de trabalho e seus dados.
- Planejar e criar uma base em Google Cloud.
- Migre suas cargas de trabalho e seus dados para o Google Cloud.
- Otimize o Google Cloud ambiente.
Para mais informações sobre as fases desse framework, consulte Migrar para o 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 simples transferência de funções de um provedor de nuvem para outro. Como os aplicativos baseados na nuvem dependem de uma rede de serviços interconectados, a migração da AWS para o Google Cloud pode requerer a substituição de serviços dependentes da AWS por serviços Google Cloud . Por exemplo, considere um cenário em que a função 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 ter uma funcionalidade semelhante.
A migração também é uma oportunidade valiosa para você revisar as decisões de arquitetura e design do seu aplicativo sem servidor. Com essa análise, você pode descobrir oportunidades para fazer o seguinte:
- Otimizar com recursos Google Cloud integrados: confira se os serviçosGoogle Cloud oferecem vantagens exclusivas ou se estão mais alinhados aos requisitos do seu aplicativo.
- Simplifique sua arquitetura: avalie se é possível simplificar consolidando a funcionalidade ou usando os serviços de maneira diferente no Google Cloud.
- Melhorar a eficiência de custos: avalie as possíveis diferenças de custo da execução do aplicativo reestruturado na infraestrutura fornecida em Google Cloud.
- Melhorar a eficiência do código: refatore seu código com o processo de migração.
Planeje sua migração de forma estratégica. Não considere 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 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 o 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:
- Criar um inventário abrangente das suas cargas de trabalho.
- Catalogar suas cargas de trabalho de acordo com as propriedades e dependências delas.
- Treine e instrua suas equipes sobre Google Cloud.
- Crie experimentos e provas de conceito no Google Cloud.
- Calcule o custo total de propriedade (TCO) do ambiente de destino.
- Escolha a estratégia de migração para suas cargas de trabalho.
- Escolha as ferramentas de migração.
- Defina o plano e o cronograma de migração.
- 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 cargas de trabalho. As seções a seguir são baseadas nas informações desse documento.
Criar 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 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 em APIs da AWS, ferramentas de desenvolvedor da AWS e na interface de linha de comando da AWS.
Depois de criar o 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 em aspectos que ajudam a prever possíveis problemas. 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 a coletar 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
- 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 de conformidade e regulamentares
- 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 você precisa modificar as cargas de trabalho e as dependências antes da migração. Para cada carga de trabalho, recomendamos o seguinte:
- Receba insights sobre o caso de uso específico que a carga de trabalho atende 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
O inventário do 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 do código-base, que geralmente é armazenado 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 código de origem é essencial para seus processos de DevOps, como pipelines de integração e desenvolvimento contínuos (CI/CD), porque esses processos 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 você precisa refazer as cargas de trabalho da AWS Lambda. Para identificar quais artefatos de implantação a carga de trabalho precisa, 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.
- Qualquer extensão do AWS Lambda da qual 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
A AWS Lambda oferece suporte a 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 acionadores e mapeamentos de origem de eventos que invocam a carga de trabalho.
- Se a carga de trabalho oferece suporte a invocações síncronas e assíncronas.
- Os URLs de carga de trabalho e os 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 é necessário 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 assincronas.
- O formato dos eventos que a carga de trabalho processa.
- Como a carga de trabalho do AWS Lambda e as extensões dela interagem com as APIs do AWS Lambda ou outras APIs da AWS.
Para funcionar, os workloads 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, 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 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.
- A arquitetura de 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 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 aplicadas ao ambiente de execução.
Configuração da carga de trabalho
Para configurar as cargas de trabalho durante a migração da AWS Lambda para o Cloud Run, recomendamos que você avalie como configurou cada carga de trabalho da AWS Lambda.
Para cada carga de trabalho da AWS Lambda, colete informações sobre as seguintes configurações de escalonabilidade e simultaneidade:
- 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 tempo máximo de execução permitido.
- Indica 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 a AWS Lambda configura e 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 avaliação, recomendamos que você avalie os requisitos de segurança dos seus workloads do AWS Lambda e a configuração deles em termos de controles de acesso e gerenciamento. Essas informações são essenciais se você precisar implementar controles semelhantes no ambiente Google Cloud . Para cada carga de trabalho, considere o seguinte:
- O papel de execução e as permissões.
- A configuração de 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 de conformidade e regulamentares
Para cada carga de trabalho da AWS Lambda, entenda os requisitos de conformidade e regulamentação dela fazendo o seguinte:
- Avalie todos os requisitos regulamentares e de compliance que a carga de trabalho precisa atender.
- Determine se a carga de trabalho está atendendo a esses requisitos.
- Determine se há requisitos futuros que precisam ser atendidos.
Os requisitos de compliance e regulamentares podem ser independentes do provedor de nuvem que você está usando, e esses requisitos também podem afetar a migração. Por exemplo, talvez seja necessário garantir que os dados e o tráfego de rede fiquem 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 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 build de artefatos no ambiente de destino. Google CloudÉ 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 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 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:
- Ofereça suporte às cargas de trabalho no Google Cloud ambiente.
- Conecte o ambiente de origem e o Google Cloud para concluir a migração.
A fase de criação e planejamento é composta pelas seguintes tarefas:
- Crie uma hierarquia de recursos.
- Configure o Identity and Access Management (IAM) do Google Cloud.
- Configure o faturamento.
- Configurar a conectividade de rede.
- Aumentar sua segurança.
- 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: planeje e crie sua base.
Migrar suas cargas de trabalho do AWS Lambda
Para migrar as cargas de trabalho da AWS Lambda para o Cloud Run, faça o seguinte:
- Projete, provisione e configure seu ambiente do Cloud Run.
- Se necessário, refatore as cargas de trabalho do AWS Lambda para torná-las compatíveis com o Cloud Run.
- Refatore seus processos operacionais e de implantação para implantar e observar cargas de trabalho no Cloud Run.
- Migrar os dados necessários para suas cargas de trabalho do AWS Lambda.
- 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 são comparados a 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 o design e as decisões de 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 ofereça suporte às cargas de trabalho que você está migrando da AWS Lambda.
Para projetar corretamente seu ambiente do Cloud Run, use os dados que você coletou durante a fase de avaliação sobre cada carga de trabalho do AWS Lambda. Esses dados ajudam você a fazer o seguinte:
- Escolha os recursos certos do Cloud Run para implantar sua carga de trabalho.
- Projete a configuração dos recursos do Cloud Run.
- 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 as 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 contêinerizado, 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 da AWS Lambda são associados a esses principais recursos do Cloud Run:
Recurso do AWS Lambda | Recurso do Cloud Run |
---|---|
Função do AWS Lambda acionada por um evento, como aqueles usados para sites e aplicativos da Web, APIs e microsserviços, processamento de dados em 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 aquelas para tarefas em segundo plano e trabalhos em lote. | Job do Cloud Run que é executado até a conclusão. |
Além dos serviços e jobs, o Cloud Run fornece outros recursos que estendem esses recursos principais. Para mais informações sobre todos os recursos do Cloud Run disponíveis, consulte o modelo de recursos do Cloud Run.
Projetar a configuração dos recursos do Cloud Run
Antes de provisionar e configurar seus 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 tempo limite de solicitações, 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.
Ativações 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 seus workloads 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 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 da AWS Lambda e quais recursos do Cloud Run podem ser usados na refatoração dessas cargas de trabalho.
Para saber mais sobre os gatilhos de serviço fornecidos pelo Cloud Run, use estes recursos:
- Invocação HTTPS: envie solicitações HTTPS para acionar os serviços do Cloud Run.
- Invocação HTTP/2: envie solicitações HTTP/2 para acionar os serviços do Cloud Run.
- WebSockets: conecte clientes a um servidor WebSockets em execução no Cloud Run.
- Conexões gRPC: conecte-se aos serviços do Cloud Run usando o gRPC.
- Invocação assíncrona: enfileira tarefas usando o Cloud Tasks para que sejam processadas de maneira assíncrona pelos serviços do Cloud Run.
- Invocação programada: use o Cloud Scheduler para invocar os serviços do Cloud Run em uma programação.
- Invocação baseada em eventos: crie gatilhos do Eventarc para invocar serviços do Cloud Run em eventos específicos no formato CloudEvents.
- Integração com o Pub/Sub: invoque serviços do Cloud Run de assinaturas de push do Pub/Sub.
- Integração com o Workflows: invoque um serviço do Cloud Run em um fluxo de trabalho.
Para saber mais sobre os mecanismos de execução de jobs que o Cloud Run oferece, use os seguintes recursos:
- Execução sob demanda: crie execuções de job que são concluídas.
- Execução programada: execute jobs do Cloud Run em uma programação.
- Integração com o Workflows: execute jobs do Cloud Run em um fluxo de trabalho.
Para entender quais mecanismos de invocação ou execução do Cloud Run são comparáveis aos mecanismos de invocação da 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 HTTPS (URLs de função) | Chamada HTTPS |
Acionador HTTP/2 (parcialmente compatível com o uso de uma gateway de API externa) | Invocação HTTP/2 (com suporte nativo) |
WebSockets (com suporte a gateway de API externa) | WebSockets (com suporte nativo) |
N/A (conexões gRPC nã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 |
Acionamento baseado em evento em um formato reservado | Invocação baseada 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 de fluxos de trabalho |
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 suporte a 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 de recursos e jobs.
Como mencionado anteriormente, você pode entender melhor como o Cloud Run funciona entendendo primeiro todas as opções de configuração disponíveis no Cloud Run. Esse entendimento ajuda você a comparar os recursos do AWS Lambda com recursos semelhantes do Cloud Run e a determinar como refatorizar suas cargas de trabalho.
Para saber mais sobre as configurações que os serviços do Cloud Run oferecem, use os seguintes recursos:
- Capacidade: limites de memória, limites de CPU, alocação de CPU, tempo limite de solicitação, solicitações simultâneas máximas por instância, instâncias mínimas, instâncias máximas e configuração de GPU
- Ambiente: porta e ponto de entrada do contêiner, variáveis de ambiente, montagens de volume do Cloud Storage, montagens de volume em memória, ambiente de execução, verificações de integridade do contêiner, secrets e contas de serviço
- Escalonamento automático
- Como lidar com condições excepcionais: como lidar com falhas do Pub/Sub e como lidar com falhas do Eventarc
- Metadados: descrição, rótulos e tags
- Servir tráfego: mapeamento de domínio personalizado, URLs atribuídos automaticamente, integração com o Cloud CDN e afinidade de sessão
Para saber mais sobre os jobs que o Cloud Run oferece, use os seguintes recursos:
- Capacidade: limites de memória, limites de CPU, paralelismo e tempo limite da tarefa
- Ambiente: ponto de entrada do contêiner, variáveis de ambiente, montagens de volume do Cloud Storage, montagens de volume na memória, segredos e contas de serviço
- Como lidar com condições excepcionais: novas tentativas máximas
- Metadados: rótulos e tags
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). |
Instâncias máximas por serviço |
N/A (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 de instâncias (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 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, você também precisa considerar as diferenças entre a forma 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 que você defina 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ão cobradas 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 oferece suporte a várias opções de configuração para ajudar a proteger seu ambiente e definir funções e permissões para seus workloads do Cloud Run.
Esta seção destaca os controles de segurança e de 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 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 que o Cloud Run oferece, use os seguintes recursos:
- Permitir acesso público (não autenticado)
- Públicos-alvo personalizados
- Autenticação do desenvolvedor
- Autenticação entre serviços
- Autenticação do usuário
Para saber mais sobre os recursos de segurança que o Cloud Run oferece, use os seguintes recursos:
- Controle de acesso com o Identity and Access Management (IAM)
- Identidade por serviço
- Integração com o Google Cloud Armor
- Autorização binária
- Chaves de criptografia gerenciadas pelo cliente
- Segurança da cadeia de suprimentos de software
- Configurações de restrição de entrada
- VPC Service Controls
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 o acesso e gerenciamento de identidade da AWS | 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:
- Implantar um serviço do Cloud Run da origem
- Como implantar imagens de contêiner no Cloud Run
- Criar jobs
- Implantar uma função do Cloud Run
Refazer cargas de trabalho do AWS Lambda
Para migrar as 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 acionadores que contêm eventos do Amazon CloudWatch, talvez seja necessário refatorar essa carga de trabalho para que ela aceite eventos no formato CloudEvents.
Vários fatores 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 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 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 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 fazer o mesmo no ambiente de execução do Cloud Run. Por exemplo, se uma carga de trabalho exigir que determinados pacotes ou bibliotecas estejam disponíveis, você precisará instalá-los 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 oferece suporte a variáveis de ambiente e segredos 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.
- Relatórios de erros. Considere se a carga de trabalho informa erros usando saída padrão e fluxos de erros. Uma carga de trabalho que faz esse tipo de relatório de erro 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:
- Dicas gerais de desenvolvimento
- Otimizar aplicativos Java para o Cloud Run
- Otimizar aplicativos Python para o Cloud Run
- Práticas recomendadas de teste de carga
- Práticas recomendadas de novas tentativas de jobs e checkpoints
- Proxy de front-end usando Nginx
- Veicular recursos estáticos com o Cloud CDN e o Cloud Run
- Entenda a redundância zonal do Cloud Run
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 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 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:
- Migrar para o Google Cloud: implantar suas cargas de trabalho
- Migrar para Google Cloud: migrar de implantações manuais para implantações automatizadas e conteinerizadas
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:
- Provisione repositórios de artefatos em Google Cloud. Por exemplo, é possível usar o Artifact Registry para armazenar artefatos e criar dependências.
- Refatore seus processos de build para armazenar artefatos no ambiente de origem e no Artifact Registry.
- 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 em Google Cloud, usando artefatos armazenados no Artifact Registry. Em seguida, aumente gradualmente o número de cargas de trabalho implantadas no Google Cloudaté que todas as cargas de trabalho a serem migradas sejam executadas no Google Cloud.
- Refactorize seus processos de build para armazenar artefatos apenas no Artifact Registry.
- 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.
- 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 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 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ê refactorize seus processos operacionais para monitorar seu ambiente do Cloud Run de maneira constante e eficaz.
O Cloud Run se integra aos seguintes serviços operacionais:
- Google Cloud Observability para fornecer geração de registros, monitoramento e alertas para suas cargas de trabalho. Se necessário, você também pode usar o monitoramento no estilo do Prometheus ou as métricas do OpenTelemetry para suas cargas de trabalho do Cloud Run.
- Registros de auditoria do Cloud para fornecer registros de auditoria.
- Cloud Trace para fornecer rastreamento de desempenho distribuído.
Migrar dados
A fase de avaliação anterior a este 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 a migração de 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 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 de 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 deles. Se você acredita que requer um esforço significativo para migrar esses dados, recomendamos fazer a migração como parte de um projeto separado e dedicado.
Validar os resultados da migração
A validação da migração de carga de trabalho não é um evento único, mas um processo contínuo. É preciso manter o foco em testes e validação antes, durante e depois da migração da AWS Lambda para o Cloud Run.
Para garantir uma migração bem-sucedida com desempenho ideal e interrupções mínimas, recomendamos o uso do seguinte processo para validar as cargas de trabalho que você está migrando da AWS Lambda para o Cloud Run:
- Antes de iniciar a fase de migração, refatore seus casos de teste para considerar o ambiente Google Cloud de destino.
- Durante a migração, valide os resultados do teste em cada etapa 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 indicar problemas de migração ou configuração.
- Teste funcional: crie e execute casos de teste que abranjam vários cenários de entrada e saída esperados nos dois ambientes para garantir que a lógica principal das suas cargas de trabalho permaneça consistente.
- Teste de carga: aumente gradualmente o tráfego para avaliar o desempenho e a capacidade de escalonamento do Cloud Run em condições reais. Para garantir uma migração tranquila, resolva discrepâncias, como erros e limitações de recursos.
Otimizar o 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:
- Avaliar o ambiente, as equipes e o ciclo de otimização atuais.
- Estabeleça suas metas e requisitos de otimização.
- Otimize o ambiente e as equipes.
- 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 Google Cloud: otimizar o ambiente e Framework de arquiteturaGoogle Cloud : otimização de performance.
A seguir
- Leia sobre outras jornadas de migração da AWS para o Google Cloud .
- Saiba como comparar os serviços da AWS e do Azure com o Google Cloud.
- Saiba quando buscar ajuda para suas migrações.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.
Colaboradores
Autores:
- Marco Ferrari | Arquiteto de soluções do Cloud
- Xiang Shen | Arquiteto de soluções
Outros colaboradores:
- Steren Giannini | Gerente de produto do grupo
- James Ma | Gerente de produtos
- Henry Bell | Arquiteto de soluções em nuvem
- Christoph Stanger | Engenheiro estratégico do Cloud
- CC Chen | Arquiteto de soluções do cliente
- Wietse Venema | Engenheiro de relações com desenvolvedores