Azure-in-bullet-points

Designing for Deployment, Migration and Integration

Azure Resource Manager

• Designed to represent each service in Azure as a resource provider and each service instance in Azure as a modular resource.
• JSON templates are used to deploy collections of resources using Infrastructure-as-Code concepts.
• Resource groups
  • Common lifecycle for resources: They can be created, managed, monitored, or deleted together.
  • The Resource Manager also offers the concept of resource group templates
    • You define a service unit in advance, and then use the template to create as many resource groups as you need.

• You can interact with Resource Manager using PowerShell, CLI, Client libraries, Visual Studio, Portal, REST API.

• Azure Resource Manager (ARM) Objects
  • Envision your solution using ARM
    • Start by designing and conceptualizing your entire solution considering all components that may compose your solution.
    • Then identify individual units of functionality and find resources available on Azure that can facilitate the specific functionalities.
  • Resource : Single service. E.g. web app, app service plan, SQL database.
  • Resource group : Logical grouping of resources.
  • Resource group template : JSON file that describes a set of resources.
• ARM Templates
  • Some or all of the properties of the resource can be parameterized so that you can customize your deployment by providing parameter values at deployment time.
  • Deployment
    • ARM Templates are deployed in a few ways.
      • These depend on your aims, the result intended and your chosen method for development.
    • A developer may choose to use Visual Studio to create and deploy ARM templates directly and to manage the lifecycle of the resources through Visual Studio.
    • An administrator may choose to use PowerShell or the Azure Command Line to deploy resources and amend them.
    • An end user without command line or developer skills would choose to use the Azure Portal to deploy resources without realizing a template is involved. E.g. marketplace offerings.
  • Advantages:
    • Ensure idempotency : Identical template to multiple resource => same functionality.
    • Simplify orchestration : Automatize.
    • *Configure multiple resources : Order, fix dependencies.
    • Parameterize : Define input & input for reuse. Can be nested for larger orchestration.
  • Template resources: Parameters (=> Variables ) => Resources => Output
• JSON schema

  • Empty ARM template:

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

  • Required: content, resources
  • Optional: parameters, variables, output.
  • Sources:
    • The Azure Quickstart templates on Github are
    • Inspect Automation script element of objects.

Role-Based Access Control (RBAC)

• You can assign roles to existing Azure AD identities that grants them pre-determined levels of access to an Azure subscription, resource group or individual resource.
• Some built-in roles:
  • Owner : Owner can manage everything, including access.
  • Contributor : Contributors can manage everything except access.
  • Reader : Readers can view everything, but can’t make changes.
  • User Access Administrator : Allows you to manage user access to Azure resources.
  • Virtual Machine Contributor : Allows you to manage virtual machines, but not access to them, and not the virtual network or storage account they are connected to.
• Role Assignment
  • Associates a security principal to a role in a given scope.
    • Security principals:
      • Users:
        • Users in AD of the subscription.
        • Can be assigned to external Microsoft accounts in same directory.
      • Groups
        • AD security groups.
        • Best practice.
      • Service principals
        • Service identities.
          • Authenticates with Azure AD to communicate with each other.
        • Can be granted access to other resources by assigning roles.
    • Resource Scopes:
      • Subscriptions, resource group, individual resources.
      • Resource inherits assignments from its parent resources.
        • Access inheritance: Subscription => Resource Groups => Resources
      • Scoping to Resource Groups
        • Add/remove and modify resources quickly without having to recreate assignments and scopes
        • Owner or contributor access => Does not require additional administrator assistance or having access to resources in other resource groups.
  • Custom roles
    • Use REST API.
    • ❗ Azure AD tenant is limited to 2000 custom roles.
    • To create a new custom role you run the New-AzureRmRoleDefinition cmdlet
      • You can pass a JSON template to the cmdLet or use PSRoleDefinitionObject.

      • E.g. json:

        {
          "Name": "New Role 1",
          "Id": null,
          "IsCustom": true,
          "Description": "Allows for read access to Azure storage and compute resources",
          "Actions": [
            "Microsoft.Compute/\*/read",
            "Microsoft.Storage/\*/read",
        
          ],
          "NotActions": [
          ],
          "AssignableScopes": [
            "/subscriptions/c489345-9cd4-44c9-99a7-4gh6575315336g"
        ]
        }
        

