Refatorar limites específicos do provedor

Preserve a lógica de negócios ao substituir o código de integração específico da AWS.

Para refatorar os limites específicos do profissional de saúde, siga estas etapas:

  1. Extraia a lógica de negócios em módulos neutros para provedores. Adicione um analisador de eventos da AWS somente para reproduzir eventos de origem capturados durante os testes de comparação.
  2. Criar um adaptador do OCI para o padrão de chamada de destino: request/response, CloudEvent, mensagem de fila, registro de fluxo, evento de objeto, notificação ou solicitação de integração.
  3. Substitua chamadas diretas do AWS SDK por interfaces e implemente chamadas de serviço do OCI por trás dessas interfaces. Faça o mesmo para configuração, acesso a segredo, registro em log, métricas e tratamento de novas tentativas.
  4. Reproduza eventos Lambda capturados e compare códigos de status, cabeçalhos, corpos de resposta, metadados de objetos, gravações downstream, efeitos colaterais, mensagens de erro e comportamento de idempotência.

Procure que a lógica de negócios seja separada do parsing de eventos, das chamadas do SDK, das suposições do IAM, do registro em log, do empacotamento e do tratamento de novas tentativas.

Considerações: Evite reescrever a lógica de negócios ao mesmo tempo que a integração do provedor. A mudança de ambos torna o teste de equivalência mais difícil.

Entenda o que o OCI fornece

Identificar quais etapas de migração usam a configuração padrão do OCI e quais exigem código personalizado.

O Oracle Cloud Infrastructure fornece serviços para execução de funções, gerenciamento de API, eventos, filas, programação, identidade, rede, observabilidade e implantação. No entanto, a migração ainda pode exigir alterações específicas da carga de trabalho, incluindo:

  • Convertendo payloads de evento da AWS na entrada esperada pelo aplicativo
  • Substituindo chamadas do AWS SDK por chamadas do OCI SDK
  • Recriando comportamento de gatilho, repetição, ordenação e falha
  • Traduzindo permissões do IAM e acesso à rede
  • Atualização de pipelines de CI/CD e procedimentos operacionais

Antes da implementação, identifique quais etapas usam a configuração padrão do OCI e quais exigem código personalizado. Valide essa distinção usando uma carga de trabalho representativa antes de estimar a migração mais ampla.

Empacotar e Implantar a Função OCI

Crie a função migrada como uma imagem de contêiner e implante-a no OCI Functions.

Para empacotar e implantar uma função, siga estas etapas:

  1. Crie ou atualize o projeto de função e func.yaml. Defina memória e timeout a partir do comportamento de origem medido, não a partir de padrões.
  2. Mova o conteúdo anterior da camada Lambda, as dependências nativas, as dependências de runtime, os certificados e os pacotes do sistema para a imagem ou uma imagem base compartilhada, conforme apropriado.
  3. Rastreie o tamanho da imagem, as versões de dependência, a compatibilidade da biblioteca nativa, o comportamento de inicialização, o trabalho de inicialização e o comportamento de runtime dentro da imagem do contêiner.
  4. Crie, envie, implante e chame a função com cargas úteis representativas de sucesso e falha antes de conectar os acionadores de produção.

Verifique se a imagem cria, envia, implanta, chama com sucesso e registra a saída esperada sem vazar segredos.

Considerações: O empacotamento de dependência geralmente ocorre quando suposições ocultas do Lambda aparecem, especialmente com camadas, bibliotecas nativas, extensões e versões SDK incorporadas.

Usar um Padrão de Entrega Repetível

Uma migração de produção deve usar um processo de entrega controlado por versão.

Para usar um padrão de entrega repetível, siga estas etapas:

  1. Armazene o código de função, a configuração, os testes e as definições de infraestrutura juntos.
  2. Crie e teste um artefato de função com controle de versão.
  3. Verifique o artefato e suas dependências.
  4. Promova o mesmo artefato testado entre ambientes.
  5. Provisione ou atualize recursos do OCI por meio de Infraestrutura como Código.
  6. Executar testes de fumaça e integração após a implantação.
  7. Mantenha o artefato e a configuração de produção anteriores para rollback.

Use a plataforma CI/CD existente quando for prático. Não exija uma alteração no conjunto de ferramentas, a menos que seja necessário para a arquitetura do OCI Functions.

Migrar Triggers e Integrações

Recrie o comportamento de chamada necessário no OCI.

Para migrar acionadores e integrações, siga estas etapas:

  1. Para cargas de trabalho HTTP, compare autenticação, método, caminho, cabeçalhos, strings de consulta, esquema do corpo, códigos de status, corpo do erro, tamanho do payload, timeout, latência e comportamento de repetição do chamador.
  2. Para eventos de objeto, compare esquema de evento, metadados de objeto, namespace, filtragem de bucket e prefixo, comportamento de criação/atualização/exclusão, comportamento de repetição, eventos duplicados, idempotência e prevenção de loop entre caminhos de entrada e saída.
  3. Para filas e fluxos, crie um tratamento explícito para tamanho de lote, ordenação, falha parcial, visibilidade ou comportamento de repetição, DLQ ou destino de falha, mensagens de veneno, contrapressão, duplicatas, throughput e repetição.
  4. Para programações, notificações, logs e fluxos de integração, verifique o tipo de chamada, a latência, a contagem de repetições, o roteamento de falhas, o comportamento de fanout, a filtragem e a observabilidade.

Valide se cada trigger tem um padrão de destino do OCI documentado e passa em testes para cenários normais, de falha, de repetição e de entrega de duplicidades.

