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 será hospedada como um aplicativo de PaaS (plataforma como serviço) no Azure e dependerá das APIs de HTTP existentes e novas. Essas APIs serão fornecidas com um conjunto de interfaces melhor projetado, permitindo a melhoria do desempenho, integração mais fácil e extensibilidade futura.
Arquitetura
Baixe um arquivo Visio dessa arquitetura.
Workflow
- O aplicativo Web local existente continuará a consumir diretamente os serviços Web locais existentes.
- As chamadas do aplicativo Web existente para os serviços HTTP existentes permanecerão inalteradas. Essas chamadas são internas na rede corporativa.
- Chamadas de entrada são feitas do Azure para os serviços internos existentes:
- A equipe de segurança permite que o tráfego da instância do Gerenciamento de API passe pelo firewall corporativo para os serviços locais existentes usando o transporte seguro (HTTPS ou SSL).
- A equipe de operações permite chamadas de entrada para os serviços somente da instância do Gerenciamento de API. Esse requisito é atendido adicionando o endereço IP da instância do Gerenciamento de API à lista de permitidos dentro do perímetro da rede corporativa.
- Um novo módulo é configurado no pipeline de solicitação local para serviços HTTP (para atuar apenas em conexões originadas externamente). O pipeline valida um certificado fornecido pelo Gerenciamento de API.
- A nova API:
- É exibida somente por meio da instância do Gerenciamento de API, que fornece a fachada da API. A nova API não é acessada diretamente.
- É desenvolvida e publicada como um aplicativo de API Web de PaaS do Azure.
- É configurada (por meio de configurações para o recurso Aplicativos Web do Serviço de Aplicativo do Azure) para aceitar apenas o IP virtual (VIP) do Gerenciamento de API.
- É hospedada em Aplicativos Web com transporte seguro (HTTPS ou SSL) ativado.
- Tem autorização habilitada, fornecida pelo Serviço de Aplicativo do Azure por meio do Microsoft Entra ID e do OAuth 2.
- O novo aplicativo Web baseado em navegador depende da instância do Gerenciamento de API do Azure para ambas as APIs HTTP, a nova e a existente.
- 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 transferirá gradualmente a funcionalidade de porta para as novas APIs e desativará os serviços originais. A equipe lidará com essas alterações na configuração do Gerenciamento de API, não afetando a interface do usuário de front-end e evitando o trabalho de redesenvolvimento.
Componentes
- O Gerenciamento de API do Azure abstrai APIs de back-end, além de adicionar funcionalidade transversal e descoberta para desenvolvedores e aplicativos. Neste cenário, a recomposição de APIs de back-end herdadas existentes e a adição de novas funcionalidades de API são possíveis usando o Gerenciamento de API como uma fachada para que o novo aplicativo cliente 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) perfeito 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.
Alternativas
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 decidiu manter os pontos de extremidade particulares existentes e não mostrá-los publicamente, sua instância do Gerenciamento de API pode ser vinculada a uma rede virtual do Azure:
- Quando o Gerenciamento de API está vinculado a uma rede virtual do Azure, a organização pode abordar diretamente o serviço de back-end através de endereços IP privados.
- No cenário local, a instância do Gerenciamento de API pode alcançar o serviço interno de modo privado por meio de um Gateway de VPN do Azure e da conexão VPN IPSec de site a site ou do ExpressRoute do Azure. Esse cenário se tornaria um híbrido do Azure e local.
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 mais informações, consulte Como 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, existem alguns serviços HTTP baseados em SOAP 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 usará um processo iterativo para evitar o risco, com algumas etapas executadas em paralelo:
- A equipe de desenvolvimento modernizará o back-end do aplicativo, que é composto por bancos de dados relacionais hospedados em VMs.
- A equipe de desenvolvimento interno criará a nova funcionalidade do negócio, que será exposta por novas APIs de HTTP.
- Uma equipe de desenvolvimento de contrato criará uma nova interface do usuário com base em navegador, que será hospedada no Azure.
Os novos recursos do aplicativo serão entregues em estágios. Esses recursos substituirão gradualmente a funcionalidade existente da interface do usuário cliente/servidor baseada em navegador (hospedada no local) que alimenta o negócio de comércio eletrônico atualmente.
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. A equipe pode usar o Gerenciamento de API do Azure para atender 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.
Considerações
Essas considerações implementam os pilares da Estrutura Bem Arquitetada do Azure, que é um conjunto de princípios orientadores que ajudam a melhorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.
Confiabilidade
A confiabilidade garante que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, consulte 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 diferentes regiões. 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 exibe as métricas para monitoramento por meio do Azure Monitor. Por exemplo, a métrica de capacidade pode ser usada para determinar a carga geral no recurso de Gerenciamento API e se são necessárias unidades de expansão adicionais. 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 custo
A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte 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 diretrizes detalhadas sobre as diferenças nesses níveis, consulte 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.
Observação
O nível Desenvolvedor pode ser usado para avaliação dos recursos do Gerenciamento de API. Não use-o para produção.
Para visualizar os custos projetados e personalizar as suas necessidades de implantação, você pode modificar o número de unidades de escala e de instâncias do Serviço do Aplicativo na calculadora de preços do Azure.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Autor principal:
- Ben Gimblett | Engenheiro sênior de clientes
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.
Próximas etapas
Documentação do produto:
Módulos do Learn:
- Explorar o Serviço de Aplicativo do Azure
- Implantar um site no Azure com o Serviço de Aplicativo do Azure
- Proteger suas APIs no Gerenciamento de API do Azure