Resource Policies

• Azure Resource Policies
  • Resource Policy is a service that controls which resources can be created and what for they take, such as naming conventions, locations, and sizes.
  • Ensure that resources created in the cloud comply with corporate standards and service level agreements.
    • E.g. preventing users from creating resources in specific locations and of specific types and sizes
  • Contains two elements, a policy definition, and a policy assignment
  • There are many pre-defined policy definitions built into Azure.
• Policy vs. RBAC
  • RBAC controls user access, permissions, privileges, and actions at different scopes.
  • Policy evaluates resource properties for already existing resources and during deployment
    • E.g. control which type of resource is available for deployment in your organization
    • E.g. limit the locations in which you deploy resources or require your resources to follow naming conventions
• Azure policy is a default allow, and explicit deny system as opposed to RBAC.
• Create policies
  • The contributor role does not contain the necessary permissions.
  • You need:
    • Microsoft.Authorization/policydefinitions/ write permission to define a policy.
    • Microsoft.Authorization/policyassignments/ write permission to assign a policy.
• Built-in Policies
  • E.g. allowed locations, allowed resource types, allowed storage account SKUs, allowed virtual machine SKUs, apply tag and default value, enforce tag and value, not allowed resource types, require SQL Server version 12.0, require storage account encryption.
    • Inclusion is to limit the number a user is required to create to manage their subscription efficiently.
• Policy Definition
  • Every policy definition contains a minimum of two elements:
    • Conditions under which it is enforced.
    • An action that triggers if the conditions are met.
  • Policy definition JSON elements: • mode • parameters • display name • description • policy rule • logical evaluation • effect

  • E.g.

      {
              "if": {
                      "field": "type",
                      "in": "[parameters('listOfResourceNotAllowed')]"
              },
              "then": {
                      "effect": "Deny"
              }
      }
    

  • During assignment, the list of resource types not allowed parameter is populated and evaluated against all current resources in scope for the assignments.
  • Any non-compliant resources will be identified. When creating new resources, the deployment will fail if they are non-compliant.
  • The definition can contain multiple if, then blocks and combines logical operators, conditions, and fields to build out the policy.
  • The policy can define alternative effects.
    • Alternate effects: • Deny • Audit • Append • AuditIfNotExists • DeployIfNotExists
  • You can assign any of these policy definitions through the Azure portal, PowerShell, or Azure CLI.
• Policy Assignment
  • Occurs over a specific scope.
  • A scope is the list of all the resource groups, subscriptions, or management groups that the policy definition is assigned to.
    • Management group
      • Groups multiple subscriptions within an enterprise.
      • Allows you to enforce policies on multiple subscriptions.
  • Policy assignments are inherited by all child resources.
    • This can be altered or prevented using the exclusion option at the time of assignment.
  • The scope, exclusions, and parameters of the Not Allowed resource types are shown in the policy assignments blade when assigning a definition.
  • Azure policies can be assigned using the Azure Portal, Azure PowerShell, and the Azure CLI.
  • Initiative Definition
    • Collection of policy definitions that are designed to achieve a design goal.
    • Can be assigned as a group to simplify the process of achieving that goal.
    • Appears as a single item.
• Policies for Naming Conventions
  • These can use wildcards, patterns tags, and multiple patterns to apply restrictions to your Azure resource names.
  • E.g. a pattern match asserting that is the resource name does not begin contoso and have six characters as the rest of the name then it will be non-compliant.

    • E.g. the resource name must begin contoso and have six characters as the rest of the name.

        {
          "if": {
            "not": {
              "field": "name",
              "match": "contoso??????"
            }
          },
          "then": {
            "effect": "deny"
          }
        }
      

