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 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 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
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:
- Em um cenário de "lift and shift" do Azure vinculado a uma rede virtual do Azure implantada, a organização pode endereçar diretamente o serviço back-end por meio 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.
Observação
Para obter informações gerais sobre como conectar o Gerenciamento de API a uma rede virtual, consulte este artigo.
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.
Disponibilidade e escalabilidade
- É possível escalar horizontalmente o Gerenciamento de API do Azure escolhendo um tipo de preço e, em seguida, adicionando as unidades.
- A escala também pode ocorrer automaticamente com o dimensionamento automático.
- A implantação em várias regiões possibilita opções de failover e pode ser realizada no nível Premium.
- Considere a Integração com o Azure Application Insights, que também exibe as métricas para monitoramento por meio do Azure Monitor.
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, confira Visão geral do pilar de otimização de custo.
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.
Implantar este cenário
Para começar, crie uma instância de Gerenciamento de API do Azure no portal.
Como alternativa, é possível escolher um modelo de início rápido existente do Azure Resource Manager que se encaixa no seu caso de uso específico.
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