Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
41 lines (25 sloc) 3.17 KB

#Azure Platform Concepts

A Resource Provider (RP, for short) is simply an HTTPS RESTful API contract that Add-on owners will implement so a trusted Azure endpoint can provision, delete, and manage services on a user's behalf. Azure uses the Response from an RP to render and show a set of simple management operations in the Azure Management Portal.

The figure below gives a simplified view of how a user interacts directly with Azure through the Azure Management Portal, PowerShell scripts or *NIX command-line tools. Azure, in turn, communicates with your RP to manage the user's service.


##Azure Concepts Before we dive into RP concepts, it will be helpful to understand several Azure concepts first.

  • Every user who signs up for Azure logs in with a Microsoft account (e.g. or

  • The user then creates a Azure Subscription. A Subscription is a named entity e.g. 3-month Free Trial or MyApp Production associated with billing information. You can view your own Subscriptions on the Account Portal.

  • Next, the user creates one or more Resources such as a Website, Virtual Machine or Add-on. Website and Virtual Machine are two different ResourceTypes. Each Resource is deployed under exactly one Azure Subscription.

This is a conceptual view of a user's Resources:

  • There are two Subscriptions, Subscription A and Subscription B.
  • Subscription A has two Resources, named Resource 1 and Resource 2.
  • Subscription B has one Resource, named Resource 1.


##Resource Provider Concepts

  • Each Resource's lifecycle is managed by a ResourceProvider. This is a common software design pattern, where a manager / orchestrator (Azure) relies on a provider (ResourceProvider) to provide specific functionality.

  • An RP introduces an additional concept, called a CloudService. Instead of nesting a Resource directly under a Subscription, Resources are nested under a named entity called a CloudService. Think of a CloudService as a container of resources, roughly analogous to an application.

Tying it together, this is a conceptual view of the user's resources:


  • There are two Subscriptions, Subscription A and Subscription B.
  • Subscription A has two CloudServices, named CloudService X and CloudService Y.
    • CloudService X has a single Resource, named Resource 1.
    • CloudService Y has a single Resource, named Resource 2. This Resource is provided by a Resource Provider named 'clouditrace' which exposes a single Resource of type 'monitoring'. Note that the combination of Subscription ID, Cloud Service ID and Resource Name must be unique.
  • Subscription B has a single CloudService, named Cloud Service X with a single Resource, named Resource 1.