Securing ARM templates

• Azure Key Vault
  • Create, manage and import secrets, keys, and certificates for applications, services and users.
  • When deploying resources using Arm templates and automating that deployment, it is best practice to use a Service Principal.
    • In on-prem AD it was called: Active Directory Service Account
  • The premium tier allows storage of these secrets in a Hardware Security Module, a physical device to contain all your secrets.
  • Flow:
    • Administrator creates & manages vaults and keys.
      • Can be created by any contributor/owner.
    • Sends URIs to developers.
    • Security administrators uses usage logging for keys.
  • Dev/test keys can be migrated to production use at deployment.
    • Key Vault Use in ARM Templates
      • Embedding credentials and passwords inside a template are unwise.
      • To further secure the deployment, it is advised to create an Azure Service Principal.
      • With key vaults the value is never exposed because you only reference its key vault ID.
      • Use in ARM templates
        1. Set the enabledForTemplateDeployment property to true when you create the Key Vault.
        2. Create secret to be used in template
        3. Ensure template can access Key vault
           • Ensure the service principal, user or template has the Microsoft.KeyVault/vaults/deploy/action permission for the correct Key Vault
           • The Contributor built-in role already has this permission.
        4. Reference the secret using a static ID in the template parameter file.
           • ❗ Challenge: Sometimes the Key Vault secret will change from deployment to deployment
             • It this requires the use of a dynamic ID reference.
             • It cannot go in the parameter file.
             • 💡 Solution: Nested template where key is also deployed.

Deploying ARM templates

• Problem defination
  • Authoring and deployment of ARM templates can be hard:
    • Become very complex in a short amount of time.
    • Difficult to ensure that Microsoft best practices for Azure infrastructure are reflected in every template authored by your team.
  • Development of your templates follows a pattern:
    • E.g.:
      1. JSON object for a virtual network
      2. JSON object for virtual machines that are deployed into the virtual network.
      3. JSON object for a network security group to secure the virtual network.
      4. JSON object for a load balancer to distribute incoming requests to the virtual machines
  • Problem:
    • Great deal of knowledge about Azure Resource Manager and the resources themselves.
    • Difficulty maintaining your templates because any modification can lead to unforeseen issues.
• Azure Building Blocks
  • Command line tool and set of ARM templates.
    • Reflect best practices as prescribed by the Patterns & Practices team at Microsoft.
  • Designed to simplify deployment of Azure resources.
    • Flow:
      1. Specify settings for Azure resources using the Building Blocks JSON schema
         • You can either specify your resources settings in one large file or several small files.
         • Supports: • Virtual Networks • Virtual Machines (including load balancers) • Virtual Machine Extensions • Route Tables • Network Security Groups • Virtual Network Gateways • Virtual Network Connection
      2. Command line tool merges these settings with best practice defaults (from GitHub templates) to produce a set of parameter files
      3. The command line tool deploys these parameter files using a set of pre-built Azure Resource Manager templates
  • Deploying resources using building blocks
    1. Install azbb command line tool and the Azure CLI.
    2. Create building blocks
       • Create a JSON file with a buildingBlocks parameter containing an array of resources that you wish to deploy.
         • Each resource within that JSON array can have certain options configured.
         • E.g. Virtual Network resource => addressPrefix, subnets and name.
         • Any options you do not specify are set using the default options specified in the building blocks repository.
         • E.g. deploying a Virtual Network:
           • Properties:
             • type :identify the type of building block. E.g. VirtualNetwork.
             • name : Unique name of the resource
             • addressPrefixes : Array of address ranges in CIDR notation.
               • E.g.: "addressPrefixes": [ "10.0.0.0/16", "11.0.0.0/16" ]
           • subnets :ian array—we can specify up to 1,000 subnets for each VNet.
    3. Create a settings file
       • Run the azbb command line tool to parse your settings and combine it with the default settings from the building blocks repository
         • The azbb command line tool will output an ARM template parameters file,

       • Empty settings file:

         {
         
           "$schema": "https://raw.githubusercontent.com/mspnp/template-building-blocks/master/schemas/buildingBlocks.json",
           "contentVersion": "1.0.0.0",
           "parameters" : {
             "buildingBlocks": {
               "value": [
                 {}
               ]
             }
           }
         }
         

       • E.g. deploying a Virtual Network

         {
           "$schema": "https://raw.githubusercontent.com/mspnp/template-building-blocks/master/schemas/buildingBlocks.json",
           "contentVersion": "1.0.0.0",
           "parameters": {
             "buildingBlocks": {
               "value": [
                 {
                   "type": "VirtualNetwork",
                   "settings": [
                     {
                       "name": "msft-hub-vnet",
                       "addressPrefixes": [
                         "10.0.0.0/16"
                       ],
                       "subnets": [
                         {
                           "name": "firewall",
                           "addressPrefix": "10.0.1.0/24"
                         }
                       ]
                     }
                   ]
                 }
               ]
             }
           }
         }
         

    4. Deploy
       • azbb tool will use the Azure CLI (version 2.0) to deploy the master ARM template from the building blocks repository using the parameters file that was generated.
         • The Azure deployment will create a collection of resources within an Azure Resource Group.
           • It’ll have historical deployment information:
             • You can go back and view the template and parameters used by the building blocks command line tool to deploy your resources.
       • Command:
         • azbb -g <new or existing resource group> -s <subscription ID> -l <region> -p <path to your settings file> --deploy

