1. Miao Jiang
Senior Program Manager - Microsoft
API Management Overview

2. Quick Survey

3. The Rise of APIs Technology landscape is more distributed than ever
On-prem, cloud, SaaS, edge, mobile
APIs started on the periphery and moved to the core of enterprise IT
As technology for building APIs got better and expertise became available more broadly
Now the default way of exposing services and data
HTTP, JSON, OpenAPI, OAuth
Key business driver – API economy
Customer loyalty, satisfaction, growth ecosystems, agility
Well-suited for ad-hoc integration
Due to standards, common patterns, and tools
API-aware workflow/orchestration products accelerate time to value
Rapid, no/low-code solution development
Subject to network effects
Every additional API increases the value of the rest

4. The Rise of APIs TechReady 23 1/1/2019 1:57 AM
© 2016 Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

5. “APIs make digital society and digital business work; they are the basis of every digital strategy.”
From the Gartner research note “Top 10 Things CIOs Need to Know About APIs and the API Economy”
By Paolo Malinverno, Kristin R. Moyer, Mark O'Neill, Mike Gilpin
Published 25 January 2017

6. API Management Consume Publis h Mediate Abstract Discover
1st and 3rd party apps
Abstract
Secure & protect
Manage lifecycle
Monitor & measure
Onboard developers
Monetize
Discover
Learn
Get access
Try
Get help
SDKs and samples
Consume
Publis h
Mediate
Azure portal
Gateway
Developer portal
App developers
API managers and developers
APIs hosted on and outside of Azure

7. There is a policy for that
Encapsulate common API management functions
Access control, Protection, Transformation, Caching, …
Chained together into a pipeline
Mutate request context or change API behavior
Set in the inbound and outbound directions
Can be triggered on error
Applied at a variety of scopes

8. Policy expressions Named values C# “snippets” used with policies
Read-only access to the request context
Can use whitelisted .NET types
Dynamically configure and conditionally execute policies
Shared across APIM instance
Keep secrets and “magic” strings out of policies
Add semantics, if named well
Enable a single point of change
Provide environment-specific values

9. Customers Instances Calls APIs Growth +50% +65% +530% +244% Total
(trailing 12 months)
+50%
+65%
+530%
+244%
Total
(as of May 20)
10.5K
17.4K
77B
112K

10. Customer use cases Enterprise API catalog
Customer and partner integration
Mobile enablement and IoT
APIs as a business
Gateway for microservices

11. API Management – Recent features and announcements
Generally available in 2 regions in China
Generally available in 6 US Gov regions
Azure Application Insights integration
e2e request/response tracing
Rich querying for debugging
Real-time reports
Entity tags in the admin and developer portals
Filter, search, group operations, APIs and products
Versions and revisions
Capacity metric and auto scale
Azure Key Vault integration

12. Demo

13. We just scratched the surface
40 policies - security, transformations, traffic management, extensibility
SOAP and SOAP to REST
API publishing with products, users and groups
VNET support for external and internal use cases
Multi-region deployment topologies for high-availability and performance
Capacity metric and auto scale
Azure Monitor metrics, logs and alerts
Analytics and Power BI template
Azure AD and Azure AD B2C integration
Developer portal customization …

14. Stay in touch Questions and discussions
Service updates, among other things
GitHub repo with sample policies
Tutorial, documentation, and references
Feedback and feature requests
Roadmap
Customer stories

15. Regional availability
30 public regions in Americas, Europe, Asia and Australia
6 USGov regions and 2 regions in China

16. Appendix How many of you are actually using APIM?
How many of you have heard of APIM?
How many of you think that APIs are valuable?

17. Multi-region topologies

18. Multi-region topologies
Secondary
region
Primary
region

19. Multi-region topologies
Secondary
region
Primary
region

20. Multi-region topologies
Secondary
region
Primary
region
Shared state
Hint: use <choose> to <set-backend> policy based on context.Deployment.Region

21. Multi-region topologies
Secondary
region
Primary
region
Shared state

22. Multi-region topologies
Secondary
region
Primary
region
Shared state

23. Policy scopes global GET /foo/bar HTTP/1.1 Host: api.constoso.com
Key:
global
CORS
LOG
product
RATE
QUOTA
from caller
to backend
inbound
api
/foo
JWT
operation
/bar
CACHE
URL
BODY
to caller
from backend
outbound

24. Façade and front door Developer portal Gateway Azure portal Consume
App developers
Gateway
Mediate
contosoapi-foo.azurewebsites.com
1st and 3rd party apps
Azure portal
APIs on Azure and outside
Publish
API managers and developers

25. Façade and front door Gateway Mediate 1st and 3rd party apps
contosoapi-foo.azurewebsites.com
1st and 3rd party apps
api.contoso.com/foo
contoso.azure-api.net/foo
contosoapi-bar.azurewebsites.com

26. Versions and revisions
No one true way
Version or not?
Semantic versioning?
What is a breaking change?
Where to place version information?
Path? Query? Header? Media type?
How to identify version?
Number? Date? Name?
Approach
Versioning is an opt-in
Natively understand versions at the system level
Offer versioning scheme options
Inform developers about the changes
Control when the changes get adopted
In light of that, we decided to provide a mechanism and leave the job of setting a “policy” to customers. First off, we don’t force anyone into versioning. We offer a selection of popular versioning schemes. We classify changes into two categories and treat each as a first-class concept in the system. Revisions allow API publishers to make, validate and apply, usually non-breaking, changes to an API without fear of breaking its consumers. Versions enable API publishers to evolve the API in more significant ways and allow app developers to opt-in into those changes whenever they are ready.
Revisions
Providers choose when to deploy
Versions
Consumers choose when to adopt

27. Revisions without versions
Service Instance
API
Operation
Revision
;rev=1
/speakers
/sessions
/days
;rev=2
foo
[ANIMATED SLIDE]
Here is the pre-version API model. Everyone is leaving in it now and can continue to do so. But there is a richer model if you decider to take advantage of versions and revisions. As you can see, each API can have multiple versions. And each version, multiple revisions. At any given time only a single revision is active - marked in red. Revisions can be “online” for testing (solid green) or “offline” (light green).
;rev=3
;rev=4

28. Versions and revisions
Service Instance
API
Version
Operation
Revision
/v1
;rev=1
;rev=2
;rev=3
/speakers
/sessions
/days
;rev=4
foo
[ANIMATED SLIDE]
Here is the pre-version API model. Everyone is leaving in it now and can continue to do so. But there is a richer model if you decider to take advantage of versions and revisions. As you can see, each API can have multiple versions. And each version, multiple revisions. At any given time only a single revision is active - marked in red. Revisions can be “online” for testing (solid green) or “offline” (light green).
/v2
;rev=1
/events
/speakers
/sessions
/venues
;rev=2