Azure API Management

Editor's Notes

• #3: Interested in all things integration – which of course includes MS Flow
• #4: Most of these slides are taken from this presentation at Integrate 2017 USA
• #5: Most of these slides are taken from this presentation at Integrate 2017 USA
• #6: More organizations adopt API-centric business strategies. Importance of APIs and investment in them are rising. APIs need to protected, measured and harnessed. In other words they need API management.
• #9: First is APIM creates a public facade over your APIs and decouples API implementations or backends from API consumers enabling them to evolve independently. This includes hiding all APIs regardless of their location behind a single domain name and API address. Exposing only a subset of backend capabilities to API consumers. Modernizing and normalizing APIs by changing their URL structure and response formats. Optimizing APIs for specific consumers and scenarios by conditionally stripping down the responses. Dynamically routing requests to implement advanced versioning approaches   Second, APIM allows API implementers to externalize and centralize common cross cutting concerns and focus on the core value, the domain related logic. Security, throttling, cross domain access and response caching are just a few horizontal capabilities you'll get from APIM. APIM supports API key, JWT token validation as well as IP based authorization. We offer a number of cross domain techniques including full support for CORS. APIM implements distributed quota and rate limiting policies that allow a great degree of flexibility and scale. It comes with built in response cache and policies that allow fine grained control over what and how gets cached   Having insight into usage and health of your APIs is important and APIM captures metrics and provides key reports out of the box. For those customers who are looking to monetize their APIs we collect and offer via API data allowing them to implement a variety of subscription business models.   With APIM Developer portal you can treat internal and external developers the same way from the get go and provide them with a self service on-boarding experience, AP catalog, documentation, samples, and allow them to send request to your APIs without writing a line of code. ■ Know who API users are and engage them like customers. Whether the developers programming to one’s APIs are inside the organization or outside, knowing who they areis a foundation of API success. For an API provider that charges for API use, like Twilioand SendGrid, this is of course necessary for collecting revenue, but even for free access, as with New York’s and Chicago’s transit systems’ APIs, knowing API users enables greater understanding of how APIs are used and what direction to take APIs in the future. API users, whether they pay or not, should be engaged as customers. ■ Clarify the rules of API access. For reasons of capacity management and security, access to APIs is rarely unlimited. But customers (i.e., API users in this case) don’t like surprises, so the rules for access must be clear, such as what data may be accessed and how many requests are allowed per minute or per month. is may include de nition of di erent access plans with di erent rules for di erent API users. Make it easy to use the API. rough documentation, examples, and discussion forums, it must be easy for API users to understand the API, get answers to questions, test API usage, and migrate between API versions. Although REST services are needed for mobile, other styles of services may also be part of an enterprise API strategy (e.g., SOAP, message queuing). Enforce the rules of API access. API providers must validate that incoming API requests are authorized and comply with the rules de ned by the access plan each API user is associated with. Proactively manage API success by treating it as a product. Whether API users are internal, external, or both, to optimize the business value of an API, the API provider must treat it as a product with customers and a life cycle. Whether via basic reporting or advanced analytics, API providers must understand patterns of API access, including error rates that may indicate the API is di cult to understand. New versions of the API need a smooth and managed rollout to API users. ■ Connect API access to functions and data within their technology estate. APIs deliver their value by connecting to the API provider’s data and applications. Some of these assets may be API- ready, while others may need some manner of integration connectivity to make them accessible.
• #10: APIM is a management layer atop all of your APIs regardless of their location or technology stack. You can also use it to publish on-prem APIs, expose 1st party Azure APIs in a simplified manner directly to your partners, or expose functionality provided by 3rd party APIs.
• #12: Secure, protect, screen and measure APIM on Azure is provided as a fully managed cloud service. It has 3 key components.   Publisher portal is used by API publishers, people who own the APIs, to manage the APIs. On the Publisher portal one can add and edit APIs, configure API policies, view analytics, etc. Metadata and settings entered on the Publisher portal drive both the gateway and the developer portal. Management operations can be automated by using a comprehensive but easy to learn and use API.   Developer portal is turn key and shows auto-generated API catalog, interactive documentation and samples. Its look-and-feel and behavior can be customized to reflect customer brand and needs.   Gateway acts as a front door and mediates all the requests to your APIs, collecting usage and health data and applying policies configured via Publisher portal. It can connect to backends located anywhere and implemented and running on any technology stack either directly or via VPN. Gateway supports both Basic HTTP and mutual certificate authentication.
• #13: APIM on Azure is provided as a fully managed cloud service. It has 3 key components.   Publisher portal is used by API publishers, people who own the APIs, to manage the APIs. On the Publisher portal one can add and edit APIs, configure API policies, view analytics, etc. Metadata and settings entered on the Publisher portal drive both the gateway and the developer portal. Management operations can be automated by using a comprehensive but easy to learn and use API.   Developer portal is turn key and shows auto-generated API catalog, interactive documentation and samples. Its look-and-feel and behavior can be customized to reflect customer brand and needs.   Gateway acts as a front door and mediates all the requests to your APIs, collecting usage and health data and applying policies configured via Publisher portal. It can connect to backends located anywhere and implemented and running on any technology stack either directly or via VPN. Gateway supports both Basic HTTP and mutual certificate authentication.
• #21: Versioning debates haven’t been definitively settled. Some advocate immutability. Others, different kinds of versioning approaches, e.g. semantic versioning. Even a seemingly simple question of what constitutes a breaking change is a subject of many arguments. Each way of conveying version information has its pros and cons.
• #22: 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.
• #23: [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).
• #24: Customers can scale an API Management (APIM) instance by adding and removing units. A unit is composed of dedicated Azure resources and has a certain load-bearing capacity expressed as a number of API calls per month. This number does not represent a call limit, but rather a maximum throughput value to allow for rough capacity planning. Actual throughput and latency vary broadly depending on factors such as number and rate of concurrent connections, the kind and number of configured policies, request and response sizes, and backend latency. Capacity and price of each unit depends on the tier in which the unit exists. You can choose between four tiers: Developer, Basic, Standard, Premium. If you need to increase capacity for a service within a tier, you should add a unit. If the tier that is currently selected in your APIM instance does not allow adding more units, you need to upgrade to a higher-level tier.
• #25: As mentioned previously, you can choose between four tiers: Developer, Basic, Standard and Premium. The Developer tier should be used to evaluate the service; it should not be used for production. The Developer tier does not have SLA and you cannot scale this tier (add/remove units). Basic, Standard and Premium are production tiers that have SLA and can be scaled. The Basic tier is the cheapest tier which has SLA and it can be scaled upto 2 units, Standard tier can be scaled to up to four units. You can add any number of units to the Premium tier.
• #26: API Management supports multi-region deployment which enables API publishers to distribute a single API management service across any number of desired Azure regions. This helps reduce request latency perceived by geographically distributed API consumers and also improves service availability if one region goes offline. When an API Management service is created initially, it contains only one unit and resides in a single Azure region, which is designated as the Primary Region. Additional regions can be easily added through the Azure Portal. An API Management gateway server is deployed to each region and call traffic will be routed to the closest gateway. If a region goes offline, the traffic is automatically re-directed to the next closest gateway. Only available in Premium Tier
• #29: Stream and analyze your Azure API Management traffic data with our intuitive Power BI reports. The Azure API Management Analytics solution template for Power BI stands up an event streaming pipeline to provide near real-time analytics on top of API Management. The pipeline combines Event Hub, Stream Analytics, and SQL to provide a flexible streaming-with-storage experience. Azure Machine Learning and Azure Functions are used to process your data and provide additional insight into patterns and trends. Get started with compelling reports that can be customized to highlight the information most important to your business.
• #30: Azure API Management Analytics: Eyecatching, insightful Power BI reports on up to 90 days of API traffic (data will begin streaming once the temlate is deployed) Use an intuitive wizard-based UI to spin up a SQL database to accumulate live API log data. Leverage the real-time event stream processing capabilities of Event Hub and Stream Analytics Monitor your API Management traffic activities at a high level or drill down into certain failures and the actions of active sunscriptions Delve in to problems, look for patterns. Embrace the API economy by sharing API data with business users & product managers.
• #39: In this fourth lab, we will be receiving the orders from the business customer’s topic in a new Logic App, and check the total amount of the invoice. In case the customer placed a large order (over $50000), we will create a task for one of our sales employees to contact the customer to verify the order. In case the order is correct, the invoice will be emailed to the customer. The Logic App will then call a function, in which we will check a storage table to determine how much discount the customer will be given (based on the total order amount), and finally will place a file on blob storage, which will be used by an employee to refund the customer.