Managed Server Applications in Azure

• Infrastructure-Backed Platform-as-a-Service (IaaS) architecture that can be used when automatic management of infrastructure is required.
• Every Microsoft Azure PaaS service is already hosted on Azure IaaS.
• Three services available:
  • App Service Environments provides a dedication scalable home for Azure Web Apps.
  • Azure Service Fabric provides a cluster of VMs to host containers and microservices for those applications.
  • Azure Container Service provides open source tools to orchestrate containers based on Docker Swarm, Mesosphere and Kubernetes clusters
• App Service Environments
  • App Services separate many of the hosting and management concerns for your web application.
  • You want sometimes more control:
    • E.g. make sure that all of the virtual machines hosting your web applications do not allow any outbound requests. (PCI compliance)
  • ASE allows you to configure network access and isolation for your applications.
  • ASE also allows you to scale using pools of instances far beyond the limits of a regular App Service plan instance
  • ASE instances are dedicated to your application alone.
  • ASE gives you more control but retain: automatic scaling, instance management, and load balancing,
  • Same concepts & paradigms as Virtual Machines:
    • Environments are created within a subnet in an Azure Virtual Network
    • You can use Network Security Groups to restrict network communications to the subnet where the Environment resides.
    • You can also use a protected connection to connect your Virtual Network to corporate resources
  • Versions
    • V1: Supports both classic and Resource Manager Virtual Networks
    • V2: Only resource Manager resources.
      • Automates most of the scaling, creation, and maintenance which v1 requires to be carried out manually.
• Azure Service Fabric
  • Solution making it simple to package, deploy, and manage scalable and reliable containers and microservices.
  • Assists with the developing and managing cloud native applications.
  • Intended for container-based applications running on enterprise-class, cloud-scale environments.
  • Microservice based applications
    • Creates a cluster of VMs that runs containers per stateful or stateless microservice.
    • Assists with provisioning, deploying, monitoring and managing in fast and efficient, automated fashion.
    • Powers Service many Microsoft services today, including Azure SQL Database, Azure Cosmos DB, Cortana, Microsoft Power BI, Microsoft Intune, Azure Event Hubs, Azure IoT Hub, Dynamics 365,__Skype for Business, and many core Azure services.
  • Application lifecycle management
    • Supports the application lifecycle and CI/CD of cloud applications including containers.
    • Simple workflows to provision, deploy, patch, and monitor applications
    • Integrating with CI/CD tools such as Visual Studio Team Services, Jenkins, and Octopus Deploy.
    • It hosts microservices inside containers that are deployed and activated across the Service Fabric cluster.¨
      • Service fabric cluster
        • Node type count: 1 to 3
          • Per node, durability tiers: Bronze, Silver, Gold.
  • Service Fabric Analytics
    • Requires Azure Diagnostics
    • Can be added from marketplace
      • Get insight into your Service Fabric framework
      • Get insight into the performance of your Service Fabric applications and micro-services
      • View events from your applications and micro-services
      • E.g. StatefulRunAsyncCancellation, SatefulRunAsyncFailure
