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 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 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 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
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:
- Em um cenário de "lift and shift" do Azure vinculado a uma rede virtual do Azure implantada, a organização pode abordar 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 conexão VPN IPSec 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.
Nota
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 legada baseada em navegador. Embora a pilha existente seja principalmente monolítica, alguns serviços HTTP baseados em SOAP 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.
Disponibilidade e escalabilidade
- Você pode expandir o Gerenciamento de API do Azure escolhendo uma camada de preço e, em seguida, adicionando unidades.
- O dimensionamento também pode acontecer automaticamente com o dimensionamento automático.
- A implantação em várias regiões permite opções de failover e pode ser feita na camada Premium.
- Considere a Integração com o Azure Application Insights, que também apresenta métricas por meio do Azure Monitor para monitoramento.
Otimização de custos
A otimização de custos consiste em encontrar maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de 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.
Implementar este cenário
Para começar, crie uma instância de Gerenciamento de API do Azure no portal.
Como alternativa, você pode escolher entre um modelo de início rápido existente do Azure Resource Manager que se alinha ao seu caso de uso específico.
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