Develop Azure compute solutions (25-30%)

Implement IaaS solutions

VM: provision

TODO:

* Network Security Groups

NSG is a set of rules (source, source port, destination, destination port, protocol). Can be associated to either a VNet subnet or a network interface (NIC). Can be associated to multiple targets at once.

«How it works» document

Effective rules can be viewed for VM: az network nic list-effective-nsg.

Application Security Group is an abstraction that can be attached to a VM. It serves as a stub source/destination in NSG rules. In other words, NSG rules with ASG as source/dest apply if ASG is attached to VM. Idea is to create a rule per application usage.

Clone VM from inside VM using Azure Powershell commands: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/capture-image-resource.

* Availability set

To provide redundancy to an application, it is recommended to group two or more virtual machines in an availability set. This configuration ensures that during either a planned or unplanned maintenance event, at least one virtual machine will be available.

az vm availability-set create

VM should be create in a set (--availability-set argument). Impossible to add it later.

SKU can be:

  • Aligned: For managed disks
  • Classic: For unmanaged disks

* Random

Disks: managed vs. unmanaged. Unmanaged are manual blob files on storage account. Managed: can be snapshot’ed. Azure Backup supported seamlessly. Support role-based access control.

ARM templates: configure, validate, and deploy

Docs. Learning module. JSON files azuredeploy.json. «Azure Resource Manager» extension for VS Code. az deployment group create.

Blank file:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": []
}

Possible to specify parameters in file which will be a command line argument for CLI. Provided by parameters('xxx') function. Can be specified in a file (azuredeploy.parameters.json) instead of a CLI command.

Variables are in-template parameters, provided by variables('xxx').

Functions can be used, e.g. resourceGroup().

Outputs are return values.

Consequentive calls are idempotent and update resource properties. It is possible to take the existing template from Azure UI.

Conditional logic: specify "condition" for a resource.

Example from Docs:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "storagePrefix": {
      "type": "string",
      "minLength": 3,
      "maxLength": 11
    },
    "storageSKU": {
      "type": "string",
      "defaultValue": "Standard_LRS",
      "allowedValues": [
        "Standard_LRS",
        "Standard_RAGZRS"
      ]
    },
    "location": {
      "type": "string",
      "defaultValue": "[resourceGroup().location]"
    }
  },
  "variables": {
    "uniqueStorageName": "[concat(parameters('storagePrefix'), uniqueString(resourceGroup().id))]"
  },
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2019-04-01",
      "name": "[variables('uniqueStorageName')]",
      "location": "[parameters('location')]",
      "sku": {
        "name": "[parameters('storageSKU')]"
      },
      "kind": "StorageV2",
      "properties": {
        "supportsHttpsTrafficOnly": true
      }
    }
  ],
  "outputs": {
    "storageEndpoint": {
      "type": "object",
      "value": "[reference(variables('uniqueStorageName')).primaryEndpoints]"
    }
  }
}

Quickstart templates: https://azure.microsoft.com/en-us/resources/templates/.

Templates can be tested using ARM template test toolkit. Possible to write own tests. Possible to run in Azure Pipelines.

Import-Module .\arm-ttk.psd1
Test-AzTemplate -TemplatePath azuredeploy.json

Container images: configure for solutions

TODO: https://docs.microsoft.com/en-us/azure/container-registry/container-registry-tutorial-quick-task

Azure Container Registry: publish an image

TODO:

Azure Container Instance: run containers

TODO:

Create Azure App Service Web Apps

X-MS-CLIENT-PRINCIPAL-NAME header (and the like) are set by app service.

* SKUs

A list of SKUs can be retrieved using REST endpoint.

Comparision table: https://azure.microsoft.com/en-us/pricing/details/app-service/windows/

