November 1, 2016

TL;DL – .NET Rocks! 1368 (Azure API Management with Vishwas Lele)

Show link: .NET Rocks! 1368: Azure API Management with Vishwas Lele

Guest: Vishwas Lele

Show Notes

  • What is API management?
    • You may have a number of different APIs written by different groups that you want to consolidate. You want them grouped together consistently and with good documentation. You want insight about the API (e.g., how many times is it being called, how it’s being used).
    • API management is a proxy that sits between your API and the external world. (This is an example of the fundamental theorem of software engineering where you just add another layer of abstraction.)
  • You need an API that you’re creating a facade for and an admin tool that configures the facade to call the underlying API. By creating this facade you are creating a developer portal. For example, Microsoft Cognitive Services API has a playground where you can try out the APIs and get a subscription key for a specific level of service.
  • The API should be easy to explore and try out so that you don’t have to wade through documentation.
  • When using Azure API management, do those APIs have to live in Azure?
    • No, they can be hosted anywhere. You can also set up VPN connections to access internal APIs.
  • There are three components: administrative, developer, and runtime (a proxy layer of interaction). In this proxy, you can inject custom behaviors such as policies (e.g., allow this particular API for a certain class of subscriber to be limited to 5000 calls per day).
  • Other examples of where API management is helpful
    • Caching data so you don’t need to make as many underlying API calls.
    • Having an on-premise API that expects a SOAP packet, but exposing a public API that uses JSON
  • Developers can write policy expressions (which use Razor syntax) that can use a subset of .NET classes to add custom behaviors (e.g., reject a JSON packet if it’s above a certain size).
  • What can you implement with a behavior?
    • Quotas (e.g., lifetime maximum of # of invocations)
    • Throttling
    • Throughput (e.g., 10 times per minute)
  • Can we have policies that describe a service level agreement (e.g., go to the front of the queue, lower latency)?
    • Policies are about injecting custom behavior and analytics. How much time did you spend calling an API? How many calls did you make? How many returned successfully? You can aggregate this by client, tenant, or user.
  • You could charge one rate for a failed request (e.g., validating an address which leads to more work that you would charge for).
    • There is an aspect of monetization. Keeping track of the statistics is useful for managing that, and invoicing is currently on the product roadmap. For example, Company X used my API for a certain period and got a certain response level so that company owes me some amount of money. On the other hand, Company X sent me users for my API and I generated this much business, and they get some money back for bringing that business.
  • This toolset protects my infrastructure (e.g., controlling runaway apps).
    • Yes, otherwise you’d have to build throttling into your business logic. You also make yourself available for DDoS attacks.
  • Having the facade (that maybe initially returns HTTP 200) first allows the creator of the services to be working at the same time as the consumer of the services. Once the service is ready, you simply point the facade to the real service.
  • Example: A company had a trained machine learning algorithm exposed as a web service on Azure. They wanted it to be available via an intranet SharePoint instance, so they implemented a custom behavior to only allow requests from a specific IP range and with a valid token.
  • Like the facade or adapter patterns, you can introduce a change in the abstraction rather than the APIs themselves.
  • The analytics you get from API management allows you to easily do bill backs (i.e., IT charging other parts of the organization for services provided).
  • Having a trusted third party (i.e., Microsoft) provide the tooling for API metrics means you don’t have to worry about whether the tools you’d have to write yourself are working properly.
  • Does Azure handle the billing of your consumers if you charge for certain service levels?
    • This will be coming in future releases. There is already the Azure Marketplace where you can get paid for people using it.
  • Do you have stuff implemented using Azure API management?
    • Yes, and it’s been around for some time (it was a startup in the Washington DC area that Microsoft acquired). We’re using it for protection, quota, discoverability, and developer portal aspects.
  • Having API metrics can also make your software more efficient. For example, you may be calling a service multiple times unnecessarily and be unaware of that.
  • Resource: Pluralsight course Microsoft Azure API Management Essentials

Better Know a Framework

  • SkillFlow — “Get real-time help from expert developers on any Slack team. SkillFlow is a real-time collaboration tool for developers built right into your existing workflow. Unlike traditional Q&A forums like Stack Overflow, SkillFlow directly notifies potential problem-solvers and initiates a real-time chat so that your problem is directly addressed and no time is wasted waiting for people to discover your question.”
  • The current Stack Overflow protocol is pretty efficient, though: Before asking a question, search for what you’d ask for, as it’s probably already been asked.

Listener E-mail

From show #1212 (cloud-oriented programming); refactored an app to be asynchronous using a worker processing from the Azure Storage Queue to make it more responsive; instrumentation and diagnostics were also a breeze.

Technology Giveaway Ideas