• Azure Container Service
  • Simplifies processes associated with creating, configuring, and managing virtual machines.
  • Supports three orchestration services:
    • Docker Swarm
    • Mesosphere DC/OS
    • Kubernetes
  • You are only charged for these VMs, Storage and networking resources actually used.
  • Contains AKS => Azure Kubernetes Service.
    • Azure manages health, maintenance, and monitoring.
    • Easy scaling, automatic version upgrades, and self-healing master nodes.
    • Can be deployed into VNet
    • Application routing: get a public DNS endpoint Azure DNS that has direct ingress into Kubernetes cluster into the container that’s providing the front-end of that application.
    • Container insights: Logs/metrics from containers
    • Access is provided to the Kubernetes API endpoints.
      • There is no SSH access to the AKS cluster.
    • Orchestration:
      • Multiple copies of each containers for high availability and scalability.
      • Allows deploying container images across a set of VMs.
      • Configures networking
      • Service discovery betwen them.
      • Doing health monitoring on the containers.
    • Virtual Kubelet => Microsoft project that allows Azure Container Instances to run on AKS (in development).
• Azure Container Instance
  • Only pay while it’s building
  • Do not pay when it’s done

High-Performance Compute (HPC)

• High Performance Computing
  • Typically describes the aggregation of complex processes across many different machines thereby maximizing the computing power of all of the machines.
  • Massively scalable parallel processing of memory-intensive workloads, such as 3D rendering and tasks that process, transform, and analyze large volumes of data.
  • Azure Batch provides this service for short-term massively scalable infrastructure
  • For other cloud-based and even hybrid solutions, Azure provides access to both Windows and Linux HPC clusters.
  • Through HPC in the cloud, one could create enough compute instances to create a model or perform a calculation and then destroy the instances immediately afterward.
  • Advancements in the HPC field have led to improvements in the way that machines can share memory or communicate with each other in a low latency manner.
  • Microsoft Azure platform has a large number of features that support HPC, including HPC Pack, Azure Batch, and Stateless Component Workloads.
• Remote Direct Memory Access
  • Remote Direct Memory Access, or RDMA, is a technology that provides a low-latency network connection between processing running on two servers, or virtual machines in Azure.
  • From a developer perspective, RDMA is implemented in a way to make it seem that the machines are “sharing memory.”
  • RDMA is efficient because it copies data from the network adapter directly to memory and avoids wasting CPU cycles.
  • VM sizes A8 to A19 => Most efficient way to run
• HPC Pack
  • Microsoft’s HPC cluster and job management solution for Windows.
  • Can be installed on a server that functions as the “head node”
    • The server can be used to manage compute nodes in an HPC cluster.
  • Can be in hybrid scenarios where you want to “burst to Azure” with A8 or A9 instances to obtain more processing power.
  • Supports several Linux distributions to run on compute nodes deployed in Azure VMs, managed by a Windows Server head node.