Notable:

  • F1 — Free
  • D1 — Shared
  • B1–B3 — Basic. Referenced as «Dedicated» app service plan above. Manual scaling, 1–3 instances.
  • S1–S3 — Standard. Autoscaling. 1–10 instances.
  • P1–P3, P1v2–P3v2, P1v3–P3v3 — Premium. Referenced as «Premium» app service plan above. Autoscaling. 1–30 instances.
  • EP1–EP3 — Elastic Premium. Manual scaling, 1–20 instances.
  • WS1–WS3 — Workflow Standard. Autoscaling.
  • EI1–EI3 — Elastic Isolated. Autoscaling.
  • U1: tiers HyperV_P1v2, HyperV_S1. No scaling.
  • U1–U3, tier LinuxFree. Autoscaling.
  • Y1 — Dynamic. This is what «Comsumption plan» creates behind the scenes.
  • I1–I3 — Isolated in ASE.

Azure App Service Web App: create

Diagnostics logging: enable

Web app: deploy code

TODO: https://docs.microsoft.com/en-us/azure/app-service/containers/tutorial-custom-docker-image

Web app configure: SSL, API settings, and connection strings

Autoscaling: implement rules, scheduled autoscaling and autoscaling by operational or system metrics

??? autoscale for functions

Azure functions

https://docs.microsoft.com/en-us/azure/azure-functions/

* Other technologies

  • WebJobs — non-serverless C# version.
  • LogicApps — declarative UI only.
  • Flow (Power Apps) — targeted at office users. Worse integration with Azure.

* Hosting options

https://docs.microsoft.com/en-us/azure/azure-functions/functions-scale

Consumption plan

az functionapp create with --consumption-plan-location option.

  • Fully serverless — no app service plan to be configured. => Pay when running.
  • No virtual networks.
  • Autoscale, 0 to 200. No way to avoid cold start.
  • Timeout, min: 5 default, 10 max.
  • 5TB temp storage.
  • Only CNAME for domain names.
## Create a serverless function app in the resource group.
az functionapp create \
  --name $functionAppName \
  --storage-account $storageName \
  --consumption-plan-location $region \
  --resource-group myResourceGroup \
  --functions-version 2
Elastic Premium plan

First, az functionapp plan create, then az functionapp create.

  • Autoscale, 0 to 100. May have warm starts — see scaling below.
  • Timeout, min: 30 to INF.
  • 250GB temp storage.
  • «Always on» should be enabled on the App Service plan.

Example

## Create a Premium plan
az functionapp plan create \
  --name mypremiumplan \
  --resource-group myResourceGroup \
  --location $region \
  --sku EP1

## Create a Function App
az functionapp create \
  --name $functionAppName \
  --storage-account $storageName \
  --plan mypremiumplan \
  --resource-group myResourceGroup \
  --functions-version 2
Dedicated plan

App service plan on dedicated machines (B1). This means:

  • Can do manual scaling.
  • Can use custom image.
  • Can re-use existing VM.

Example

## Create an App Service plan
az functionapp plan create \
  --name myappserviceplan \
  --resource-group myResourceGroup \
  --location $region \
  --sku B1

## Create a Function App
az functionapp create \
  --name $functionAppName \
  --storage-account $storageName \
  --plan myappserviceplan \
  --resource-group myResourceGroup \
  --functions-version 2

«ASE» (App Service Environment) is a container for isolated app service plans. One has to first create this environment, it will be available as a separate region which would have special «I» SKU plans.

Kubernetes

«KEDA» — Kubernetes event-driven autoscaling.

* Scaling

Event-driven scaling: https://docs.microsoft.com/en-us/azure/azure-functions/event-driven-scaling.

  • Unit of scaling is function app. Functions inside an app all scale at the same time.
  • Max instances is 200, but one instance may handle multiple requests.
  • HTTP trigger: 1 instance per second. Other triggers: 1 instance per 30 seconds.
  • Service bus triggers: LISTEN right is not enough to see queue length and scale, need more.
  • Scale out can be limited by setting functionAppScaleLimit.

Warm starts in Premium and Dedicated plans:

  • «Always ready instances»: minimumElasticInstanceCount property of function app.
  • «Pre-warmed instances»: preWarmedInstanceCount property of function app.

Pre-warmed instances are provisioned in addition to the used ones. Always ready instances are counted as one.

Azure Functions: create and deploy

