Edit

Share via


Migrate a web app by using Azure API Management

Azure API Management
Azure Monitor
Azure App Service

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

Diagram that shows the steps to migrate a web app by using API Management.

Download a Visio file of this architecture.

Workflow

The following workflow corresponds to the previous diagram:

  1. The existing on-premises web app continues to directly consume the existing on-premises web services.

  2. Calls from the existing web app to the existing HTTP services remain unchanged. These calls are internal to the corporate network.

  3. API Management makes calls from Azure to the existing internal services.

  4. The new API has the following characteristics:

  5. The new browser-based web app depends on the API Management instance for both the existing HTTP API and the new API.

  6. 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.

  • 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:

Other contributor:

To see nonpublic LinkedIn profiles, sign in to LinkedIn.

Next steps