Are you migrating or building microservices on Azure and need an architectural solution for the API Management that meets your requirements? Here, in this article ,  I will talk about possible architectural solutions for the API Management in Hub and Spoke Architecture with relative advantages and disadvantages! 

What is the Azure API Management?

An API gateway sits between clients and services. It acts as a reverse proxy, routing requests from clients to services. It may also perform various cross-cutting tasks such as authentication, SSL termination, and rate limiting. 

A Gateway API decouples the clients from backend services and has several features that can be grouped into the following design patterns:

Gateway Offloading: Using the API Gateway you can offload the responsibilities of different features from individual services to the gateway, allowing you to centralize the management of cross-cutting concerns. So you can consolidate features like authentication and authorization in one place, rather than making each service responsible for implementing these.

Gateway Routing: You can use the Gateway API as a reverse proxy to route requests to different backend services using Layer 7 routing. This way you can provide a single endpoints for your microservices clients, decoupling clients from services.

Gateway Aggregation: Using the API Gateway you can aggregate many individual requests into a single request. The gateway then acts as a dispatcher addressing the requests to the various backend services providing the ability to manipulate and aggregate the results, then sending them to the client and reducing chattiness between client and backend.

What architectural solution can I use for my API Management?

Assumption.We assume that the only entry point from the Internet for our cloud infrastructure is the Application Gateway deployed in the HUB. But the focus of this article is on API Management and not on the possible configuration of the application Gateway 

Therefore in our considerations, we will take in analysis only the architectural configuration of the API Management leaving and ingoring therefore that of the AGW.

There are several possible API Management solutions that depend on your needs and requirements:

Shared API Management in HUB

Shared API Management with a dedicated Landing Zone

API Management dedicated to an application in application landing zone

Remember that the Azure API Management is a very expensive resource and is a very close resource for the development teams!

Shared API Management in HUB

Deploying Azure API Management to the Hub in a Hub and Spoke architecture can be motivated by different needs. Here are some common reasons:

Centralization and Control: The Hub becomes the single point of management for all of your organization’s APIs

Security and Compliance: Can improve security and ensure compliance with organization policies. You can apply easily centralized security, authentication, and authorization policies for all APIs in a consistent, hub-controlled manner.

Monitoring and analytics: Allows you to monitor and collect analytics on APIs in one place. This provides a global view of API requests, performance, and usage metrics. So, this setting increases visibility and control over API traffic of all applications.

Saving-costs. Thanks to the Shared API Management

However, there may be some drawbacks to consider:

May suffer for little separation of concerns: The API is a very close resource to development teams, as they need access to it to configure their own APIs and aggregation and routing logics. Placing it in the HUB would require that development teams have access to a resource in the HUB.

May be difficult to apply different security, authentication and authorization policies for different applications

Possible latency issues: we can have more network traffic, as all requests to APIs are routed through the HUB. This can impact all backend services of different applications.

In summary, deploying Azure API Management in the Hub offers benefits such as centralization, control, security and visibility, enabling organizations to efficiently manage their APIs in a distributed environment.

Shared API Management with a dedicated Landing Zone

Creating a dedicated Azure API Management Landing Zone may be necessary for several reasons. Here are some of the needs that may justify this choice:

Centralized API Management: Create a dedicated Landing Zone allows you to centralize the management of all APIs in a single dedicated environment.

Separation of responsibilities: Allow clear separation of responsibilities between API management and the network hub.

Isolation and Security: Provide an additional layer of isolation and security for APIs within the dedicated Landing Zone. Also, allow to apply easily centralized security, authentication, and authorization policies for all APIs in a consistent, hub-controlled manner.

Granular Control: Allow more specific control over API management for the dedicated Landing Zone.

Independent scalability: Enable scalability and independent management of the Management API for the dedicated Landing Zone.

Monitoring and Analytics: By creating a dedicated Landing Zone, you can focus the collection of monitoring and analysis data in a single area, simplifying metrics analysis and reporting.

Saving-costs thanks to the Shared API Management

However, there are some disadvantages to consider for this solution:

Additional complexity: Can introduce greater architectural complexity

Communication overhead: API requests must pass through the API Management Landing Zone and then reach backend services in their respective Landing Zones. This can result in increased delay and latency of requests.

Additional costs: Can request additional effort for the creation and management of the dedicated Landing Zone.

In summary, the creation of a Landing Zone dedicated to Azure API Management in a network that acts as a spoke to the hub, but as a hub compared to spokes that contain backend services, allows you to centralize the management of APIs, ensure security and scalability and improve API monitoring and analysis, while maintaining a clear separation of concerns between the HUB and the API Management.

API Management dedicated to an application in application landing zone

There can be several needs that can lead to deploying an Azure API Management in the spoke dedicated to the application that resides in the same spoke. Some common scenarios include:

Resource Isolation: If the application within a spoke requires a high degree of isolation for its resources and APIs, it may be preferable to have an API Management instance dedicated to that specific application in the same spoke. This ensures that resources and APIs are managed completely separately from other applications, improving resource management.

Performance and Latency: Having an instance of the Management API in the same application spoke can reduce latency and improve the performance of API requests. This can be beneficial in scenarios where performance and latency are critical, such as for traffic-intensive applications.

Autonomy and flexibility: Having an instance of Management API dedicated to the application spoke allows developers to have more autonomy and flexibility in managing their APIs. They can configure security policies, authentication, and authorization independently without depending on a single instance of the Management API.

Regulatory Compliance: In some situations, such as when you need to comply with application-specific regulations or regulations, you may need to have a dedicated API Management instance to ensure compliance. Management API in spoke can be configured specifically to meet application compliance requirements without having to extend these configurations to the entire Hub and Spoke architecture.

However, it is important to carefully assess the specific needs of the project and the trade-offs associated with this configuration. Managing multiple instances of API Management can lead to increased operational complexity and additional asset configuration and maintenance.

It is also important to consider the disadvantages of this solution:

Higher Costs: Azure API Management is already a very expensive resource. Devoting it to a specific application could lead to higher costs. It is therefore fundamental that these are gustificated by the criticality of the application.

Duplication of effort possible: As each spoke may have to implement the same security, authentication and authorization policies.

Lower visibility and API traffic control of all applications, as APIs are managed independently in each spoke.

Conclusion

In conclusion there is never a true and correct solution for everything. This depends on the needs and requirements of the organization, applications and projects.

However, it is true that the arrival of workspaces on the API Management simplifies the management and separation of permissions on the Management API between different development teams.