• Azure Batch
  • Managed HPC pack offering on Azure.
  • Provides
    • Auto-scaling
    • Job scheduling
    • compute resource management
      • VM’s of compute nodes
  • Includes end-of-cycle processing such as a bank’s daily risk reporting or a payroll that must be done on schedule.
  • Includes large-scale business, science, and engineering applications that typically need the tools and resources of a compute cluster or grid.
  • Batch works well with intrinsically parallel (sometimes called “embarrassingly parallel”) applications or workloads, which lend themselves to running as parallel tasks on multiple computers.
  • Concepts:
    • Pool
      • Number and size of machine
      • E.g. 100 machines, n1 series.
    • Job
      • Includes one or more code packages.
    • Task
      • Task to execute code package.
    • Execution:
      1. Starts all VM’s (takes time)
      2. Executes code
      3. Removes all VM’s
  • Scaling out Parallel Workloads
    • Through the Batch API
    • Can be managed as part of a larger workflow managed by tools such as Azure Data Factory.
    • You can wrap an existing application, so it runs as a service on a pool of compute nodes that Batch manages in the background.
      • You can develop the service to let users offload peak work to the cloud, or run their work entirely in the cloud.
      • The Batch Apps framework handles the movement of input and output files, the splitting of jobs into tasks, job and task processing, and data persistence.
• Stateless component workloads
  • You do not have to rely on the pre-defined HPC services.
  • Azure provides non-managed solutions and related services to provide a degree of HPC using IaaS.
    • These include: • Virtual Machines • VM scale Sets • Azure Container Services • HDInsight • Machine Learning and more.
    • Azure fabric is a good platform to deploy parallel compute tasks on several services.
  • 💡 Best practices:
    • Azure Resource manager to automate deployment.
    • Auto scale based on various criteria.
      • E.g. deploying a scale set manage an HPC workload by varying the number of VMs based on the queue length would combine auto-scale based on a custom metric with HPC Pack and templated infrastructure deployment.

Migration

• Migration strategies includes:
  1. On-premises lift and shift
     • Lift and shift approach
       • Provides all the benefits of pay as you go computing without the potential headaches of rewriting application code or re-architecting the application to fit a specific cloud application pattern.
     • Azure Migrate service
       • Discovery and assessment tool
       • Assesses suitability for migration and ensures that sizing is correct for the performance of the VM
       • Estimate of the cost of running your VM in Azure
       • Visualize dependencies of a specific VM or for all VMs in a group
       • ❗ Limitations
         • Provides assessment for only VMWare VMs
           • If you want to assess Hyper-VMs and physical servers, use the Azure Site Recovery Deployment Planner for Hyper-V, and our partner tools for physical machines.
         • Azure Migrate only supports managed disks for migration assessment.
         • All regions are not supported
       • Cloud maturity:
         1. On-premises monolithic architecture
         2. Lift and shift: No re-architect, no code changes
            • Cloud infrastructure-ready monolithic architecture
            • Cloud DevOps ready monolithic architecture
         3. Architected for the cloud, might require new code
            • Cloud optimized full PaaS & cloud-native with monolithic and microservices architectures.
  2. Classic (Azure Service Manager) migration to ARM
     • From Azure Service Manager (ASM) model to Azure Resource Manager (ARM) deployment.
     • Supported services: • Virtual Machines • Availability Sets • Cloud Services • Storage Accounts • Virtual Networks • VPN Gateways • Express Route gateways • Network Security Groups • Route Tables • Reserved IPs
  3. Cloud to Platform-as-a-Service (PaaS)
     • From cloud services to a PaaS solution
     • Necessary to consider the difference between VMs, workloads, and applications in each model.
     • Azure Cloud Services
       • Platform as a service (PaaS) in Classic Model (not ARM)
       • A cloud service deploys applications as VMs; code is connected to a VM instance which might be a Web role or a worker role,
         • Web role: Automatically deploys and hosts your app through IIS.
         • Worker role: Does not use IIS, and runs your app standalone
       • Scaling and management
         • To scale the application, more VMs are deployed.
         • You don’t create virtual machines. Instead, you provide a XML configuration file that tells Azure how many of each you’d like, such as “three web role instances” and “two worker role instances.”
         • You still choose what size those backing VMs should be
       • The deployment package
         • Contains the web role and worker role definition
         • Specifies the instance count for each role; an instance is a VM hosting that role.
     • Cloud Services with Worker Role_s can be migrated to _Service Fabric Cluster with Stateless Service
     • Migrating a cloud service to Service Fabric switches to deploying applications to VMs that are already running Service Fabric either on Windows or Linux.
     • The applications or services that are deployed are entirely unrelated to the VM infrastructure.
     • The service fabric application platform hides the VM layer from the application.
     • Handling dependencies
       • A cloud service application will typically have external dependencies which manage the data and state of an application and the method of communicating between web and worker roles.
         • E.g. Azure Redis, Storage queue, Service Bus.
       • A Service fabric application can also rely on the same external service dependencies.
       • The quickest and easiest way to migrate a Cloud Service application to service fabric:
         • Convert the Web roles and worker roles to stateless services whilst keeping the architecture the same.
       • If the aim is to remove the external dependencies and take full advantage of the ability to unify deployment, management and upgrade models, then state-full services would be required which will mean full code and application rewrites.

