Compartilhar via

Migrar um aplicativo Web usando o Gerenciamento de API do Azure

Gerenciamento de API do Azure
Azure Monitor
Serviço de aplicativo do Azure

Neste cenário, uma empresa de comércio eletrônico no setor de viagens migra um aplicativo Web herdado usando o Gerenciamento de API do Azure. A nova interface do usuário é hospedada como um aplicativo PaaS (plataforma como serviço) no Azure e depende de APIs HTTP existentes e novas. Essas APIs são enviadas com um conjunto de interfaces melhor projetado, que permitem melhor desempenho, integração mais fácil e extensibilidade futura.

Architecture

Diagrama de arquitetura

Baixe um arquivo do Visio dessa arquitetura.

Workflow

  1. O aplicativo Web local existente continuará a consumir diretamente os serviços Web locais existentes.
  2. As chamadas do aplicativo Web existente para os serviços HTTP existentes permanecerão inalteradas. Essas chamadas são internas na rede corporativa.
  3. Chamadas de entrada são feitas do Azure para os serviços internos existentes:
  4. A nova API:
  5. O novo aplicativo Web baseado em navegador depende da instância de Gerenciamento de API do Azure para a API HTTP existente e a nova API.
  6. A empresa de comércio eletrônico de viagens agora pode direcionar alguns usuários para a nova interface do usuário (para versão prévia ou teste), preservando a interface do usuário antiga e a funcionalidade existente lado a lado.

A instância do Gerenciamento de API está configurada para mapear os serviços HTTP herdados para um novo contrato de API. Com essa configuração, a nova interface do usuário da Web desconhece a integração com um conjunto de serviços/APIs herdados e as novas APIs.

No futuro, a equipe de projeto poderá portar gradualmente a funcionalidade para as novas APIs e desativar os serviços originais. A equipe lida com essas alterações na configuração de Gerenciamento de API, deixando a interface do usuário de front-end não afetada e evitando o trabalho de redesenvolvimento.

Components

  • O Gerenciamento de API do Azure abstrai AS APIs de back-end, bem como a adição de funcionalidade e descoberta cruzadas para desenvolvedores e aplicativos. Nesse cenário, a recomposição das APIs de back-end legadas existentes e a adição de novas funcionalidades de API são possibilitadas usando o Gerenciamento de API como uma fachada para que o novo aplicativo cliente as consuma de forma consistente e usando padrões modernos. Como o Gerenciamento de API faz fachadas tanto das APIs existentes quanto das novas, é possível que os desenvolvedores modernizem os back-ends herdados por trás da fachada de Gerenciamento de API de forma iterativa e com impacto mínimo a zero no novo desenvolvimento de front-end.
  • O Serviço de Aplicativo do Azure é um serviço de PaaS (Plataforma como Serviço) para hospedagem na Web que fornece recursos prontos para uso, como segurança, balanceamento de carga, dimensionamento automático e gerenciamento automatizado. O Serviço de Aplicativo do Azure é uma ótima opção para as novas APIs que estão sendo desenvolvidas para essa solução porque fornece hospedagem flexível e pronta para uso, permitindo que a equipe de DevOps se concentre no fornecimento de recursos.

Alternatives

  • Se a organização planeja mover sua infraestrutura inteiramente para o Azure, incluindo as VMs (máquinas virtuais) que hospedam os aplicativos herdados, o Gerenciamento de API ainda é uma ótima opção porque pode atuar como uma fachada para qualquer ponto de extremidade HTTP endereçável.

  • Se a organização decidisse manter os pontos de extremidade existentes privados e não os expor publicamente, a instância de Gerenciamento de API da organização poderia estar vinculada a uma Rede Virtual do Azure:

  • A organização pode manter a instância do Gerenciamento de API particular implantando-a no modo interno. Em seguida, a organização pode usar a implantação com o Gateway de Aplicativo do Azure para habilitar o acesso público para algumas APIs, enquanto outras permanecem internas. Para obter mais informações, consulte Integrar o Gerenciamento de API em uma rede virtual interna com o Gateway de Aplicativo.

  • A organização pode decidir hospedar suas APIs localmente. Um dos motivos para fazer essa alteração pode ser porque a organização não pôde mover dependências de banco de dados downstream que estão no escopo desse projeto para a nuvem. Se esse for o caso, a organização ainda poderá aproveitar o Gerenciamento de API localmente usando um gateway auto-hospedado.

    O gateway auto-hospedado é uma implantação em contêiner do gateway do Gerenciamento de API que se conecta novamente ao Azure em um soquete de saída. O primeiro pré-requisito é que os gateways auto-hospedados não podem ser implantados sem um recurso pai no Azure, que tem uma cobrança adicional. Em segundo lugar, o nível Premium do Gerenciamento de API é necessário.

