Microsoft’s API management service just passed 10 years, 35,000 customers, and 2 million managed APIs. What have we learned, and what’s in store for the future?
API management was important a decade ago; it’s now essential. Cloud-native development models use APIs to link microservices into distributed applications, with some services used by more than one application in different ways.
By putting in an API management layer, operations teams can decide how applications use those APIs, using controls to ensure fair access. They also help secure APIs, using role-based access controls to lock down access to only approved users and applications. These tools also help allow access to third-party services, adding cost controls alongside their other management functions.
More than controlling code
It’s not only our code that needs managing. Modern agentic AI services use APIs to access data, and we need to be sure that access is tightly regulated so that critical and sensitive information doesn’t leak outside the organization. At the same time, we need to control access to AI services, reducing the risk of prompt injection attacks while carefully watching the costs associated with overly complex prompts.
One other benefit of API management tools is that they act as a unifying layer, bringing together all the APIs you use in a single gateway, redirecting calls as needed. This gives you a translation layer with a common API syntax for all your code, rather than having to mix gRPC, REST, GraphQL, SOAP, and more. This approach can speed up application delivery and allow you to switch out the underlying APIs for new versions or for tools from alternate vendors.
Some of the supported technologies are ones we might think of as legacy technologies, but a lot of legacy programs are still in use in large enterprises. Legacy support helps sell the service, helping upgrade services without affecting the underlying stack. API management brings all these features into one pane of glass, controlling your API usage across premises and multiple clouds, as well as third-party applications and services.
A decade of managing APIs
Microsoft’s Azure API Management service recently celebrated its 10th anniversary. I’ve been looking back at what it’s been used for and looking forward to how it can help with the next generation of applications. I spoke to Vladimir Vinogradsky, principal group program manager at Microsoft about the evolution of the platform, from its early days to today’s comprehensive API tool.
The underlying numbers are impressive: more than 35,000 customers, 2 million managed APIs, and 2.2 trillion calls a month, with significant yearly growth across all three metrics. Vinogradsky attributes this to being customer-led. He says, “You wouldn’t believe the amount of time the team spends interacting with customers directly, working with our field teams to understand customer concerns, customer scenarios.” That is a more complex task than it first seems, as it requires translating customer conversations about missing features to actual customer needs, understanding what they are trying to do with APIs in their business.
This approach has allowed the service to add new features to its underlying gateway architecture. Vinogradsky notes, “We added support for expressions with which you can now conditionally execute, parameterize, and customize built-in policies which essentially exponentially improved the power and flexibility of the gateway right to the degree that customers can use it for a lot of things that we didn’t even think were possible.”
Azure API Management is competitively priced, with a mix of tiers that target different use cases, from developers experimenting with the service to organizations using it to securely handle millions of transactions every day. There’s even a serverless consumption tier that gives you a million free calls a month, which is an attractive option for small and medium enterprises that want to control internal API usage.
As well as working as part of your Azure infrastructure, Azure API Management offers a self-hosted gateway that works anywhere, giving you one pane of glass where you can manage all your APIs, in Azure, on premises, or even on other clouds like AWS. This is available as a Docker container and can be run using Docker on a host server or even as part of a Kubernetes cluster. Self-hosted gateways do need connectivity to Azure, as they check in regularly with the API Management service, updating configurations in near real time.
Aggregating APIs in GraphQL
One interesting new feature is support for synthetic GraphQL APIs. This approach allows you to map existing legacy APIs to a modern GraphQL instance, offering a single endpoint for your data using a GraphQL schema. While you’re working with existing APIs, Azure API Management treats this as creating a new API definition. You need to start with a GraphQL schema for your planned API, which is imported into the Azure API Management portal. Other prerequisites include a fallback API endpoint and a base URL for your synthetic API.
Once your API has been created, you can start to define resolvers. These are how you map a GraphQL resource to an existing API. Next you need to define the data being returned and the URL of the endpoint being used, as well as the type of request you’re making. Azure API Management includes the ability to test APIs from the portal. This has the benefit of retrofitting security features to APIs that may not have the right protection for a modern application. There’s also the option to add further security with Microsoft Defender for APIs.
Developers writing code to use these synthetic APIs now must work with the GraphQL schema you’ve defined, accessing it through a single endpoint. This simplifies application development, reducing the risks involved with accessing multiple APIs and allowing architects to establish appropriate coding standards and other guardrails. Using the Azure API Management portal to test calls before writing code also helps ensure that you are using the right API, no matter the underlying technology.
Using Azure API Management with Dapr
With API management being key to the success of cloud-native application development, it’s interesting to note support for Dapr in Azure API Management. This uses the self-hosted API gateway along with a Dapr sidecar to manage access to APIs running a Dapr-based Kubernetes application. These API gateways run in their own containers, outside of your application pods, using Dapr to route API calls to and from your application. This manages your APIs without exposing any public interfaces.
As with all Azure API Management instances, these gateway containers are managed from the same Azure-hosted control panel. As Dapr uses OpenAPI definitions, mapping its APIs to Azure-managed APIs is relatively simple. Once the API has been mapped, you can apply policies. You can use the useful ability to push policy configurations to the self-hosted gateway in your Dapr environment to update the system on the fly, for example, switching a back-end service for an updated version without affecting users.
API management goes beyond policies, and Microsoft has been working on additional features that complement the familiar management tool. One option simplifies creating policies, as Azure API Management is now part of Microsoft Copilot for Azure. This allows inexperienced users to automate creating new API policies. You can use the resulting AI-generated policies to help learn how to use the service, showing Azure CLI commands that were defined by your intent.
Another possibility is Azure API Center, which provides one place to manage the metadata for all your APIs. It’s a relatively new feature and works not only with Azure API Management, but also repositories like GitHub. There are plans to expand to other sources of information about your APIs. This approach allows APIs to be assessed, using linting tools, to determine if they’re well formed. These tools can also help reduce API sprawl at the same time by using it to deduplicate efforts. Vinogradsky says, “Why would we build an API if it already exists somewhere? Maybe we should use it. And if it’s not sufficient quality, we should maybe invest in it.”
APIs are built by developers and consumed by developers, so it’s good to see Microsoft thinking about how we both catalog and discover APIs, as well as implementing a devops process around them. Building on the work done with Azure API Management makes a lot of sense—after all, there’s a decade of experience to use as a foundation for the next decade.