Considerações: Não suponha que um mapeamento de origem de evento da AWS tenha um substituto direto da OCI. Preserve o comportamento necessário, não o nome de controle da AWS.

Padrões de Trigger Lambda Comuns

Os mapeamentos a seguir estão iniciando padrões para uma migração do OCI Functions.

Valide o comportamento necessário antes da implementação:

Padrão AWS Padrão inicial do OCI Functions Itens para validar
Gateway de API para Lambda Gateway de API do OCI para OCI Functions Rotas, métodos, autenticação, formatos de solicitação e resposta, limites de payload, timeouts, códigos de status e comportamento de erro síncrono
EventBridge para Lambda OCI Events para OCI Functions para eventos de serviço do OCI; use o serviço de roteamento de eventos do OCI aplicável para requisitos de roteamento mais amplos Cobertura de eventos, filtros, esquemas, comportamento de entrega, repetições e requisitos de repetição
SQS para Lambda Oracle Cloud Infrastructure Queue por meio do OCI Connector Hub para Funções do OCI Tamanho do lote, tempo limite de visibilidade, entrega pelo menos uma vez, pedidos, manipulação de duplicidades, mensagens de veneno e recuperação de falhas
Eventos S3 para Lambda Eventos do OCI Object Storage por meio do OCI Events para o OCI Functions Esquema de evento, filtros, entrega duplicada, permissões de objeto, comportamento de repetição e efeitos colaterais downstream
Eventos programados para Lambda OCI Resource Scheduler para Funções do OCI Programar expressão, fuso horário, payload de entrada, timeout, execuções sobrepostas e destinos de sucesso ou falha

Não suponha que os serviços AWS e OCI tenham comportamento idêntico. Valide o comportamento exigido por cada carga de trabalho antes da implementação.

Preservar Comportamento de Trigger e Falha

Documente e teste o comportamento necessário para cada acionador migrado.

Para preservar o comportamento de trigger e falha, siga estas etapas:

  1. Documente e teste o seguinte para cada acionador migrado:
    • Se a entrega é síncrona ou assíncrona
    • Repetir proprietário, intervalo de repetição e máximo de tentativas
    • Garantias de entrega e possíveis eventos duplicados
    • Requisitos de pedido
    • Comportamento de idempotência
    • Comportamento de lote e falha parcial
    • Timeout de visibilidade ou comportamento de confirmação
    • Tratamento de mensagens venenosas
    • Destino de falha ou letra morta
    • Procedimento de repetição e recuperação
  2. Não suponha que serviços similares da AWS e da OCI tenham comportamento de entrega ou falha idêntico.
  3. Quando a entrega duplicada é possível, projete a função para processar eventos repetidos com segurança.

Para chamadas desanexadas do OCI Functions, registros de sucesso e falha podem ser enviados para destinos do OCI Queue, do OCI Streaming ou do OCI Notifications. Esse comportamento é específico para chamadas desanexadas e não deve ser descrito como um substituto universal para cada padrão de fila de mensagens mortas da AWS.

Configurar o IAM, Segredos e Rede

Traduza o comportamento de runtime para acesso à OCI de menor privilégio e acessibilidade de rede aprovada.

Para configurar o OCI Identity and Access Management (IAM), segredos e rede, siga estas etapas:

  1. Mapeie cada ação de origem para uma ação, recurso e compartimento do OCI. Evite políticas amplas, a menos que a carga de trabalho realmente exija que eles e os revisores aprovem.
  2. Use grupos dinâmicos e controladores de recursos para acesso de runtime aos recursos do OCI. Teste os caminhos permitidos e negados, incluindo compartimento errado, bucket errado, segredo errado e casos de política ausentes.
  3. Mova segredos para o OCI Vault ou um padrão aprovado. Confirme se nenhum valor de segredo aparece no código-fonte, imagens, logs, despejos de ambiente, saída de CI, rastreamentos de pilha ou mensagens de erro.
  4. Valide regras de roteamento, regras de segurança, gateway de serviço ou comportamento NAT, pontos finais privados, DNS, confiança TLS, listas de permissões externas e limites de conexão downstream.

Valide se as chamadas de serviço permitidas foram bem-sucedidas, os caminhos negados falharam com segurança e os caminhos de rede necessários estão acessíveis sem expor caminhos não autorizados.

Considerações: A tradução do IAM deve começar com o comportamento de runtime observado, não com base nos nomes de políticas da AWS ou em políticas gerenciadas amplas.

Recriar Observabilidade e Operações

Garanta que os proprietários de produção possam detectar, diagnosticar e se recuperar de falhas.

Para recriar a observabilidade e as operações, siga estas etapas:

  1. Emite logs com ID de correlação, ID da solicitação, ID do acionador, identificador de objeto ou mensagem, status, duração, contagem de novas tentativas, detalhes do erro higienizado e resultado de dependência downstream.
  2. Confirme métricas e alarmes para contagem de chamadas, duração, taxa de erros, contagem de timeout, limitação ou sintomas de capacidade, DLQ ou contagem de falhas, idade da fila ou backlog, resultados de entrega desanexados e falhas downstream.
  3. Crie painéis de controle ou views aprovadas para integridade, latência, erros, capacidade, backlog do trigger e status de dependência.
  4. Atualize runbooks com testes de chamada, consultas de log, resposta de alarme, contatos de escalação, trigger de rollback, etapas de rollback e tempo de recuperação esperado.

Verifique se os operadores de produção podem observar e solucionar problemas da função migrada antes da movimentação do tráfego.

Considerações: Uma migração não está pronta para produção se apenas a função funcionar. Os operadores devem ser capazes de detectar e recuperar de um trigger com falha, segredo, caminho de rede ou dependência downstream.