Authoring Serverless Applications in Azure

• App Services
  • It’s recommended to use the Standard or Premium tiers in order to support autoscale and SSL.
  • SKU’s:
    • Basic Tier
      • Scaling is manual
    • Standard or upper service tiers
      • Scaling is automatic
      • ❗ Standard tier allows to scale up to 10 instances.
        • 💡 If you still need more instances you can go to the Isolated tier where you can scale up to 100 instances
  • Authorization behavior in App Service
    • Allow all requests:
      • Use your own authentication and authorization code.
    • Allow only authenticated requests
      • User is challenged or returned 401
    • Allow Anonymous requests
      • Handles authentication & authorization
      • Defers authorization decisions to your application code
  • Web Apps
    • Low friction Platform-as-a-Service (PaaS) offering to host your web applications in the Azure platform.
    • The service is fully managed and you can easily configure advanced features such as AlwaysOn, custom domains, and autoscale by using either portal.
    • Deploy: Git, Kudu, Microsoft Visual Studio through FTP or Web Deploy protocol.
    • Supports .NET, Java, PHP, Node.js, or Python
    • Easy scaling: Autoscale creates multiple instances of your Web App that are automatically load balanced so that your application can meet potential spikes in demand.
    • Web app containers
      • The Linux variant specifically offers the ability to host Docker containers directly using a Web App.
      • The docker containers can be sourced from Docker Hub, Azure Container Registry or GitHub.
      • Containers can be deployed manually, or deployed in a streamlined continuous integration process using Docker Hub or GitHub.
  • API apps
    • Specialized version of Web Apps designed to server different purposes in an all-up solution on Azure.
    • Support for developing, hosting and securing your custom API’s in the context of App.
    • It can run either custom code or can run pre-built software to connect to existing popular SaaS solutions through Logic App.
    • API Apps share a lot of the same features and support as Web Apps.
    • Integrates seamlessly with API Management.
    • Easy authentication: service-to-service or CORS.
  • Mobile Apps
    • Mobile App endpoints are REST APIs.
    • Provides capabilities of:
      • Single sign on: From list of Azure AD.
      • Offline sync: Work offline when connectivity is not available, and synchronize with your enterprise backend systems when devices comes back online.
        • Any data source including, SQL, Table Storage,Mongo, or Document DB, and any SaaS API including Office 365, Salesforce, Dynamics, or on-premises databases.
      • Push notifications: You can easily hook Notification Hubs to any existing app backend.
      • Auto scaling
    • Client SDKs are available to connect mobile app to a Mobile App instance for its backend data.
      • Supported for: • Xamarin Android/IOS, • Android Native, • IOS Native, • Windows Store, • Windows Phone, • .NET, • HTML
