Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
In this scenario, an e-commerce company in the travel industry migrates a legacy web app by using Azure API Management. The company hosts the new UI as a platform as a service (PaaS) app on Azure. The new UI depends on both existing and new HTTP APIs. These APIs deploy with more effectively designed interfaces that improve performance, simplify integration, and allow future extensibility.
Architecture
Download a Visio file of this architecture.
Workflow
The following workflow corresponds to the previous diagram:
The existing on-premises web app continues to directly consume the existing on-premises web services.
Calls from the existing web app to the existing HTTP services remain unchanged. These calls are internal to the corporate network.
API Management makes calls from Azure to the existing internal services.
The security team allows traffic from the API Management instance to pass through the corporate firewall to the existing on-premises services by using secure transport protocols like Hypertext Transfer Protocol Secure (HTTPS) over Transport Layer Security (TLS).
The operations team allows inbound calls to the services only from the API Management instance. It meets this requirement by adding the IP address of the API Management instance to the allow list within the corporate network perimeter.
A new module in the on-premises request pipeline for Hypertext Transfer Protocol (HTTP) services acts only on connections that originate externally. The pipeline validates a certificate that API Management provides.
The new API has the following characteristics:
Only the API Management instance, which provides the API facade, surfaces the new API. You don't directly access the new API.
You develop and publish the new API as an Azure PaaS web API app.
You set up the new API by using the settings for the Web Apps feature of Azure App Service to accept only the API Management virtual IP (VIP).
Web Apps hosts the new API with secure transport protocols like HTTPS or TLS turned on.
Azure App Service provides authorization capabilities via Microsoft Entra ID and Open Authorization (OAuth) 2.
The new browser-based web app depends on the API Management instance for both the existing HTTP API and the new API.
The travel e-commerce company can direct some users to the new UI for preview or testing while preserving the old UI and existing functionality side by side.
Set up the API Management instance to map the legacy HTTP services to a new API contract. In this configuration, the new web UI is unaware of the integration with a set of legacy services or APIs and new APIs.
In the future, the project team can gradually move functionality to the new APIs and retire the original services. The team handles these changes within the API Management configuration, leaving the front-end UI unaffected and avoiding redevelopment work.
Components
API Management is a management platform and gateway for APIs across all environments. In this architecture, it serves as a facade for the existing legacy APIs and the new APIs. The new client app consumes a single consistent interface, and the team can modernize legacy back ends incrementally behind that facade with minimal impact on front-end development.
App Service is a turnkey PaaS solution for web hosting that provides out-of-the-box features like security, load balancing, autoscaling, and automated management. In this architecture, App Service provides flexible turnkey hosting so that the DevOps team can focus on feature delivery.
Alternatives
If the organization plans to move its infrastructure, including the virtual machines (VMs) that host the legacy apps, entirely to Azure, API Management can serve as a facade for any addressable HTTP endpoint.
If the organization keeps the existing endpoints private and doesn't expose them publicly, the organization's API Management instance can link to an Azure virtual network.
When API Management is linked to an Azure virtual network, the organization can directly address the back-end service through private IP addresses.
In the on-premises scenario, the API Management instance can connect to the internal service privately via Azure VPN Gateway and a site-to-site Internet Protocol Security (IPsec) VPN connection or Azure ExpressRoute. This scenario then becomes a hybrid of Azure and on-premises.
The organization can keep the API Management instance private by deploying it in internal mode. The organization can then use deployment with Azure Application Gateway to allow public access for some APIs while others remain internal. For more information, see Integrate API Management in an internal virtual network by using Application Gateway.
The organization might decide to host its APIs on-premises. One reason for this change might be that the organization can't move downstream database dependencies that are in scope for this project to the cloud. In this scenario, the organization can take advantage of API Management locally by using a self-hosted gateway.
The self-hosted gateway is a containerized deployment of the API Management gateway that connects to Azure on an outbound socket. To use self-hosted gateways, you must meet the following prerequisites:
You must deploy self-hosted gateways by using a parent resource in Azure, which adds extra cost.
You must use the Premium tier of API Management.
Scenario details
An e-commerce company in the travel industry wants to modernize its legacy, browser-based software stack. The existing stack is mostly monolithic, but some Simple Object Access Protocol (SOAP)-based HTTP services exist from a recent project. The company considers the creation of extra revenue streams to monetize some of its internal intellectual property.
Goals for the project include addressing technical debt, ongoing maintenance improvements, and feature development acceleration with fewer regression bugs. The project uses an iterative process to avoid risk and does the following steps in parallel:
The development team modernizes the app's back end, which consists of relational databases hosted on VMs.
The in-house development team writes new business functionality and exposes it over new HTTP APIs.
A contract development team builds a new browser-based UI, which Azure hosts.
The company delivers new app features in stages. These features gradually replace the existing browser-based client and server UI functionality hosted on-premises that power the company's e-commerce business.
Members of the management team don't want to modernize unnecessarily. They also want to maintain control of scope and costs. To achieve these goals, they decide to preserve their existing SOAP HTTP services. They also intend to minimize changes to the existing UI. They can use API Management to address many of the project's requirements and constraints.
Potential use cases
This scenario highlights how to modernize legacy, browser-based software stacks.
You can use this scenario for the following tasks:
- See how your business can benefit from using the Azure ecosystem.
- Plan a service migration to Azure.
- Learn how a shift to Azure might affect existing APIs.
Considerations
These considerations implement the pillars of the Azure Well-Architected Framework, which is a set of guiding tenets that you can use to improve the quality of a workload. For more information, see Well-Architected Framework.
Reliability
Reliability helps ensure that your application can meet the commitments that you make to your customers. For more information, see Design review checklist for Reliability.
Activate availability zones when you deploy your API Management instance. The option to deploy API Management into availability zones is only available in the Premium service tiers.
Use availability zones that have extra gateway instances deployed to different regions. This combination improves service availability if one region goes offline. Multiregion deployment is only available in the Premium service tier.
Integrate with Application Insights, which surfaces metrics through Azure Monitor for monitoring. For example, you can use the capacity metric to determine the overall load on the API Management resource and whether you need more scale-out units. Track resource capacity and health to improve reliability.
Ensure that downstream dependencies, such as the back-end services that host the APIs that API Management covers, are also resilient.
Cost Optimization
Cost Optimization focuses on ways to reduce unnecessary expenses and improve operational efficiencies. For more information, see Design review checklist for Cost Optimization.
API Management has eight tiers:
- Consumption
- Developer
- Basic and Basic v2
- Standard and Standard v2
- Premium and Premium v2
For more information about the differences in these tiers, see API Management pricing.
You can scale API Management by adding and removing units. Each unit has capacity that depends on its tier.
Note
You can use the Developer tier to evaluate API Management features. Don't use it for production.
To view projected costs for your deployment needs, you can modify the number of scale units and App Service instances in the Azure pricing calculator.
Contributors
Microsoft maintains this article. The following contributors wrote this article.
Principal author:
- Ben Gimblett | Senior Customer Engineer
Other contributor:
- Andrew Cardy | Senior Software Engineer
To see nonpublic LinkedIn profiles, sign in to LinkedIn.
Next steps
- App Service overview
- API Management overview
- Set up staging environments in App Service
- Transform and protect your API
- Explore App Service