Neste cenário, uma empresa de comércio eletrónico no setor de viagens migra uma aplicação Web legada com a Gestão de API do Azure. A nova interface do usuário será hospedada como um aplicativo de plataforma como serviço (PaaS) no Azure e dependerá das APIs HTTP existentes e novas. Essas APIs serão fornecidas com um conjunto de interfaces mais bem projetado, o que permitirá um melhor desempenho, integração mais fácil e extensibilidade futura.
Arquitetura
Baixe um arquivo Visio desta arquitetura.
Fluxo de Trabalho
- O aplicativo Web local existente continua a consumir diretamente os serviços Web locais existentes.
- As chamadas do aplicativo Web existente para os serviços HTTP existentes permanecem inalteradas. Essas chamadas são internas à rede corporativa.
- As 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 de Gerenciamento de API passe pelo firewall corporativo para os serviços locais existentes usando transporte seguro (HTTPS ou SSL).
- A equipe de operações permite chamadas de entrada para os serviços somente da instância de Gerenciamento de API. Ele atende a esse requisito adicionando o endereço IP da instância de Gerenciamento de API à lista de permissões dentro do perímetro da rede corporativa.
- Um novo módulo é configurado no pipeline de solicitação local para serviços HTTP (para atuar somente em conexões originadas externamente). O pipeline valida um certificado fornecido pelo Gerenciamento de API.
- A nova API:
- É exibido somente por meio da instância de Gerenciamento de API, que fornece a fachada da API. A nova API não é acessada diretamente.
- É desenvolvido e publicado como um aplicativo de API Web PaaS do Azure.
- Está configurado (por meio de configurações para o recurso Aplicativos Web do Serviço de Aplicativo do Azure) para aceitar apenas o IP virtual ( VIP) de Gerenciamento de API.
- Está hospedado 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 Open Authorization (OAuth) 2.
- 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.
- A empresa de comércio eletrônico de viagens agora pode direcionar alguns usuários para a nova interface do usuário (para visualização ou teste), preservando a interface do usuário antiga e a funcionalidade existente lado a lado.
A instância de Gerenciamento de API é configurada para mapear os serviços HTTP herdados para um novo contrato de API. Nessa configuração, a nova interface do usuário da Web não está ciente da integração com um conjunto de serviços/APIs herdados e novas APIs.
No futuro, a equipe do projeto irá gradualmente portar a funcionalidade para as novas APIs e aposentar os serviços originais. A equipe lidará com essas alterações dentro da configuração do Gerenciamento de API, deixando a interface do usuário front-end não afetada e evitando o trabalho de redesenvolvimento.
Componentes
- O Gerenciamento de API do Azure abstrai APIs de back-end, além de adicionar funcionalidade e descoberta transversais para desenvolvedores e aplicativos. Nesse 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 fachada das APIs existentes e novas, é possível que os desenvolvedores modernizem os backends herdados por trás da fachada do Gerenciamento de API de forma iterativa e com impacto mínimo a zero no novo desenvolvimento front-end.
- O Serviço de Aplicativo do Azure é um serviço de plataforma como serviço (PaaS) pronto para uso 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, pois fornece hospedagem turn-key flexível, 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 máquinas virtuais (VMs) 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 tivesse decidido manter os pontos de extremidade existentes privados e não expô-los publicamente, a instância de Gerenciamento de API da organização poderia 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 endereçar diretamente o serviço back-end por meio de endereços IP privados.
- No cenário local, a instância de Gerenciamento de API pode retornar ao serviço interno de forma privada por meio de um Gateway de VPN do Azure e uma conexão VPN IPSec (Internet Protocol Security) site a site ou Rota Expressa do Azure. Esse cenário se tornaria um híbrido do Azure e local.
A organização pode manter a instância de Gerenciamento de API privada implantando-a no modo interno. 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 Application Gateway.
A organização pode decidir hospedar suas APIs localmente. Uma razão para essa alteração pode ser que a organização não pôde mover as dependências de banco de dados downstream que estão no escopo deste projeto para a nuvem. Se esse for o caso, a organização ainda pode aproveitar o Gerenciamento de API localmente usando um gateway auto-hospedado.
O gateway auto-hospedado é uma implantação em contêiner do gateway de 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 carrega uma cobrança adicional. Em segundo lugar, a camada Premium do Gerenciamento de API é necessária.
Detalhes do cenário
Uma empresa de comércio eletrônico no setor de viagens está modernizando sua pilha de software legada baseada em navegador. Embora a pilha existente seja principalmente monolítica, alguns serviços HTTP baseados em SOAP (Simple Object Access Protocol) existem a partir de um projeto recente. A empresa está considerando a criação de fluxos de receita adicionais para monetizar parte da propriedade intelectual interna que desenvolveu.
Os objetivos do projeto incluem lidar com a dívida técnica, melhorar a manutenção contínua e acelerar o desenvolvimento de recursos com menos bugs de regressão. O projeto utilizará um processo iterativo para evitar riscos, com algumas etapas executadas em paralelo:
- A equipe de desenvolvimento modernizará o back-end do aplicativo, que consiste em bancos de dados relacionais hospedados em VMs.
- A equipe de desenvolvimento interna escreverá novas funcionalidades de negócios que serão expostas por meio de novas APIs HTTP.
- Uma equipe de desenvolvimento de contrato criará uma nova interface do usuário baseada em navegador, que será hospedada no Azure.
As novas funcionalidades da aplicação serão entregues por fases. Esses recursos substituirão gradualmente a funcionalidade de interface do usuário cliente/servidor baseada em navegador existente (hospedada localmente) que agora alimenta o negócio de comércio eletrônico da empresa.
Os membros da equipa de gestão não querem modernizar-se desnecessariamente. Eles também querem manter o controle do escopo e dos custos. Para fazer isso, eles decidiram preservar seus serviços HTTP SOAP existentes. Eles também pretendem minimizar as alterações na interface do usuário existente. Eles podem usar o Gerenciamento de API do Azure para abordar muitos dos requisitos e restrições do projeto.
Potenciais casos de utilização
Este cenário destaca a modernização de pilhas de software herdadas baseadas em navegador.
Você pode usar este cenário para:
- Veja como a sua empresa pode beneficiar da utilização do ecossistema do Azure.
- Planeje a migração de serviços para o Azure.
- Saiba como uma mudança para o Azure afetaria as APIs existentes.
Considerações
Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que ajudam a melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.
Fiabilidade
A confiabilidade garante que seu aplicativo possa atender aos 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 de 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 em várias regiões também só está disponível 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 faz, também sejam resilientes.
Otimização de custos
A otimização de custos consiste em procurar formas de reduzir 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 é oferecido em quatro níveis: Desenvolvedor, Básico, Standard e Premium. Para obter orientações detalhadas sobre as diferenças nessas camadas, consulte as diretrizes de preços do Gerenciamento de API do Azure.
Você pode dimensionar o Gerenciamento de API adicionando e removendo unidades. Cada unidade tem a capacidade estabelecida pelo respetivo escalão.
Nota
Você pode usar a camada de desenvolvedor para avaliar os recursos de gerenciamento de API. Não o use 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.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Autor principal:
- Ben Gimblett - Brasil | Engenheiro de Clientes Sênior
Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.
Próximos passos
Documentação do produto:
Aprenda módulos:
- Explore o Serviço de Aplicativo do Azure
- Implantar um site no Azure com o Serviço de Aplicativo do Azure
- Proteja suas APIs no Gerenciamento de API do Azure