• Azure Functions
  • Function Apps were implemented using the existing code and base functionality for Azure WebJobs.
  • Function Apps can be created using one of two models:
    • App Service : Function Apps exist as another kind of app within an App Service Plan.
    • Consumption :
      • The consumption model allows you to pay for Function Apps based on execution time as opposed to having a dedicated App Service Plan.
      • Function Apps are billed at a rate specific to Gigabyte Seconds after a specific free monthly allocation threshold has been met.
  • Function Apps share a lot of functionality with other App types such as Web Apps. You can configure App Settings, Connection Strings, AlwaysOn, Continous Deployment and many other settings that are configurable in a Web App instance.
    • Enable AlwaysOn for Function App to respond to requests as quickly as possible.
  • Authorization level of functions:
    • Anonymous: No API key is required.
    • Function: A function-specific API key is required.
    • Admin: The master key is required.
  • Event-Based triggers
    • A Trigger is anything that invokes an Azure Function.
    • Can have triggers for many different scenarios including: • Creation of Blobs • Changes to data in Cosmos DB • External File or Table changes • HTTP requests • OneDrive or Excel files • E-mail messages • Mobile Apps • SendGrid e-mails • Twilio Text Messages
    • Azure Functions can also be triggered by existing messaging services including: • Service Bus • Storage Queues • Logic Apps • Event Grid • Event Hubs • Webhooks
• Integration
  • API Management
    • Provides the core competencies to ensure a successful API program through developer engagement, business insights, analytics, security and protection.
    • Flow
      • Administrators create APIs.
        • Each API consists of one or more operations, and each API can be added to one or more products.
          • A product is segmentation/grouping of APIs.
            • Access policies can be enforced.
            • Defines API’s (endpoints)
      • Subscribers: Developers/B2B partners subscribe to a product that contains that API, and then they can call the API’s operation, subject to any usage policies that may be in effect.
    • Portals
      • Publisher portal: Admin portal.
        • Configures API’s & products & subscribers.
      • Developer portal: Partners can test the services.
    • Example: | API | Products | Subscribers | | — | — | — | | • DEVICEINFO • BUILDINFO • ORDERS • DELIVERYORDER • SHIPMENT • MILESTONES • RETURNDEVICE | • DCServicesExternal • DCServicesInternal • MakeInternal • MakeExternal • ReturnsInternal • ReturnsExternal | • Arvato • Ups • Fedex • Walmart • Amazon |
  • Logic Apps
    • Workflows that can connect various components of your application together using minimal or no-code.
    • Designed using JSON.
    • Logic Apps can integrate with existing services using built-in connectors. There are connectors available for popular services such as: SQL Server • OneDrive • Dropbox • Twilio • SendGrid • Cosmos DB • Event Grid • Event Hubs • Storage Blobs, Queues and Tables • Mobile Apps
    • Logic Apps can also integrate with custom APIs that are deployed as API Apps in your subscription.
    • The main components of a Logic App are as follows:
      • Workflow : The business process described as a series of steps, in an acyclic graph (loops are not supported).
      • Triggers : The step that starts a new workflow instance.
      • Actions : A step in a workflow, typically a Connector or a custom API App.
      • Connector : A special case of API App ready made to integrate a specific service (e.g., Twitter) or data source (e.g., SQL Server).
    • E.g. Azure Service Bus Connector to queue processing that you will run on HDInsight against some big data, and then send the result via an SMS message using the Twilio connector.
  • Traffic Manager
    • Automatically fails over if the primary region becomes unavailable.
    • Supports several routing algorithms
      • g. priority routing (formerly called failover routing): all requests are sent to prioritized endpoint until it’s unhealthy.
  • Multi-region model
    • Using a multi-region architecture provides a higher availability of your applications.
    • 💡 Have paired region as secondary region as paired regions are prioritized during outage.
  • Example
    • Regions
      • Active region: Where application with SQL lies.
      • Standby region: Where application exists and SQL is replicated.
    • A regional outage affects the primary region, you can use Traffic Manager to fail over to the secondary region.
    • Use SQL database geo-replication to the standby region.

This site is open source. Improve this page.