Detalhes do cenário

Uma empresa de comércio eletrônico no setor de viagens está modernizando sua pilha de software herdado baseado em navegador. Embora a pilha existente seja principalmente monolítica, alguns serviços HTTP baseados em SOAP (Simple Object Access Protocol) existem de um projeto recente. A empresa está considerando a criação de fluxos de receita adicional para monetizar parte da propriedade intelectual interna que foi desenvolvida.

As metas do projeto incluem endereçar a dívida técnica, melhorar a manutenção contínua e acelerar o desenvolvimento de recursos com menos erros de regressão. O projeto usa um processo iterativo para evitar riscos, com algumas etapas executadas em paralelo:

  • A equipe de desenvolvimento moderniza o back-end do aplicativo, que consiste em bancos de dados relacionais hospedados em VMs.
  • A equipe de desenvolvimento interna grava novas funcionalidades de negócios expostas por novas APIs HTTP.
  • Uma equipe de desenvolvimento de contrato cria uma nova interface do usuário baseada em navegador, que está hospedada no Azure.

Novos recursos de aplicativo são entregues em estágios. Esses recursos substituem gradualmente a funcionalidade existente de interface do usuário do cliente/servidor baseada em navegador (hospedada localmente) que agora alimenta o negócio de comércio eletrônico da empresa.

Os membros da equipe de gerenciamento não querem uma modernização desnecessária. Ela também quer manter o controle de escopo e custos. Para isso, eles decidiram preservar os serviços HTTP de SOAP existentes. Ela também pretende minimizar as alterações na interface do usuário existente. Eles podem usar o Gerenciamento de API do Azure para atender a muitos dos requisitos e restrições do projeto.

Possíveis casos de uso

Esse cenário destaca a modernização de pilhas de software herdadas baseadas em navegador.

Você pode usar esse cenário para:

  • Ver como sua empresa pode se beneficiar do uso do ecossistema do Azure.
  • Planejar a migração de serviços para o Azure.
  • Saber como uma mudança para o Azure afetaria as APIs existentes.

Considerations

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que você pode usar para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Well-Architected Framework.

Reliability

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos que você faz aos seus clientes. Para obter mais informações, consulte a lista de verificação de revisão de design para Confiabilidade.

  • Considere implantar sua instância de Gerenciamento de API do Azure com zonas de disponibilidade habilitadas. A opção para implantar o Gerenciamento de API em zonas de disponibilidade só está disponível na camada de serviço Premium.
  • As zonas de disponibilidade podem ser usadas em conjunto com instâncias de gateway adicionais implantadas em regiões diferentes. Isso melhora a disponibilidade do serviço se uma região ficar offline. A implantação multirregião também está disponível apenas na camada de serviço Premium.
  • Considere a integração com o Azure Application Insights, que também apresenta métricas por meio do Azure Monitor para monitoramento. Por exemplo, a métrica de capacidade pode ser usada para determinar a carga geral no recurso de Gerenciamento de API e se unidades de expansão adicionais são necessárias. Controlar a capacidade e a integridade dos recursos melhora a confiabilidade.
  • Certifique-se de que as dependências downstream, por exemplo, os serviços de back-end que hospedam as APIs que o Gerenciamento de API apresenta, também sejam resilientes.

Otimização de custos

A Otimização de Custos concentra-se em maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte a lista de verificação de revisão de design para Otimização de Custos.

O Gerenciamento de API é fornecido em quatro níveis: Desenvolvedor, Básico, Standard e Premium. Para obter mais informações sobre as diferenças nessas camadas, consulte as diretrizes de preços do Gerenciamento de API do Azure.

É possível escalar o Gerenciamento de API adicionando e removendo unidades. Cada unidade tem capacidades que dependem de sua camada.

Note

O nível Desenvolvedor pode ser usado para avaliação dos recursos do Gerenciamento de API. Não use-o para produção.

Para exibir os custos projetados e personalizar de acordo com suas necessidades de implantação, você pode modificar o número de unidades de escala e instâncias do Serviço de Aplicativo na calculadora de preços do Azure.

Contributors

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas

Documentação do produto:

Módulos de aprendizado.