Azure API Management is a fully managed service that enables customers to publish, secure, transform, maintain, and monitor APIs. With a few clicks in the Azure portal, you can create an API façade that acts as a “front door” through which external and internal applications can access data or business logic implemented by your custom-built backend services, running on Azure, for example on App Service or Azure Kubernetes Service, or hosted outside of Azure, in a private datacenter or on-premises. API Management handles all the tasks involved in mediating API calls, including request authentication and authorization, rate limit and quota enforcement, request and response transformation, logging and tracing, and API version management.
Starting today, Azure customers can choose the new Consumption tier when they are creating a new API Management instance. This Consumption tier, essentially a variant of API Management designed and implemented around serverless principles, will allow more customers to enjoy the benefits of API management, and will become a more organic fit for the emerging breed of applications built using serverless technologies.
APIM Consumption tier enables the following key use cases we have been hearing about from customers:
- API gateway for microservices implemented using serverless technologies such as Functions and Logic Apps.
- API gateway providing a simplified and secure façade for serverless Azure resources such as Service Bus queues and topics, Azure storage, and others.
- API gateway for traditional backends where API traffic has large spikes but stays low most of the time.
If any of the use cases above look relevant, we hope you would give the new tier a try and let us know what you think.
To understand the essence of the new tier let’s compare it with the existing ones.
API Management launched with just two tiers – Developer and Standard. Over the time we have added the Premium tier with high-end features for enterprise customers and the Basic tier as an entry-level production tier. All these tiers have a common architecture where each API Management service instance is assigned a set of resources reserved for its exclusive use. Security isolation, instantly available capacity, and protection from noisy neighbors are among the top benefits of this approach. However, they came with a few side effects - relatively high provisioning and scaling latencies and non-consumption-based pricing, which don’t fit well with the new breed of solutions based on the serverless application model.
Consumption tier uses the same underlying service components as the previous tiers but employs an entirely different architecture based on shared, dynamically allocated resources. Consequently, it aligns perfectly with serverless computing model, i.e., no infrastructure to manage, no idle capacity, high-availability, automatic scaling, and usage-based pricing, all of which make it an especially good choice for solutions that involve exposing serverless resources as APIs. There are a few tradeoffs involved when you choose the Consumption tier. The two most important are a curated feature set and enforced usage limits. The table below summarizes key points of comparison between the tiers.
|Consumption NEW||Developer | Basic | Standard | Premium|
|No infrastructure to provision or manage||No infrastructure to provision or manage|
|Built-in high availability||Built-in high availability1|
|Built-in auto-scaling (down to zero)||Manual or external auto-scaling2|
|Consumption-based micro billing||Billing based on reserved capacity|
|No reserved capacity||Reserved capacity|
|Shared resources||Dedicated resources|
|On-demand activation||Always on|
|Curated set of features||Full set of features3|
1With the exception of the Developer tier
2Azure Monitor Autoscale available in Standard and Premium tiers
3Availability of a few features varies across the tiers
The following two new features, now available only in the Consumption tier, will soon be available in the rest of the API Management tiers.
Bring Your Own Cache (BYOC): Response caching is an effective and widely used technique for both improving API latencies and reducing the load on API backends. This feature allows customers to configure API Management service to use an externally provisioned, Redis-compatible cache. Full control over cache configuration, the ability to preload and purge cache content, and ability to scale cache size independently from the API Management service instance that uses it, are the key benefits of BYOC. It is also the only option for enabling response caching in the Consumption tier because, unlike the other tiers, it doesn’t come with a built-in cache. We modified existing caching policies to work seamlessly with both integrated and external cache configurations.
More flexible subscriptions: Subscription is essentially a named container for a set of API keys (two to be exact - primary and secondary). Previously, subscriptions had to be owned by a user and supported a single, API product scope. To streamline key management, we've made a few changes. We now allow "standalone" subscriptions, not associated with a user. We also added two more subscription scopes - all APIs and a single API. So now it's possible, for example, to create keys granting access to an API (or all APIs within an API Management instance), without needing to create a product and add the API (or all APIs) to it first! Moreover, each API Management instance now comes with an immutable, all-APIs subscription, which makes it even more straightforward to test and debug APIs within the Test console.
We have been working on the Consumption tier since last spring and are very excited to finally share it with you. However, there is still work left to do, before we can call it done. Here are some important features and improvements you should expect to see over the coming months.
- Custom hostname and certificate
- "One-click" upgrade to a higher API Management tier
- Faster provisioning time (it’s already super-fast compared with older tiers, but we hope to improve it further)
- Reduced “cold start” latency (we haven’t done much in this area yet, and the latency is far from where it needs to be)
- Broad availability in the public Azure regions (we plan to have full the Consumption tier available in every region where API Management is available)
- “Add API” experiences for additional serverless and PaaS resources (expect to see new tiles on the Add API page)
We are excited to announce the immediate availability of the Consumption tier in preview in the North Central US, West US, West Europe, North Europe, Southeast Asia, and Australia East regions.
Want to learn more about how to build serverless APIs? Check out the webinar, “Build Serverless APIs with Node.js on Azure Functions.”