In this 2-part article, I will be describing my experience supporting one of the Microsoft Azure PaaS services in the past one year. February 2021 when I returned from Ghana where I worked with Globacom (as a Data Services Integration Engineer), I had the opportunity to join one of the Microsoft vendors, Tek Experts. I joined Tek as a Technical Support Engineer supporting Azure API Management service globally. A typical day at Tek Experts had me providing top-notch technical support, to Microsoft Azure customers across the globe, using variety of debugging, internal tools, research, processes, detailed error reporting, and documentation. It was a very challenging but yet interesting experience. How possible? Yeah, kindly follow me as I explain this interesting experience of mine.
I would like to start off by briefly describing the Azure API Management service. Therefore, part one of this article will be dedicated to its description while the other part will be used to dissect my experiences supporting this interesting and business-innovative service by Microsoft Azure.
Azure API Management (APIM) service is one of the PaaS offerings by Microsoft Azure and it is a way to create consistent and modern API gateways for existing back-end services just like Amazon API Gateway and Google Cloud Apigee - the exact equivalent services from the other two Cloud giants, AWS and Google Cloud.
With Azure APIM service, organizations and businesses can publish APIs (hosted on Azure, on-premises, and in other clouds) to external, partner, and internal developers to unlock the potential of their data and services. With it comes the core competencies to ensure a successful API program through developer engagement, business insights, analytics, security, and protection. Essentially, you can use Azure APIM to launch a full-fledged API program based on any backend.
How Azure APIM Service is Used
- Organization/Businesses use case: Administrators create APIs in API Management service (from Azure portal, CLI, Powershell, or ARM templates). Each API consists of one or more operations, and each API can be added to one or more products.
- Partners/Developers/External use case: Developers/External consumers subscribe to a product that contains that API, and then they can call the API's operation(s), subject to any usage policies that may be in effect.
Based on the above two use cases below are the common usage scenarios:
- Securing mobile infrastructure by gating access with API keys, preventing DOS attacks by using throttling, or using advanced security policies like JWT token validation.
- Enabling ISV partner ecosystems by offering fast partner onboarding through the developer portal and building an API facade to decouple from internal implementations that are not ripe for partner consumption.
- Running an internal API program by offering a centralized location for the organization to communicate about the availability and latest changes to APIs, gating access based on organizational accounts, all based on a secured channel between the API gateway and the backend.
Components of APIM Service
Basically, I will be explaining the APIM system's main components and features. As an organization utilizing the APIM service in your business operations, the APIM system is made up of familiar components as highlighted below:
- The API Gateway:
This accepts API calls and verifies API keys, JWT tokens, certificates, and other credentials while routing the calls to your backends. The gateway can also enforce usage quotas and rate limits, transforms your API on the fly without code modifications, caches backend responses (where set up), and logs calls metadata for analytics purposes.
- The Azure portal:
If you are familiar with Azure Cloud, this will not be any strange. It is simply the administrative interface where organizations or businesses set up their API program (and of course, other Azure Cloud services). With respect to APIM service, the Azure portal is used to define or import API schema, package APIs into products, set up policies like quotas or transformations on the APIs. The Azure portal can also be used to manage users (API consumers) and retrieve insights from analytics.
- The Developer portal:
This particular portal is different from the general Azure portal in that it serves as the main web presence for developers (customers/partners). Prospective customers can visit the developer portal, learn about your APIs (API documentation), and view APIs and operations. If they would like to use your APIs, they then create an account and subscribe to get API keys, view & call operations, as well as subscribe to products - interactive console. Customers can also get to access analytics on their own usage. The URL for APIM service developer portal is located on the dashboard in the Azure portal for your API Management service instance.
You can customize the look and feel of your developer portal by adding custom content, customizing styles, and adding your branding.
Below are the elements that make up the APIM service operations
- API and operations
As stated earlier, an API in Azure APIM service represents a set of operations available to developers. Each API contains a reference to the back-end service that implements the API, and its operations map to the operations implemented by the back-end service. APIM offers so much flexibility to configure operations for extensive business needs and requirements, with control over URL mapping, query and path parameters, request and response content, and operation response caching. Rate limit, quotas, and IP restriction policies can also be implemented at the API or individual operation level. You can get more information on how to create APIs and add operations to an API in Azure APIM service.
- Products
Products in APIM are how APIs are surfaced to developers. Products have one or more APIs, and are configured with a title, description, and terms of use. Products can be Open or Protected. Protected products must be subscribed to before they can be used, while open products can be used without a subscription. Product has to be published before it can be viewed (and in the case of protected products subscribed to) by developers. Subscription approval is configured at the product level and can either require administrator approval, or be auto-approved.
- Groups
Groups are used to manage the visibility of products to developers. Products grant visibility to groups, and developers can view and subscribe to the products that are visible to the groups in which they belong. API Management has the following immutable system groups:
- Administrators: Azure subscription administrators are members of this group. Administrators manage API Management service instances, creating the APIs, operations, and products that are used by developers.
- Developers - Developers are the customers that build applications using your APIs. In other words, they are authenticated developer portal users that are granted access to the developer portal and build applications that call the operations of an API.
- Guests - This is a group of unauthenticated developer portal users, such as prospective customers visiting the developer portal of an APIM instance. They can be granted certain read-only access, such as the ability to view APIs but not call them. In addition to these system groups, administrators can create custom groups or leverage external groups in associated Azure Active Directory tenants.
- Developers
Developers represent the user accounts in an API Management service instance. Developers can be created or invited to join by administrators, or they can sign up from the Developer portal. Each developer is a member of one or more groups, and can subscribe to the products that grant visibility to those groups.
When developers subscribe to a product, they are granted the primary and secondary key for the product. This key is used when making calls into the product's APIs.
- Policies
Policies are a powerful capability of API Management that allow the Azure portal to change the behavior of the API through configuration. Policies are a collection of statements that are executed sequentially on the request or response of an API. Popular statements include format conversion from XML to JSON and call rate limiting to restrict the number of incoming calls from a developer, and many others.
You can use policy expressions as attribute values or text values in any of the APIM policies, unless the policy specifies otherwise. Some policies such as the Control flow and Set variable policies are based on policy expressions. You can get more information about Advanced policies and Policy expressions
For a complete list of API Management policies, see Policy reference
Pricing Tiers of APIM Service
I will only be highlighting the features availbale in the various pricing tiers, to know more about the costing perse, kindly go to API Management pricing.
1. Consumption Tier
This is a lightweight and serverless version of API Management service, billed per execution. The service is hosted on shared platform in Azure App service and scales automatically depending on usage.
2. Developer Tier
This tier is for non-production use cases and evaluations. It has no SLA and cannot be scaled out as it has just one unit(One VM). Developer tier supports Azure VNet integration, multiple custom domain names, and self-hosted gateway.
3. Basic Tier
This tier is for entry-level production use cases and can be scaled to 2 units. It does not support Azure VNet integration.
4. Standard Tier
This tier is for medium-volume production use cases and can be scaled out to 4 units. It does not support Azure VNet integration.
5. Premium Tier
This tier is for high-volume or enterprise production use cases. It supports multi-region deployments and can be scaled out to 12 units by default. It supports Azure VNet integration, multiple custom domain names, and self-hosted gateway.
6. Isolated Tier
Although this tier is still in preview, it is a very large scale tier that is used for enterprise production use cases requiring high degree of isolation. It has its own compute resources (compute isolation). It supports multi-region deployments and can be scaled out to 12 units by default. It supports Azure VNet integration, multiple custom domain names, and self-hosted gateway.
An article cannot of course explicitly describe the APIM service, if you really find this service interesting, you can check more about it in the official documentation by Microsoft using the links above.
Catch up with the part two of this article describing how I handled the challenges, some typical support scenarios and highlights of the solutions.