Links:

My script.

az group create -n az204func -l westeurope
az storage account create -n az204orlovfuncstorage -g az204func
az functionapp create -n calcfuncapp -g az204func -s az204orlovfuncstorage --functions-version 2 --consumption-plan-location westeurope

* Triggers and bindings general

Good introduction.

Specified either in function.json or as attributes in C#. List of supported bindings.

C## attributes are specific per target type.

It is possible to specify parameters as curly braces (e.g. {name}) in function.json, function parameters, or code. That’s called binding expressions. They are taken from some internal dictionary and are shared between bindings/trigger. HttpTrigger can set JSON payload values. Blob trigger — file name.

Example of function.json:

{
  "bindings": [
    {
      "authLevel": "anonymous",
      "name": "req",
      "type": "httpTrigger",
      "direction": "in",
      "methods": ["get", "post"]
    },
    {
      "name": "$return",
      "type": "http",
      "direction": "out"
    },
    {
      "name": "inputBlob",
      "direction": "in",
      "type": "blob",
      "path": "incontainer/{name}",
      "connection": "AzureWebJobsStorage"
    }
  ]
}

Input and output bindings

(see above)

Supported bindinds list.

Multiple bindings per function.

Notes.

  • Mobile Apps input binding. Loads a record from a mobile table endpoint and passes it into function.
  • Azure Cosmos DB trigger, input bindings, and output bindings only work with Core SQL API and Graph API accounts.
  • Microsoft Graph - output bindings allow you to write to files in OneDrive, modify Excel data, and send email through Outlook.

Function triggers: using data operations, timers, and webhooks

(see above)

1 trigger per function.

Notes.

  • HttpTrigger. It is possible to require a key for requests as x-functions-key header. These keys are specified in «function keys», but are required by the trigger.
  • Time trigger. CRON format: {second} {minute} {hour} {day} {month} {day of the week}. */10 means «every 10 minutes.

Durable Functions: implement

Link

Idea: Code-first version of Logic Apps. Implemented as functions with custom templates.

  • Client — entry points based on trigger. A function that gets IDurableOrchestrationClient starter parameter. It can start functions and raise events (which are to be handled in the orchestrator).
  • Orchestrator — workflow in code. A function that gets IDurableOrchestrationContext context which has CallActivity method.
  • Activity — basic orchestrated unit of work. Is an Azure Function. Have Run, by default without arguments.
  • Entity — stores state. Gets parameter [EntityTrigger] IDurableEntityContext ctx. Can get and set values to it. Usually has «add» and «get» operations. Som activity can reference [DurableClient] IDurableEntityClient entityClient and call SignalEntityAsync to send «add» to an entity function which will update the context.

Chaining activities is done by passing the previous one (it’s a Task) as the second argument of CallActivityAsync:

var x = await context.CallActivityAsync<object>("F1", null);
var y = await context.CallActivityAsync<object>("F2", x);

Waiting for events. They are sent by RaiseEventAsync and are kept in the queue. First argument when raising events is instanceId that will handle the event. Events are handled by WaitForExternalEvent

var gate1 = context.WaitForExternalEvent("CityPlanningApproval");

Custom handlers

Link

host.json configured to call a custom executable for each function. Possible to handle HTTP triggers directly (optimization).

Develop for Azure storage (15-20%)

TODO: https://docs.microsoft.com/en-us/learn/paths/store-data-in-azure/

Cosmos DB

TODO: https://docs.microsoft.com/en-us/azure/cosmos-db/

API and SDK for a solution: select

Partitioning schemes and partition keys

TODO: https://docs.microsoft.com/en-us/azure/cosmos-db/partitioning-overview

Operations on data and Cosmos DB containers: perform

CloudTableClient???

compositeIndexes - CosmosDB policy to order by multiple.

Consistency level for operations: set

TODO: https://docs.microsoft.com/en-us/azure/cosmos-db/throughput-serverless

Change feed notifications: manage

TODO: https://docs.microsoft.com/en-us/azure/cosmos-db/change-feed-design-patterns

Blob storage

