The eBook will be free and open sourced on Github at https://github.com/arafato/azure-core-concepts-book and published via Leanpub at https://leanpub.com/azure-core-concepts. Any royalties will be donated to http://amazonwatch.org/
I'm leaving the original Azure Ramp-Up guide here until the book has been published.
DRAFT VERSION 0.3 (still early stage, TOC is almost final)
- Fundamental Concepts
- Developer Tooling
- Infrastructure as a Service (IaaS)
- Platform as a Service (IaaS)
- Software as a Service (SaaS)
- Open-Source Ecosystem
- Learning Paths
- Free Resources
This chapter is about the the foundational building blocks of the Azure platform. This chapter will help you understand the basic terminology and concepts you will need every day when working with Microsoft Azure.
- Azure Portal: A graphical user interface to manage and operate your cloud-based environment.
- Classic Portal: The old graphical user interface using the ASM deployment model (deprecated)
- Azure Environment: A strictly isolated part of the Azure Cloud Platform
- Azure Geography: A defined area of the world that contains at least one Azure Region
- Azure region: A geographical location within a geography containing one or more Azure data-centers
- Azure Subscription: A manageable group of resources for the accounting department
- Azure Resource Group: A logical container associated with exactly one subscription that holds related resources for an Azure solution
- Microsoft account: A consumer account that has been created via https://signup.live.com/
- Work or school account: An account that has been created in an (Azure) Active Directory. Includes Office365 accounts.
- Azure Resource Manager (ARM): The modern deployment model in Azure.
- Azure Service Manager (classic): The classic deployment model. Do not use for new projects.
- Azure Resource: A manageable item that is available through Azure. Some common resources are a virtual machine, storage account, web app, database, and virtual network, but there are many more.
Azure is comprised of currently four different so-called environments that are strictly isolated from each other. Strictly isolated means:
- They are operated and managed through different endpoints (same API interfaces, though)
- Their authentification mechanisms (Azure Active Directory) do not have a trust-relationship with each other. Thus, environments do not provide a single sign-on experience amongst each other
- They are managed through distinct graphical user interfaces (Azure speak: portals) since a portal also needs to authenticate and operate against the different management and service endpoints
Azure currently provides the following environments:
| Azure Environment | Name to Use |
|---|---|
| International Cloud | AzureCloud |
| German Cloud | AzureGermanCloud |
| US Government Cloud | AzureUSGovernment |
| China Cloud | AzureChinaCloud |
where Name to Use is the name to be used in the context of our Developer Tooling.
Gotcha
- The Azure Cloud environment is the only one which has a trust relationship with the Microsoft consumer identity system. This lets you signup and login with a Microsoft account (formely known as LiveID). This is also the reason why you cannot use a Microsoft account to signup and login into the other Cloud environments since these do not have a trust relationship with the Microsoft consumer identity system due to their restricted privacy and data regulations.
- When using our Azure CLIs and SDKs be sure to configure them accordingly to let them talk to the correct environment (see section Developer Tooling for more information)
Also known as the International Cloud. Currently comprised of 30 regions world-wide.
Sign Up: https://azure.microsoft.com/free/
Portal: https://portal.azure.com
Endpoints: are listed here for your convenience or can be programmatically fetched via
$ az cloud list --query "[?name == 'AzureCloud'].endpoints"
Also known as Microsoft Cloud Deutschland. Comprised of 2 regions, one located in Frankfurt, the other one in Magdeburg. Operated by T-Systems International GmbH, a subsidiary of Deutsche Telekom. Serves as trustee, protecting disclosure of data to third parties except as the customer directs or as required by German law. Even Microsoft does not have access to customer data or the data centres without approval from and supervision by the German data trustee. More information at https://azure.microsoft.com/overview/clouds/germany
Sign Up: https://azure.microsoft.com/free/germany/
Portal: https://portal.microsoftazure.de
Endpoints: are listed here for your convenience or can be programmatically fetched via
$ az cloud list --query "[?name == 'AzureGermanCloud'].endpoints"
For further information on the German cloud, the data trustee model, and the data trustee agreement, please refer to the according resources in the German Cloud section.
Azure China Cloud is available through a unique partnership between Microsoft and 21Vianet, one of the country’s largest Internet providers.
Sign Up: https://www.windowsazure.cn
Portal: https://portal.azure.cn/
Endpoints: are listed here for your convenience or can be programmatically fetched via
$ az cloud list --query "[?name == 'AzureChinaCloud'].endpoints"
Also known as Microsoft Azure Government Cloud. Comprised of 4 regions in USA. No public registration. More information at https://azure.microsoft.com/overview/clouds/government/
Trial Registration Form: https://azuregov.microsoft.com/trial/azuregovtrial
Endpoints: are listed here for your convenience or can be programmatically fetched via
$ az cloud list --query "[?name == 'AzureUSGovernment'].endpoints"
The Azure platform is currently comprised of 34 regions world-wide. A region is a geographical location of a cluster of Azure data-centers. Each region is assigned to one and only one environment. More information at https://azure.microsoft.com/regions/
Azure regions are organized as so-called Paired Regions. Each Azure region is paired with another region within the same geography, together making a regional pair. The exception is Brazil South, which is paired with a region outside its geography. More information at https://docs.microsoft.com/azure/best-practices-availability-paired-regions
- When deploying new resources onto Azure you can select the region to deploy to, however, as of now you cannot choose amongst the individual data-centers available in that region.
- Availability of Azure services depend on the region. Not every service that is Generally Available is available in every region. Please check services available by region at https://azure.microsoft.com/regions/services/
Understanding Authentication in Azure can be complicated at the beginning. Most users are confused about all the different pieces and terminologies such as Azure AD, Tenant ID, Account Owner, Subscription Owner, Subscription Admin, Directory Admin, Co-Admin, RBAC etc. coming together. It doesn't help neither that terms are used inconsistently throughout the web, and that Azure has two different authentication models, depending on whether you are using ARM or ASM (see section Azure Resource Manager). We will focus on ARM which is the current model and the one you should use for every new project.
So let's provide clarity.
Before we look at the different aspects and services let's quickly define what we mean when we refer to Control Plane and Data Plane.
A Control Plane is the set of APIs that allow you to provision and configure a resource.
A Data Plane is the set of APIs that allow you to actually use the resource.
Example: In order to provision a Storage Account, I need to use a different set of APIs compared to when I want to actually store some data on it. Likewise, I'm using a different set of APIs when I want to provision an EventHub compared to when I actually push data to it.
Why is this important? Because Azure provides two different authentication mechanisms. The one that is based on Azure AD (authentication) and RBAC (authorization) which we will thoroughly discuss in the subsequent sections, and one that is based on Shared Keys.
Every operation on the Control Plane needs to be authenticated against Azure AD. Every operation. Period. Not every operation against the Data Plane, however, needs to be also authenticated against Azure AD. Some services such as Azure Storage Service, Service Bus, and Event Hubs rely on so-called Shared Keys.
So if you want to provision a Storage Account you will need to authenticate against Azure AD. In order to read and write data from it (which are operations on the data plane) you are using Shared Keys. For a more detailed discussion on this topic with a strong focus on Azure Storage, we recommend the following link: https://docs.microsoft.com/en-us/azure/storage/storage-dotnet-shared-access-signature-part-1
Most services on Azure, however, rely on Azure AD and RBAC for managing the Control Plane and the Data Plane.
Azure Active Directory (Azure AD) is Microsoft’s multi-tenant cloud based directory and identity management service (see https://docs.microsoft.com/azure/active-directory/active-directory-whatis). In Azure AD, a tenant is representative of an organization. It is a dedicated instance of the multi-tenant Azure AD service that an organization receives and owns when it signs up for a Microsoft cloud service such as Azure, Microsoft Intune, or Office 365. Each Azure AD tenant is distinct and separate from other Azure AD tenants.
An Azure AD tenant has always the following domain assigned *.onmicrosoft.com. For example,
if you sign up with your MS consumer account [email protected] an Azure AD tenant is
automatically created for you similiar to joedoeoutlook.onmicrosoft.com. A user Lilli created in this directory would be referred to as [email protected]. Of yourse, if you have your own domain, you can create a CNAME to joedoeoutlook.onmicrosoft.com so that users do not need to use these awkward-looking user-name accounts.
A tenant houses the users in a company and the information about them - their passwords, user profile data, permissions, and so on. It also contains groups, applications, and other information pertaining to an organization and its security.
There are two types of accounts you can use to sign in: a Microsoft account (formerly known as Microsoft Live ID) and a work or school account, which is an account stored in Azure AD. There is a federation relationship between Azure AD and the Microsoft account consumer identity system. As a result, Azure AD is able to authenticate "guest" Microsoft accounts as well as "native" Azure AD accounts, assuming that the Azure AD tenant is living in the International Cloud.
- Account Overlap: It is not possible anymore to create a new personal Microsoft account using a work/school email address, when the email domain is configured in Azure AD. See https://blogs.technet.microsoft.com/enterprisemobility/2016/09/15/cleaning-up-the-azure-ad-and-microsoft-account-overlap/ for details
An Azure subscription is just a manageable group of resources for the accounting department. Every Azure subscription has a trust relationship with an Azure AD instance. This means that it trusts that directory to authenticate users, services, and devices. Multiple subscriptions can trust the same directory, but a subscription trusts one and only one directory.
This trust relationship that a subscription has with a directory is unlike the relationship that a subscription has with all other resources in Azure (websites, databases, and so on), which are more like child resources of a subscription. If a subscription expires, then access to those other resources associated with the subscription also stops. But the directory remains in Azure, and you can associate another subscription with that directory and continue to manage the directory users.
Please see https://docs.microsoft.com/en-us/azure/active-directory/active-directory-how-subscriptions-associated-directory for a more detailed discussion.
First, let's define the terminology because this often leads to confusion. Generally speaking, an indentity in Azure AD can be of two types: Administrator and User.
A User can only manage Azure resources such as VMs or Storage depending on the according access rights he has been granted through RBAC. He is not allowed to change any Azure AD properties.
An Administrator can manage properties in Azure AD such as creating, deleting, and modifying users, and also - depending on his granted access rights through RBAC - manage Azure resources.
When we talk about administrators in the context of Azure we usually do not refer to this Administrator type. Instead, people are usually using the notion of Azure Active Directory Admin and Azure Subscription Admin. Both are, however, two separate concepts.
Let's examine both of them in more detail.
Azure Active Directory Admin
Also known as Account Admin an Azure AD admin (Administrator type) can manage properties in the Azure AD like performing
directory administration tasks using tools such as Azure AD PowerShell or
Office 365 Admin Center. They have not necessarily access to the associated subscriptions. It is possible but this isn’t required.
An Azure AD Admin is always assigned a specific administrator role. To have access to all
administrative features of Azure AD, an administrator needs to be assigned the so-called
Global Administrator role. Only those can also assign other administrator roles.
Administrator that have not been assigned the Global Administrator role, are usually referred
to as Limited Administrators. Please see https://docs.microsoft.com/en-us/azure/active-directory/active-directory-assign-admin-roles for
a detailed discussion and overview of the individual roles.
Much of these roles, however, are not really relevant in the context of Azure. Note, that
Azure AD is used amongst a lot of different Microsoft products such as Office365, Dynamics365,
Skype for Business, Intune, and many more. This is why there are so many more roles.
The ones that are usually relevant in the context of Azure are
- Global Administrator
- User account administrator
Typically, the account you are using for the initial sign up for an Azure account, is both an Azure AD Admin (Global Administrator role) and an Azure Subscription Admin (see next section). But again, this is not required.
Azure Subscription Admin
An Azure Subscription Admin (can be both an Administrator type or User type) is an identity that has been assigned
an owner role on subscription level.
That means it has has full access to all Azure resources including the right to delegate access to others.
Access Management in Azure is done via Role-based Access Control (RBAC) (see next section)
which lets you assign appropriate roles to users, groups, and applications at different scopes
such as subscription, resource groups, or a single subscription.
In the old ASM world the equivalent role is often referred to as Service Administrator or Co-Admin, and unfortunately they are still used in the ARM world. Do not use them since they do not provide the same power and flexibility as the new concepts discussed here. In particular, they are lacking the entire RBAC functionality and force you to use the classic portal if you need to make any changes.
So in essence an Azure Subscription Admin is only a specialization of a regular User type. That is, someone with an Owner role at subscription level. We could also think about an identity with only Contributor role on a certain resource group scope. From a conceptual point of view both users do not differ except for their assigned roles and rights.
Now what exactly is this RBAC, Owner, and Contributor role all about? Next!
Role-based Access Control (RBAC) is all about defining what your users are allowed to do.
For this purpose it provides built-in roles that you can use to assign to a user, groups, and
applications.
Azure RBAC has three basic roles that apply to all resource types:
- Owner has full access to all resources including the right to delegate access to others.
- Contributor can create and manage all types of Azure resources but can’t grant access to others.
- Reader can view existing Azure resources.
The rest of the RBAC roles in Azure allow management of specific Azure resources.
For example, the Virtual Machine Contributor role allows the user to create and
manage virtual machines. It does not give them access to the virtual network or the
subnet that the virtual machine connects to.
A more detailed discussion can be found at https://docs.microsoft.com/azure/active-directory/role-based-access-control-what-is
If you're looking to define your own roles for even more control, see how to build Custom roles in Azure RBAC. Note, however, that custom roles are currently supported only via Powershell, the Azure CLI, and the REST API.
Now let's talk about Groups and Group Owners.
A group in the RBAC-context provide a means to group users, and let them utilize the privileged access it grants.
From a conceptual point of view, they are really similiar to GNU/Linux groups for access control.
What is interesting is, that you can assign a so-called Group Owner to a particular group.
The membership of the group is now managed by the group owner.
The resource owner effectively delegates the permission to assign users to the subscription, resource group, or resource
to the owner of the group.
A detailed discussion of this topic can be found at https://docs.microsoft.com/azure/active-directory/active-directory-manage-groups.
Until now we only talked about authenticating real users, human beings. But what if your script or application needs to authenticate itself (via certificates) in order to access Azure resources? Or if it needs to participate in Authentication Workflows such as OAuth2? This is where Service Principals come into play. Please refer to both links below in order to learn more about this topic, and to learn how to set up a service principal.
- Application and service principal objects in Azure Active Directory
- Use portal to create Active Directory application and service principal that can access resources
Once you have setup a service principal, you can use it to make calls to the Azure APIs (see section Resource Provider for details what we mean by the term Azure APIs) from a script or an application, for example. Our SDKs will do much of the heavy lifting regarding authentication, token handling, and so on. See next chapter to learn what's really going on under the hood.
Let's briefly look under the hood to better understand what's going on when an SDK authenticates a call. The overall process looks as follows:
- We need to acquire an OAuth2 bearer token by authenticating ourselves against an identity provider such as Azure AD
- We use this bearer token to sign our requests to authenticate against the relying party which is the Azure Management API in our case
The example assumes we are using the Internation Cloud. The use of another Azure cloud environment requires you to use the according endpoints of that respective environment. See section Environments for how to get them with our Azure CLI 2.0.
The JSON Web Token (JWT) can be acquired with a POST call to https://login.windows.net/<tenantId>/oauth2/token. The tenant id is your Azure AD tenant that is associated to your subscription, and where you have created a service principal. Think of https://login.windows.net as a landing page that forwards you to the correct identity provider depending on whether you are using a work or school account (re-directs you to your Azure AD tenant), or a Microsoft account (re-directs you the Microsoft consumer identity system).
In our example we want a token that can be used to sign requests against the ARM API of the International Cloud. For this we need to specify the correct audience which is https://management.core.windows.net. We provide this information and our service principal credentials in the body of this request.
After having acquired this token we can add it to the Authorization Header of our HTTP-request against the service management API which is hosted at https://management.azure.com/. See section Resource Provider for a more detailed discussion on how this API works.
We recommend to take a look at this easy to understand code example (NodeJS) that walks the path we have just outlined on a high-level.
For a more detailed disucssion on different authentication scenarions we recommend the following links:
- https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-rest-api
- https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-authentication-scenario
Azure Resource Manager (ARM) is the recommended model for deploying and managing your applications on Azure. It is comprised of two parts:
- A set of APIs (accessible via REST, CLI, SDKs, and the Portal) that you use to provision and manage your resources. These APIs are offered by so-called Resource-Providers
- A deployment model allowing you to group your resource into so-called resource-groups, and hence manage them as a unit, and to declaratively specify your resources in so-called ARM-Templates
Let's take a deeper look into the various aspects.
Think of a resource provider as a service that exposes various APIs for you to create and manage different kinds of Azure resources such as VMs, storage accounts, networking, Stream Analytics jobs, etc. There are a lot of different resource providers available, which you can query in the portal or with our new CLI as follows:
$ az provider list
You can find the according output here for your convenience (last updated March 2nd 2017).
Gotcha
- Our CLIs and SDKs are configured to talk to the Internation Cloud environment by default. The above output thus lists only the resource providers available in the regions of the International Cloud. See section Developer Tooling for how to configure them to use different Azure environments.
Resource providers are organized in namespaces such as Microsoft.Compute, Microsoft.Storage, or Microsoft.StreamAnalytics. We will use the term namespace and resource provider interchangeably.
So for example, looking at the namespace Microsoft.Compute, you can find multiple resource types, each one listed with its available API versions and regions. A resource type represents an Azure resource such as a virtual machine, an availability set, a disk, or available locations. A resource type adheres to the following naming convention:
<Namespace>.resourceType(/resourceType)*
That means resource types can be nested. For example: Microsoft.Compute.virtualMachineScaleSets/virtualMachines/networkInterfaces
This denotes the resource type of a network interfaces of virtual machines within a scale set.
Each of these resource types provide their own set of REST-full operations and APIs. Depending on the Azure environment (see section Environments) you are using, the management endpoint that hosts these APIs is different.
For instance, the resource provider APIs of the Internation Cloud are hosted at https://management.azure.com, the APIs of the German Cloud are hosted at https://management.microsoftazure.de).
Example: In order to talk to the REST API of a virtual machine named myVM in the resource group myrg in subscription 8d4dee44-4b28-4e05-9927-3a5d34a42bf5 in the Internation Cloud you would call
https://management.azure.com/subscriptions/8d4dee44-4b28-4e05-9927-3a5d34a42bf5/resourceGroups/myrg/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2016-03-01
You will find the official Azure REST API reference here: https://docs.microsoft.com/azure/templates/.
If you know the resource type, you can go directly to it with the following URL format: https://docs.microsoft.com/azure/templates/{provider-namespace}/{resource-type}. For example, the SQL database reference content is available at: https://docs.microsoft.com/azure/templates/microsoft.sql/servers/databases
Note that most Azure service REST APIs have a corresponding client SDK library, which handles much of the client code for you. We will take a more detailed look at these SDKs, and how to configure them accordingly in the Developer Tooling section.
A resource group is a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group. You decide how you want to allocate resources to resource groups based on what makes the most sense for your organization.
Note, that you need to assing a location to a resource group. The individual resources within a resource group can, however, be deployed into different regions.
Usually, it is recommended to group those resources together that have the same lifecycle (web application servers in one resource group, database servers in another).
You will find a more detailed discussion on this topic at https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview#resource-groups
Gotcha
- The resource group stores metadata about the resources. Therefore, when you specify a location for the resource group, you are specifying where that metadata is stored. For compliance reasons, you may need to ensure that your data is stored in a particular region
An ARM-Template is a JavaScript Object Notation (JSON) file that defines one or more resources to deploy to a resource group. It also defines the dependencies between the deployed resources. The template can be used to deploy the resources consistently and repeatedly in a so-called declarative syntax meaning "Here is what I intend to create". This frees you to think about the sequence of programming commands you have to use.
Using ARM-Templates to provision your resources is the recommended way, and defintely a best-practice.
ARM-Templates also provide the possibility to use numeric and string functions increasing their expressiveness, and also a means to split them into smaller units through so-called Linked Templates.
We recommend the following links to learn more about how to author them, what to consider, and making them world-class ARM-Templates.
-
Authoring Azure Resource Manager templates
A gentle introduction to the structure of ARM-Templates -
Resource Manager template walkthrough
An end-to-end walkthrough based on a real example -
Azure Quickstart ARM-Templates
A huge collection of example ARM-Templates that will help you get going fast. Ranging from simple Linux or Windows based VMs, to complex Elastic Search, Cassandra, and Zookeeper setups. -
https://docs.microsoft.com/azure/templates
The official Azure REST API reference. If you know the resource type, you can go directly to it with the following URL format:https://docs.microsoft.com/azure/templates/{provider-namespace}/{resource-type}. For example, the SQL database reference content is available at: https://docs.microsoft.com/azure/templates/microsoft.sql/servers/databases -
Free Ebook: World-class ARM-Templates - Considerations and Proven Practices
Over 60 pages full of best-practices and design considerations
Sometimes you will hear that ARM-Templates support Round-Trip Engineering. This is true in that the internal representation of an Azure resource refers to the same JSON schema as an ARM-Template. You will find the JSON schemas at https://github.com/Azure/azure-resource-manager-schemas
So in essence this enables you to look at the JSON description of already deployed resources, copy / adapt them to your ARM-Templates, re-deploy, and repeat if needed. Just how can you look at the JSON description of already provisioned resources? There are multiple ways to do that:
-
In the Azure portal you can export the JSON representation of an entire resource group. You'll find that button in the according resource group blade under
Settings - Automation Script -
In the Azure portal search for
Resource ExplorerunderMore Services -
Visit https://resources.azure.com for an explorer that is similar to the one in the Azure portal, however, providing more features such as calling available REST APIs directly from the web interface
Gotcha
- The internal JSON representation of an Azure resource will usually include many more attributes than your original ARM-Template, since the internal representation is explicit. Many attributes have standard values that you often do not explicitly set or are only set and known at provision time such as internal domain name suffixes of your network interface cards.
Writing complex infrastructure setups "by hand" is possible but sometimes people end up writing their own ARM-Template generation tools to speed up things. According projects are still in its infancy, however, support is growing. We'll take a look at these kind of projects in section Open-Source Ecosystem.
There is, however, already intellisense support for a wider range of different editors. We will look at them in section Developer Tooling.
Also there is a free and commercial plugin available for Visual Studio made by a German-based company Tangible Engineering that allows you to derive your ARM-Templates from a graphical model.
This section will discuss the different means to programmatically talk to Microsoft Azure, and the tooling that is provided by us and third party vendors.
Essentially, Microsoft Azure provides 4 different means to talk to the platform:
- Azure Portal
- Command Line Interface (CLI)
- SDKs for various programming languages
- REST API
Let's look at each of them and discuss how to use and configure them.
Gotcha
Do not assume (yet) that there is feature parity between all four ways to talk to Microsoft Azure. Unfortunately, there are features that are available via the Portal that might not be available via our SDKs, or available via CLI but not via the Portal. This is a fast moving target so be sure to consult the according documentation on whether the feature is supported. Every feature, however, is available via our REST API.
As a rule of thumb, assume that per default, all our tools usually use the endpoints of the International Cloud.
While not being a programmatic means to talk to Azure, for many it is often the first starting point. Keep in mind that every Azure Environment has its dedicated portal running at a dedicated URL, requiring you to use separate login credentials, stored in Azure Active Directory Tenants tied to the according environment. No single sign-on experience is provided across different Azure Environments since they do not have a trust-relationship amongst each other.
Please refer to the section Azure Environments to get an overview, under which URL an according portal for a given environment can be found.
Azure is currently providing two different cross-platform CLIs:
- The old one based on NodeJS, still supporting the old ASM and the new ARM model. It is available via Node Package Manager (NPM), and hosted on Github.
- The new one often referred to as Azure CLI 2.0, written in Python, and only supporting the new ARM model. It is also hosted on Github. For installing instructions please refer to our install guide.
We strongly recommend to use the new Azure CLI 2.0. For the rational behind introducing a new CLI, please refer to the official announcement. We will refer to new Azure CLI 2.0 for the remainder of this section.
Overview and Documentation:
https://docs.microsoft.com/en-us/cli/azure/overview.
Installation
https://docs.microsoft.com/en-us/cli/azure/install-azure-cli
Environment Configuration
To change the environment to be used, type
$ az cloud set --name <environment_name>
where <environment_name> is any of our currently available Azure Environments.
Gotcha
- If you use both CLIs, remember that
azureis the old CLI, and thatazis the new Azure CLI 2.0.
You can get an overview about our officially supported SDKs and tools at
https://docs.microsoft.com/en-us/azure/#pivot=sdkstools&panel=sdkstools-all
Our officially supported SDKs are all open-source and available on Github. In the remainder of this section we will sho how to configure these SDKs for use with different Azure environments other than the International Cloud. In particular, we will demonstrate how to do a interactive logins, logins via service principals, a call to the control plane, and a call to the data plane via shared access keys. See section Short Tale About Two Different Authentication Schemas for details on control- and access planes, and shared access keys.
-
Azure Environment Configuration
Sample on how to configure this SDK to use a specific Azure environment (e.g. German Cloud). Per default, it uses the International Cloud.
-
Currently supported Azure Environments and endpoint URLs to use
-
Azure Environment Configuration
Sample on how to configure this SDK to use a specific Azure environment (e.g. German Cloud).
-
Currently supported Azure Environments and names to use: The user has to provide the environment endpoint URL.
Work in Progress, not yet officially supported: Go SDK
This repository is under heavy ongoing development and is likely to break over time. We currently do not have any releases yet.
You will find an overview about all currently supported Azure IoT SDKs on this landing page:
https://github.com/Azure/azure-iot-sdks#microsoft-azure-iot-sdks-1
TODO https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-rest-api
https://docs.microsoft.com/en-us/azure/storage/storage-azure-cli TODO: Portal, CLIs, SDKs, IDEs and according configuration
TODO: VMs, Storage, VNET, Availability Set, Managed Disks https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-sizes
TODO: App Service
TODO: Azure Marketplace
This chapter is about third party OSS projects in the context of Microsoft Azure.
- Serverless Framework
The Serverless Framework allows you to deploy auto-scaling, pay-per-execution, event-driven functions to any cloud. It currently supports Microsoft Azure, AWS Lambda, Apache OpenWhisk, and is expanding to support other cloud providers.
- Azurite
A lightweight server clone of Azure Blob Storage that simulates most of the commands supported by it with minimal dependencies. Written in NodeJS. - S3Proxy
AWS S3 Proxy written in Java with support for Azure Blob Storage and many other storage backends. - BlobPorter
A high throughput blob copier, optimized for large files. Written in Golang.
- Proto
A Python library to generate Azure Resource Manager (ARM) Templates. Kudos to Peter Hoffmann from BlueYonder for maintaining this project.
The following link points you to an overview listing all available learning paths we are currently offering for the Azure platform. Use these learning paths to guide yourself through the documentation for our services so you can start to build effective cloud applications on Azure.
These learning paths do not encompass all of our services currently available. For many use-cases, however, we think that the most relevant are covered.
https://azure.microsoft.com/documentation/learning-paths/
- https://azureinfohub.azurewebsites.net/MediaType?mediaType=Ebook
A comprehensive and curated list of free Azure-related eBooks. A big thank you goes out to Holger Sirtl who maintains this site. - Überblick über Microsoft Azure (German only)
A great resource to get an overview about our broad service offering by Holger Sirtl, including Analytics, IoT, Security, Networking, DevOps, Storage, Web Applications, and Media Services.
- Azure Friday
Join Scott Hanselman every Friday as he engages one-to-one with the engineers who build the services that power Microsoft Azure as they demo capabilities, answer Scott’s questions and share their insights. - Microsoft Virtual Academy - Azure Courses
Free Microsoft Azure trainings delivered by experts, ranging from our IaaS to PaaS Offerings such as App Service, Azure Search, Nano-Services with Azure Functions, and Microservice with Docker on Azure Container Service.
- Azure Info Hub - Whitepapers
A comprehensive and curated list of free Azure-related Whitepapers. A big thank you goes out to Holger Sirtl who maintains this site. - Azure Whitepapers by David Chappell
Great high-level and conceptual explanations of Azure-related services and technologies by David Chappell - Securing the Microsoft Cloud
- Azure Security, Privacy, and Compliance
- Security Management in Microsoft Azure
- Cloud Operations Excellence and Reliability Strategy Paper
- Leveraging Stored Energy for Handling Power Emergencies
- Resilience by Design for Cloud Services
- Information Security Management
- Where and How your Data is Stored
- Whitepaper German Trustee Concept (German only)
An in-depth view at the German Cloud and the data trustee model. - Official Customer Data Trustee Agreement (DE)
- Official Customer Data Trustee Agreement (EN)
The Customer-Data Trustee Agreement is a legally separate contract between Customer and Data Trustee. Microsoft is not a party to this agreement.
- Official Azure Blog
Great resource to get informed about all new services and feature announcements - Official Azure Documentation
Extensive documentation about Azure services, SDKS/Tools, and architectural best-practices - Azure Info Hub A curated Website full of all sorts of information regarding Microsoft Azure. From querying Azure Feature Announcements, lists of different Webcasts, ebooks, whitepapers, and tools. Must-know resource for everyone building applications with Azure.
- Official Microsoft Azure Github Repository
APIs, SDKs and open source projects from Microsoft Azure (350+ projects) - Azure Networking and ARM FAQ by Igor Pagliai
A little bit outdated but still relevant and highly informative FAQ that goes really deep on Networking and ARM topics - A curated list of Azure Bookmarks
Links to follow-up Azure articles ranging from topics such as App Service Environments, Availability Best-Practices, Blobs, Data Lake Store, all the way up to Security, Trainig, VNETs and WebHooks.
We recommend the following Twitter handles to follow to be first to know if something mind-boggling is happening in the Azure universe.
- Microsoft Azure
The official account for Microsoft Account. Follow for news and updates from the #Azure team and community. - Corey Sanders
Director of Program Manager responsible for IaaS and Cloud Services. - Mark Russinovich
CTO of Microsoft Azure - Scott Guthrie
Runs the Cloud & Enterprise division at Microsoft