In this scenario, an e-commerce company in the travel industry migrates a legacy web application by using Azure API Management. The new UI will be hosted as a platform as a service (PaaS) application on Azure, and it will depend on both existing and new HTTP APIs. These APIs will ship with a better-designed set of interfaces, which will enable better performance, easier integration, and future extensibility.
Architecture
Download a Visio file of this architecture.
Workflow
- The existing on-premises web application 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.
- Inbound calls are made 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 (HTTPS or SSL).
- 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 allowlist within the corporate network perimeter.
- A new module is configured into the on-premises request pipeline for HTTP services (to act on only connections that originate externally). The pipeline validates a certificate that API Management provides.
- The new API:
- Is surfaced only through the API Management instance, which provides the API facade. The new API isn't accessed directly.
- Is developed and published as an Azure PaaS Web API app.
- Is configured (via settings for the Web Apps feature of Azure App Service) to accept only the API Management virtual IP.
- Is hosted in Web Apps with secure transport (HTTPS or SSL) turned on.
- Has authorization enabled, provided by Azure App Service via Microsoft Entra ID and OAuth 2.
- The new browser-based web application depends on the Azure API Management instance for both the existing HTTP API and the new API.
The API Management instance is configured 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/APIs and new APIs.
In the future, the project team will gradually port functionality to the new APIs and retire the original services. The team will handle these changes within API Management configuration, leaving the front-end UI unaffected and avoiding redevelopment work.
Components
Alternatives
If the organization plans to move its infrastructure entirely to Azure, including the virtual machines (VMs) that host the legacy applications, API Management is still a great option because it can act as a facade for any addressable HTTP endpoint.
If the organization had decided to keep the existing endpoints private and not expose them publicly, the organization's API Management instance could be linked to an Azure virtual network:
- In an Azure "lift and shift" scenario linked to a deployed Azure virtual network, the organization could directly address the back-end service through private IP addresses.
- In the on-premises scenario, the API Management instance could reach back to the internal service privately via an Azure VPN gateway and site-to-site IPSec VPN connection or Azure ExpressRoute. This scenario would then become 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 enable public access for some APIs while others remain internal. For more information, see Integrate API Management in an internal virtual network with Application Gateway.
The organization might decide to host its APIs on-premises. One reason for this change might be that the organization couldn't move downstream database dependencies that are in scope for this project to the cloud. If that's the case, the organization can still 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 back to Azure on an outbound socket. The first prerequisite is that self-hosted gateways can't be deployed without a parent resource in Azure, which carries an additional charge. Second, the Premium tier of API Management is required.
Note
For general information on connecting API Management to a virtual network, see this article.
Scenario details
An e-commerce company in the travel industry is modernizing its legacy browser-based software stack. Although the existing stack is mostly monolithic, some SOAP-based HTTP services exist from a recent project. The company is considering the creation of additional revenue streams to monetize some of the internal intellectual property that it has developed.
Goals for the project include addressing technical debt, improving ongoing maintenance, and accelerating feature development with fewer regression bugs. The project will use an iterative process to avoid risk, with some steps performed in parallel:
- The development team will modernize the application's back end, which consists of relational databases hosted on VMs.
- The in-house development team will write new business functionality that will be exposed over new HTTP APIs.
- A contract development team will build a new browser-based UI, which will be hosted in Azure.
New application features will be delivered in stages. These features will gradually replace the existing browser-based client/server UI functionality (hosted on-premises) that now powers 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 do this, they've decided to preserve their existing SOAP HTTP services. They also intend to minimize changes to the existing UI. They can use Azure API Management to address many of the project's requirements and constraints.
Potential use cases
This scenario highlights modernizing legacy browser-based software stacks.
You can use this scenario to:
- See how your business can benefit from using the Azure ecosystem.
- Plan for migrating services to Azure.
- Learn how a shift to Azure would affect existing APIs.
Considerations
These considerations implement the pillars of the Azure Well-Architected Framework, which is a set of guiding tenets that help improve the quality of a workload. For more information, see Microsoft Azure Well-Architected Framework.
Availability and scalability
- You can scale out Azure API Management by choosing a pricing tier and then adding units.
- Scaling can also happen automatically with autoscaling.
- Deploying across multiple regions enables failover options and can be done in the Premium tier.
- Consider Integrating with Azure Application Insights, which also surfaces metrics through Azure Monitor for monitoring.
Cost optimization
Cost optimization is about finding ways to reduce unnecessary expenses and improve operational efficiencies. For more information, see Overview of the cost optimization pillar.
API Management is offered in four tiers: Developer, Basic, Standard, and Premium. For detailed guidance on the differences in these tiers, see the Azure API Management pricing guidance.
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 for evaluation of the API Management features. Don't use it for production.
To view projected costs and customize to your deployment needs, you can modify the number of scale units and App Service instances in the Azure pricing calculator.
Deploy this scenario
To get started, create an Azure API Management instance in the portal.
Alternatively, you can choose from an existing Azure Resource Manager quickstart template that aligns to your specific use case.
Contributors
This article is maintained by Microsoft. It was originally written by the following contributors.
Principal author:
- Ben Gimblett | Senior Customer Engineer
To see non-public LinkedIn profiles, sign in to LinkedIn.
Next steps
Product documentation:
Learn modules:
- Explore Azure App Service
- Deploy a website to Azure with Azure App Service
- Protect your APIs on Azure API Management