TODO:

Move items in Blob storage between storage accounts or containers

Properties and metadata: set and retrieve

Operations on data by using the appropriate SDK

Storage policies, data archiving and retention

Implement Azure security (20-25%)

Implement user authentication and authorization

Microsoft Identity platform

TODO: https://docs.microsoft.com/en-us/azure/active-directory/develop/

Azure Active Directory

TODO: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/

Shared access signatures (SAS)

TODO:

Implement secure cloud solutions

App Configuration Azure Key Vault: secure app configuration data

TODO: https://docs.microsoft.com/en-us/azure/key-vault/general/

Azure Key Vault: develop code that uses keys, secrets, and certificates

TODO: https://docs.microsoft.com/en-us/azure/key-vault/general/tutorial-net-create-vault-azure-web-app

Managed Identities for Azure resources: implement

TODO: https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview

Microsoft Graph: implement solutions that interact with

TODO: https://docs.microsoft.com/en-us/graph/overview

Monitor, troubleshoot, and optimize Azure solutions (15-20%)

Caching and content delivery within solutions

TODO:

Azure Redis Cache: configure cache and expiration policies

Cache patterns: data sizing, connections, encryption, and expiration

Azure CDN.

Cache levels: override (duration, but not no-cache), set if missing, bypass.

Monitoring and logging

TODO:

Application Insights: configure an app or service to use it

TODO: https://docs.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview

Azure Monitor: analyze and troubleshoot solutions by using it

TODO:

Link

Sampling: adaptive, fixed, ingestion.

Application Insights web tests and alerts: implement

TODO:

Connect to and consume Azure services and third-party services (15-20%)

API Management: Implement

Link

It is possible to import Functions to management.

Benefits learn page

Inbound, outbound, backend policy types.

APIM instance: create

TODO: https://docs.microsoft.com/en-us/azure/api-management/get-started-create-service-instance-cli

New-AzureRmApiManagementBackendProxy???

Authentication for APIs: configure

TODO: https://docs.microsoft.com/en-us/azure/api-management/security-controls-policy

Policies for APIs: define

TODO: https://docs.microsoft.com/en-us/azure/api-management/api-management-howto-policies

Develop event-based solutions

TODO: https://docs.microsoft.com/en-us/learn/paths/connect-your-services-together/

Azure Event Grid: implement solutions that use

TODO: https://docs.microsoft.com/en-us/learn/modules/react-to-state-changes-using-event-grid/

Azure Event Hubs: implement solutions that use

TODO: https://docs.microsoft.com/en-us/learn/modules/enable-reliable-messaging-for-big-data-apps-using-event-hubs/

Develop message-based solutions

* Services

Link, Compare

  • Event Grid — high-level events between Azure services. Calls subscribers.
  • Event Hubs — send and read events. Pull model.
  • Service Bus — High-value enterprise messaging. Optional order preservation. Integrates with Event Grid. Implementation of AMQP.

Azure Service Bus: implement solutions that use

TODO:

Topic, subscription, namespace relationship???

Azure Queue Storage queues: implement solutions that use

TODO: https://docs.microsoft.com/en-us/learn/modules/communicate-between-apps-with-azure-queue-storage/

Plan

07-19 (2)

  • Develop message-based solutions
  • Develop event-based solutions
  • (Check dumps)

07-20 (2)

  • Container images, Azure Container Registry, Azure Container Instance

07-21 (2)

  • API Management: Implement
  • ARM templates
  • VM: provision

=> Connect to and consume Azure services and third-party services (15-20%)

=> Develop Azure compute solutions (25-30%)

07-22 (2)

  • Implement user authentication and authorization

07-23 (2)

  • Implement secure cloud solutions

=> Implement Azure security (20-25%)

07-24 (5)

  • Monitoring and logging
  • Caching and content delivery within solutions

=> Monitor, troubleshoot, and optimize Azure solutions (15-20%)

07-25 (5)

  • Blob storage
  • Cosmos DB

=> Develop for Azure storage (15-20%)

07-26 (2)

  • Ad-hoc