3. Deploy and manage Azure compute resources.md

Deploy and manage Azure compute resources (20–25%)

Automate deployment of resources by using Azure Resource Manager (ARM) templates or Bicep files

• Interpret an ARM template or a Bicep file
• Modify an existing ARM template
• Modify an existing Bicep file
• Deploy resources by using an ARM template or a Bicep file
• Export a deployment as an ARM template or compile a deployment as a Bicep file

Azure Resource Manager (ARM)

ARM provides the ability to work with the resources in your solution as a group instead of individual components.

• Deploy, update, or delete all resources for solutions in a single operation
• Use templates for deployment
• Templates can work for testing, staging, and production environments
• Provides security, auditing, and tagging to assist with managing resources after deployment
• Provides the ability to monitor all resources for your solution
• Repeatedly deploy solutions throughout the development lifecycle while ensuring they're deployed consistently
• Templates are declarative and can be used to manage the infrastructure instead of using scripts
• RBAC can be applied to all service within the resource group since it's natively integrated into the management platform
• Tags can help logically organize resources within the subscription
• The organization's billing can be clarified by viewing the costs for groups of resources using the same tags

ARM provides a way to consistently manage resources by performing tasks through:

• Azure PowerShell
• Azure CLI
• The Azure portal
• REST API
• Client SDKs

Take advantage of ARM while working with solutions by:

• Defining all deployment and config steps using the template(s). No manual steps should be required to setup solutions
• Running commands like starting/stopping an app or machine to manage resources
• Organizing resources with the same lifecycle using resource groups
  • Use tags to organize additional resources

ARM Templates

ARM Templates are JSON documents, written in a declarative syntax.

• Declarative syntax is what powers declarative automation, which is the automated deployment of resources.

Benefits include:

• Improve consistency: the structure, format, and expresses in the template will remain the same regardless of what tools are used to deploy the ARM template(s).
• Link templates together: allows the templates to become modular.
• Save time & prevent errors: manually creating & connecting resources is time consuming and leave room for errors.
• Easily express complex deployments: multiple resources can be deployed in the correct order using templates.
  • ARM will map out each resource and the dependencies to ensure dependent resources are created and deployed first.
• Express requirements through code: templates are a type of IaaS and can be shared, tested, and versioned.
  • Can be used with Git for version control.
• Promote reuse: templates can require params that are filled out when it runs.
  • Ex: domain name, username or password, etc.
• Simplify orchestration: instead of deploying each resource independently, all of your resources can be deployed by deploying the template.

ARM Template Schema

JSON documents are a collect of key-value pairs.

• Each key is a string and the values can be:

  • A string
  • List of values
  • Number
  • Boolean expression
  • An object (aka a collection of other key-value pairs)

• $schema: the location of the JSON schema file that describes the version of the template language.

  • Required

• contentVersion: the version of the template. This value is used to document major changes in the template & can be used to identify the proper template is being utilized.

  • Any value can be provided for this.
  • Required

• parameters: values that are provided when deployment is executed to customize resource deployment.

  • Not required - Important: each template is limited to 256 params; reduce the number by using objects that contain multiple properties.

• variables: values that are used as JSON fragments in the template which simplify the template language expressions.

  • Not required

• functions: user-defined functions available within the template

  • Not required

• resources: the types of resource that gets deployed, or updated, in a resource group.

  • Required

• outputs: values that are returned after deployment

  • Not required

Bicep Templates

Azure Bicep is a domain-specific language (DSL) and can be used instead of JSON to develop ARM templates.

• Like ARM templates, it uses declarative syntax to deploy resources and supports code reuse.
• Additionally, it provides reliable type safety.

Bicep syntax:

• Reduces complexity
• Improves the development experience

Note: Bicep is a transparent abstraction over ARM templates and don't lose any of the capabilities of JSON templates.

When deploying a resource, or multiple resources, Bicep will convert the template into a JSON template.

• Transpilation: the process of converting source code to another language.

Benefits of using Bicep over JSON templates:

• Simple syntax: provides a simpler syntax for writing templates which makes reading and writing Bicep templates easier.
  • Params and variables can be referenced directly.
  • String interpolation is used to combine values for names and other items, instead of concatenation.
  • Properties of a resource can be referenced directly by using the symbolic name vs complex reference statements.
• Automatic dependency management: Bicep autodetects dependences between resources which reduces some of the work required to write templates.
• Type validation & IntelliSense: VS Code offers a Bicep extension which provides rich validation and IntelliSense for all Azure resource type API definitions, which makes writing templates easier.
• Modules: complex templates can be broken down into smaller module files, which can be referenced in the main template.
  • Provides easier management as well as making the template writing process easier.

Create and configure virtual machines

• Create a virtual machine
• Configure Azure Disk Encryption
• Move a virtual machine to another resource group, subscription, or region
• Manage virtual machine sizes
• Manage virtual machine disks
• Deploy virtual machines to availability zones and availability sets
• Deploy and configure an Azure Virtual Machine Scale Sets

Azure Virtual Machines

Working with VMs allows you to have more control over the installed software and configuration settings.

Characteristics of Azure VMs include:

• Based on the infrastructure as a service (IaaS) model, which is an instant computing infrastructre that's provisioned and managed over the web.
• VMs provide their own OS, storage, and networking capabilities, and can run a wide range of apps.
• VMs can be quickly scaled up and down on demand, allowing you to pay for what you use.
• Multiple VMs can be implemented, and each machine can be configured with different software and config settings to support different operations (deployment, testing, and deployment environments).
• Microsoft and the customer share responsibility associated with configuring and maintaining VMs.

Before using IaaS and VMs, you should consider the following:

• Test and development: quickly setup and tear down test & dev environments to push apps out faster.
• Website hosting: using IaaS and VMs can make running websites less expensive than traditional hosting.
• High-performance computing (HPC): HPC can solve complex problems that involve millions of calucations or variables. VMs enable this on clusters, computer grids, or supercomputers, providing the ability to support various scenarios.
• Storage, backup, and recovery: VMs avoid expenses associated with storage and storage management. IaaS provides a simplified approach to handling unpredictable demand, as well as backup and recovery systems.
• Extended datacenters: VMs in Azure can help add capacity to an organizations datacenter, without requiring addition cost for physical hardware and additional maintenance.
• Big data analysis: data mining allows you to discover hidden patterns that require a large amount of processing power, provided by IaaS in a more economical approach.

Planning VM Configuration

Following a checklist will help you plan to configure a VM:

• Network configuration: VNets are used to provide private connectivity between your VMs and other services in Azure.

  • Resources on the same VNet can access one another; by default, any resources outside the VNet aren't able to connect to those within the VNet.
  • Additional configuration is required to the network before external services can be accessed, including any on-prem servers.
    • Note: If your organizations private network is going to be connected to the services in Azure, make sure to consider the topology before creating VMs.

• Name for the VM: the name of the VM will be configured as part of the OS.

  • Windows VMs allow names up to 15 characters long
  • Linux VMs allow names up to 64 characters long
    • Note: make sure to pick a naming convention that's meaningful and standardized.
      • Ex: produsc-webvm01 would be used for the first production web server in the US South Central location.

• Location for the VM: the region in which you create your VM will be where the resources are allocated.

  • Choosing a regional location allows your VM to be close to your users.
    • Note: the location of the VM can improve performance and is an important decision to ensure you meet legal, tax, and/or compliance requirements.
  • Location can limit your options for hardware and configurations.
  • Location can also determine the pricing - some regions will be more expensive than others.

• Size of the VM: depending on the type of workload the VM will be running will determine the memory and storage sizes your machine will require.

  • Azure allows you to resize VMs when the size no longer meets your needs if the hardware configuration is allowed in the new size.
  • This provides an agile and elastic approach to VM management.
    • Note: you can select any size available in your region when you stop & deallocate the VM. However, you should use caution resizing production machines as resizing might require a reboot or change the IP address, causing a temp outage.

• Review the pricing model to estimate costs: subscriptions are billed two charges for each VM; compute and storage. These costs being separate allow you to scale them and pay for only what you need.

  • Compute: paid on a per-hour basis and billed on a per-minute basis.
    • Consumption-based means you pay for the compute capacity per second. This option allows you to increase or decrease the capcity on demand, allowing you to start or stop as needed.
      • This option is best if your organization runs apps with unpredictable or short-term workloads that cannot be interrupted, such as quick tests or developing apps in VMs.
    • Reserved VM Instances (RI) provides an option to purchase a VM for one or three years, in a specific region. While this option requires a commitment made up front, you save up to 72% compared to the pay-as-you-go pricing model. - This option is best if the VM needs to run continuously OR if you need a predictable budget, if you can commit to using the VM for a minimum of one year. - RIs can be exchanged or returned with an early term fee.
  • Storage: charged separately for the Azure Storage used by the VM.
    • Status of the machine doesn't determine the charges incurred.

• Select an OS to use: pick between different versions of Windows or Linux.

  • The cost of the OS license is included in the price.
  • Use the Azure Marketplace to search for more than just base OS images. This allows you to install images that have the OS and additional software.
    • Ex: A Linux server, Apache web server, MySQL database, and PHP are included in an image stack.
  • You can also create your own disk image if you cannot find one that suits your needs.
    • Note: Azure only supports 64-bit OS.

• Identify the Azure Storage to use: Azure Managed Disks handle the storage account creation & management for you.

  • Disk size & performance (standard or premium) can be selected.
  • Adding disks or scaling up/down is possible.

• Determine VM storage: all Azure VMs have at least two disks: an OS and a temporary disk. However, they can have one or more data disks.

  • All disks are stored as Virtual Hard Disks (VHDs), which are like physical disks in on-prem servers, just virtualized.
    • OS disk: every VM will have one OS disk attached.
      • These disks contain the pre-installed OS and are registered as a Serial Advanced Technology Attachedment (SATA) drive.
      • OS disks will be labled as the C: drive by default.
    • Temp disk: data on these disks could be lost during maintenance or upon deployment, however, it should persist upon a normal reboot of the VM.
      • Windows: by default, this drive will be labeled the D: drive and is used to store the pagefil.sys file.
      • Linux: this drive is usually /dev/sdb and is formatted & mounted to /mnt by the Azure Linux Agent.
        • Important: data on the temp drive should not be critical to the system as it could be lost upon moving to a new host.
    • Data disks: these are managed disks and used to store app data, or any other data that's needed to be kept.
      • Registered as SCSI drives and are able to be labeled a letter of your choice.
        • Note: the size of the VM determines how many data disks can be attached and the kind of storage that can be used to host these disks.

Storage considerations

• Azure Premium Storage: gain high-performance, low-latency disk support for VMs with input/output (I/O)-intensive workloads.

  • Premium Storage stored data on SSDs.
  • Existing VM disks can be migrated to Premium Storage.

• Multiple Storage disks: using multiple disks allows your apps up to 256 TB of storage space per VM.

  • Premium Storage allows your apps to achieve 80,000 I/O operations per second (IOPS) per VM & a disk throughput up to 2,000 MB/s per VM.
  • Read operations yield low latencies with Premium Storage.

• Managed disks: Azure Managed Disks are VHDs and are stored as page blobs which are a random IO storage object.

  • These disks are considered managed because they are an abstraction over page blobs, blob containers, and Azure storage accounts.
  • You provision these disks while Azure handles creating and managing them.
  • These types of disks are available in Ultra SSD, Premium SSD, Standard SSD, and Standard HDD.
    • Note: These disks are required for the single instance VM SLA.

• Migrating to Premium Storage: Microsoft recommends migrating VM disks that require high IOPS to Premium Storage for the best performance.

  • If the disk doesn't require high IOPS, reduce your cost by keeping it in standard storage.

Creating VMs in Azure portal

The first thing to decide is which image to use while creating a VM in the Azure portal. The portal will guide you through the config process while creating the machine image.

• Basics tab: contains the admin account, project details, and inbound port rules.
• Disks tab: select the OS disk type & data disks.
• Networking tab: create VNets and load balancing.
• Management tab: enable auto-shutdown and configure backup details.
• Advanced tab: configure scripts, agents, or VM extensions.
• Monitoring & Tabs tabs: additional settings are available.

Connecting to VMs

You can connect to your VMs in Azure in multiple ways:

• Azure Bastion
• SSH
• RDP
• Cloud Shell

Windows-based VMs

Connecting to a Windows VM hosted in Azure will be done using the Remote Desktop app (uses RDP).

• Any version of Windows that's supported will have a GUI session.
  • The VMs IP address and port number will be needed to connect with this method. Azure will then allow you to download a RDP file to use to connect.

Linux-based VMs

Connecting to a Linux VM hosted in Azure can be done using an SSH client.

• You can reuse a single public-private key pair to access VMs and services, depending on the org's security policies.
  • WSL, Terminal, or Shell can be used as SSH clients to connect.
  • The path to your private key file will be required. This key remains on your system and needs to be protected.
  • The public key will be placed on the Linux VM, or another service using public-key cryptography.

Azure Bastion

Note: this is a platform managed PaaS service.

Bastion provides secure, seamless RDP/SSH connectivity to all VMs in the VNet, directly over SSL.

• No IP address is required when connecting using the service.
• Azure Bastion protects VMs from exposing RDP/SSH ports externally.
  • Note: this service allows you to connect directly from Azure portal; no additional software is required.

Planning for Maintenance

Availability plans for VMs need to include methods for unplanned and unexpected situations, and planned situations.

Unplanned hardware maintenance: these events happen when Azure predicts the a component associated to the physical machine is going to fail. When the platform predicts a failure, an unplanned hardware maintenance event will be issued. - Note: Azure uses Live Migration technology to migrate VMs from failing hardware to a fully functioning machine. - Live Migration will only pause the VM for a short period of time and performance might be impacted before or after.

Unexpected downtime: these events happen when the infrastructure or hardware for your VM fails. This could include:

• Local network failures
• Rack level failures
• Local disk failures
  • Note: Azure will automatically migrate the VM to a healthy physical machine within the same datacenter when this occurs.

Regularly scheduled maintenance: these events are regular updates Microsoft makes to the Azure platform to help improve reliability, security, and performance of the infrastructure VMs run on.

• It's important to remember that most of these will not impact any VM or service running in Azure.
  • Note: Microsoft does not automatically update VM OS or other software. You are fully responsible for these updates. Only the underlying software is updated periodically, as well as the hardware.

Availability sets

There are several things to remember about availability sets, including but not limited to:

• A VM and an availability set can be created at the same time
  • Note: VMs can only be added to an availability set when the VM is created. Changing the availability set requires deleting the VM and then recreating it.
• Availability sets can be built using the following options:
  • Azure portal
  • ARM templates
  • Scripting
  • API tools
• All VMs within an availability set should perform the same set of functions
• All VMs within an availability set should have the same software installed
• VMs in an availability set will run across multiple servers, racks, storage units, and switches.
  • Note: if hardware or Azure software fails, only a subset of the VMs in the set are impacted and the app will continue to be available.
• SLAs are provided by Microsoft for VMs and availability sets.

Important: Availability sets won't protect the apps from OS or app failures.

When using availability sets, consider the following:

• Redundancy
• Load balancing: for high availability & network performance
• Separation of application tiers: to help mitigate single points of failure
• Managed disks: for block-level storage

An availability set is a logical grouping of virtual machines hosting your application. These consist of update domains (UDs) and fault domains (FDs). Each VM you create will have a UD and FD that's associated with it.

• Note: you can have up to 3 FDs and 20 UDs.
  • The default number of UDs is 5. If you create more than 5 VMs, the 6th VM will be placed on the 1st UD, the 7th on the 2nd UD, and so on.

Deploying multiple instances of your app will help you achieve High Availability (HA), which removes the risk of a single point of failure.

FDs represent a set of VMs that have the same network switch, A/C, and power.

• Note: you can only configure up to 3 FDs, which is the default value when setting up availability sets.

UDs represent a group of VMs and the host, which can be updated & rebooted at the same time.

• Note: only one UD will be rebooted at a time during scheduled maintenance, such as patching, firmware updates, etc.
  • While one is being rebooted, 30mins is required before the next scheduled task will begin on another domain.

Creating availability sets can be done using:

• Azure portal
• Azure PowerShell
• Azure CLI

Information required to create availability sets:

• Subscription
• Resource group
• Name
• Region
• Number of FDs
• Number of UDs
• Disk alignment (use of managed disks)

Fault domains and Update domains

VM Availability sets implement two node concepts to achieve high availability and fault tolerance:

Update domains: these are a group of nodes that get upgraded together during service upgrades and allow Azure to incrementally upgrade across a deployment.

• Can be updated and rebooted at the same time
• Only one update domain is rebooted at a time during planned maintenance
• There are 5 UDs by default
• Up to 20 UDs can be configured

Fault domains: these are a group of nodes representing physical units of failure.

• Two FDs work together to prevent hardware failure, network outages, power interruptions, and/or software updates.
• FDs are a group of VMs sharing the same hardware, or network switch, and sharing the same single point of failure.

Availability zones

Each Azure region has unique physical locations. These locations are called zones and make up one or more datacenters that has its own power, networking, and cooling. Deploying apps to multiple zones can provide protection from datacenter failure as we can create instances in different zones within a region.

• If a zone suffers an outage, instances will be deployed in different zones to maintain availability.

When creating a VM, you can select which zone to deploy to.

Note: Availability zones can help improve SLAs of your applications.

• Availability zones are unique, physical locations within a region in Azure.
• Physical separation within regions protects against datacenter failures.
• Each zone has one, or more, datacenters equipped with power, cooling, and networking independently.
• Zone-redundant services will replicate apps and data across the availability zones, protecting against single points of failure.
• A minimum of 3 separate zones exist within enabled regions.

There are two categories of services that support availability zones:

Zonal services: these pin each resource to a zone

• Azure VMs
• Managed disks
• Standard IP addresses

Zone-redundant services: these replicate automatically across all zones

• Azure SQL DB
• Zone-redundant Azure Storage

Important: Availability zones help businesses achieve business continuity while using Azure services. However, you should build the architecture of your apps using a combo of availability zones and region pairs.

Vertical and horizontal scaling

Scalability allows throughput for a VM proportionally to the availability of the associated hardware resources. When a VM is scalable, it can handle increased requests without negatively affecting throughput or response time.

Vertical scaling (aka scale up/scale down): increases or decreases the VM size in response to a workload. This makes the VM more or less powerful.

Vertical scaling can be beneficial when:

• Services running on a VM are not heavily used on the weekends: scaling down can help decrease monthly costs
• An increase in use occurs: scaling up can help you support the demand without requiring the creation of additional VMs

Horizontal scaling (aka scale in/out): adjusts the number of VMs to support a changing workload.

Consider the following when using either scaling option:

• Limitations: horizontal scaling has fewer limitations compared to vertical scaling as vertical scaling depends on the availability of larger hardware.
  • Note: larger hardware hits upper limits quickly and availability varies by region.
  • Vertical scaling typically requires stopping the VM and restarting it, which presents limitations to accessing data or apps.
• Flexibility: horiztonal scaling is more flexible in the cloud.
• Reprovisioning: the process of removing an existing VM and replacing it with a new machine.

Azure Virtual Machine Scale Sets (VMSS)

Virtual Machine Scale Sets are an Azure Compute resource that can be used to deploy & manage a set of identical VMs.

• All VMs are configured in the same way allowing you to have true autoscaling
• There is no need to pre-provision VMs
• VMSS provides an easier way of building large-scale services that target large compute, containerized workloads and big data
• VMSS automatically increases/decreases the number of VM instances as demand increases/decreases
  • Note: adding and removing machines can be automated or manual, or a mixed combination.

It's important to remember:

• VMSS supports up to 1,000 VM instances.
  • If you crease and upload custom VM images, you are limited to 600 VM instances.
• VMSS supports the use of Azure Load Balancer (basic layer 4 traffic distribution).
• VMSS supports the use of Azure Application Gateway (advanced layer 7 traffic distribution & SSL termination).
• All VM instances are created from the same base OS image & configuration.
• VMSS can be used to run multiple instances of apps.
  • If one VM has a problem, users will keep their access through other VMs with minimal interruption.
• VMSS autoscales based on the demand for your app(s).

Create VMSS

Creating VMSS can be done from the Azure portal. The following information is needed:

• The number of VMS
• Allocation policies
• Orchestration mode: how VMs are managed by the scale set
  • Uniform: optimized for large scale stateless workloads with identical instances - define the VM model and Azure generates identical instances based on the model.
  • Flexible: achieve high availability at scale with identical or multiple VMs - manually create & add VMs of any configuration to the scale set.
• Image/base OS or app for the VM
• VM architecture:
  • Arm64
  • x64
• Run with Azure Spot discount: offers the unused Azure capacity at a discount vs pay as you go
  • Note: workloads should be tolerant to infrastructure loss as this may recall capacity
• Size: select the size to support the workload you want to run.
  • Note: this size will determine processing power, storage capacity, and memory.
  • Azure charges an hourly price based on the size and OS.

Advanced options can also be selected:

• Enable scaling beyond 100 instances:
  • Selecting No means the VMSS implementation will be limited to one placement group with a max capacity of 100.
  • Selecting Yes means the implementation can span multiple placement groups with a max capacity of 1,000. However, this will change the availability characteristics.
• Spreading algorithm: Microsoft recommends allocating Max spreading to provide the optimal spreading.

Autoscaling

Consider the following:

• Automatic adjusted capacity: rules can be created to define the acceptable performance for positive user experience - when the thresholds are met, the rules will adjust the capacity of the VMSS implementation.
• Scale in: reduce the cost to run the VMSS implementation - limits the number of instances that will run to provide support to the current demand.
• Scale out: automatically increase the implementation if the load on your VMs increases.
• Scheduled events: events can be scheduled to automatically increase/decrease the capacity of the implementation at specific times.
• Overhead: VMSS with autoscaling reduces management overhead to monitor and optimize the performance of your app.

Autoscaling can be enabled during the creation of VMSS.

• Note: make sure to define a min., max., and default number of VM instances to use during the process for best performance.

Several settings can be configured to enable autoscaling:

• Min/Max number of VMs
• Scale out
  • CPU threshold %: specifies the threshold to trigger the scale out rule
  • Duration in mins: defines the amount of time the Autoscale engine will look for metrics. The delay allows metrics to stabilize and avoids reacting to transient spikes.
  • Number of instances to increase by: defines the number of VMs to add to the VMSS when the scale out rule is triggered
• Scale in
  • CPU threshold %: specifies the threshold to trigger the scale in rule
  • Number of instances to decrease by: defines the number of VMs to remove from the VMSS when the scale in rule is triggered
• Scale-in policy: this feature provides a way to configure the order VMs are scaled in.

Provision and manage containers in the Azure portal

• Create and manage an Azure container registry
• Provision a container by using Azure Container Instances
• Provision a container by using Azure Container Apps
• Manage sizing and scaling for containers, including Azure Container Instances and Azure Container AppsConfigure sizing and scaling for Azure Container Instances

Create and configure an Azure App Service

• Provision an App Service plan
• Configure scaling for an App Service plan
• Create an App Service
• Configure certificates and TLS for an App Service
• Map an existing custom DNS name to an App Service
• Configure backup for an App Service
• Configure networking settings for an App Service
• Configure deployment slots for an App Service

Azure App Service plans

Azure App Service plans define a set of compute resources for web apps to run.

• One or more application can be configured to run on the same computing resources (in the same App Service plan).
• When creating an App Service plan in a region, a set of the compute resources is created for the plan in that region. Any apps placed into the plan will run on the compute resources the plan uses.
• New apps can be added to existing plans, if the plan has the resources to handle the increased load.

App Service plans define the following settings:

• Region
• Number of VM instances
• Size of VM instances

App Service Pricing Tiers:

• Free or Shared Tier
  • Apps run by reciving CPI minutes on a shared VM instance
  • Apps cannot scale out
• Basic, Standard, Premium, or Isolated Tier
  • Apps run on all VM instances in the App Service plan
  • Multiple apps in the same plan will share the same VM instances
  • If there are multiple deployment slots for an app, they will all run on the same VM instances
  • Enabling diagnostic logs, running WebJobsm and performing backups use CPU cycles & memory on the same VM instances

Note: If autoscaling is configured, all apps in the plan are scaled out together based on the settings configured.

App Service Pricing

There are a total of 6 categories of pricing tiers.

Free & Shared: these plans are the base tiers that run on the same VMs as other apps.

• Some apps might belong to other customers.
• Intended for dev & testing.
• No SLA.
• Metered on a per app basis.

Basic: these plans are designed for apps with lower traffic requirements and don't require advanced autoscaling or traffic management.

• Pricing is based on size & number of instances.
• Built-in network load balancing support distributes traffic across instances automatically.
• Supports Web App for Containers with Linux runtime environments.

Standard: these plans are designed to run production workloads.

• Pricing is based on size & number of instances.
• Built-in load balancing support distributes traffic automatically across instances.
• Autoscale is included.
• Supports Web App for Containers with Linux runtime environments.

Premium: these plans are designed for enhanced performance for production apps.

• Premium v2 offers Dv2-series VMs with faster processors, SSD, and double memory-to-core ratio vs the Standard tier.
• The new plan supports higher scale via increased instance count while providing the advanced capabilities of the Standard tier.
• The first gen of Premium is available to support existing customer scaling needs.

Isolated: these plans are designed for mission critical workloads that are required to run in a VNet.

• Allows apps to run in a private, dedicated environment in an Azure datacenter.
  • Note: this private environment is referred to as the App Service Environment.
• Offers Dv2-series VMs with faster processors, double memory-to-core ratio, and SSD compared to the Standard tier.
• Can scale to 100 instances, but more are available upon request.

App Service Scaling

Scaling up increases the amount of CPU, memory, and disk space available.

• Provides additional features: dedicated VMs, custom domains & certificates, autoscaling, staging slots, plus more.
• Scale up by changing the pricing tier of the App Service plan where the app is.

Scale out increases the number of VM instances that run the app.

• Scale out up to 30 instances, depending on the pricing tier.
  • The Isolated tier allows you to scale out up to 100 instances.
• Scale instance count can be configured manually or automatically.

Autoscale allows you to automatically increase the scale instance count for scaling out.

• Based on predefined rules & schedules.

Scale up or down anytime by changing the pricing tier.

Azure App Services

Azure App Services seamlessly brings together the components needed to create mobile backends, websites, and web APIs for any device or platform. These apps easily run and scale within both Linux and Windows environments.

Benefits of Azure App Services:

• DevOps integration: continuous integration and deployment using Azure DevOps, GitHub, Docker Hub, and BitBucket.
  • Apps can be managed in App Service using Azure PowerShell or the CLI.
• Support for various languages and frameworks: provides support for PHP, Ruby, Python, ASP.NET, Java, and Node.js.
  • PowerShell and other scripts/executables can be ran as background services.
• Serverless code: code snippets can be ran on demand
• High Availability: the Basic tier and above allow you to use built-in load balancers.
  • Note: autoscaling is available from the Standard tier and above
• Compliance & Security: Azure App Service is ISO, PCI, and SOC compliant and allows for easy other IdPs to be integrated for authentication.
  • Ex: Google, Facebook, Twitter, Microsoft.
• VS integration: dedicated tools in Visual Studio are offered to help publish apps.
• Marketplace app templates: lists of app templates are available within the Azure Marketplace.
  • Ex: Joomla, Drupal, and WordPress.
• API and mobile features: features like CORS support for RESTful API, offline data syncing, and push notifications are offered using Azure App Services.

Creating Apps with App Service

Configuration settings to create an app with App Service:

• Name: the name must be unique as it identifies the app and its location in Azure.
  • Custom domains can be mapped if preferred.
• Publish: App Service hosts the app as a Docker container or as code.
• Runtime stack: multiple choices are available, along with various versions of PHP, Python, Ruby, Node.js, .NET Framework, and .NET Core.
  • Linux apps and custom container apps can have an optional start-up file/command configured.
• OS: Linux or Windows
• Region: the region will affect the App Service plans that are available for your app.
• App Service plan: the app needs to be associated with an Azure App Service plan for available resources, capacity, and features.
  • Pricing tiers will depend on what's available in the region selected.

Once the app is created, additional configuration settings will become available.

• App deployment
• Path mappings
• Always On: your app can stay loaded regardless of the volume of traffic.
  • Required for continuous WebJobs, or WebJobs that are triggered by using a CRON expression.
• ARR affinity: you can ensure the app client is routed to the same instance for the life of the session while in a multi-instance deployment.
• Connection strings: these strings are encrypted at rest & are transmitted over an encrypted channel.

Security with Azure App Service

App Service offers built-in authn & authz support.

• Sign in users and access data by writing minimal or no code in your apps, whether web app, mobile backend, Azure Functions, or API.
  • Note: you don't have to use App Service for authentication and authorization.

Important to know:

• The authn and authz security module runs in the same env as your app code, but separately.
• The security module is configured using app settings - no changes to your app code, no SDKs, or specific languages are needed
• Incoming HTTP requests pass through the module after the security module is enabled, before being handled by the app code.
• The module handles the following tasks for your app:
  • Authentication of users with a specified provider
  • Validates, stores, & refreshs tokens
  • Manages the authenticated session
  • Injects identity info into request headers

You can choose to do the following:

• Allow anonymous requests: provides flexibility to handle anonymous requests and allows you to have multiple IdPs available to users.
• Logging and tracing: authentication and authorization traces can be viewed directly from the log files.
• Allow only authenticated requests: all anonymous requests will be redirected to the provider of your choice. No authentication code will need to be written

Custom domain names

Azure will assign newly created web apps to the subdomain azurewebsites.net and will assign a virtual IP address for the app.

• For production apps, you can show your users a custom domain name.

Note: to map a custom domain, you need to have a paid tier for your Azure App Service plan.

Steps to create a custom domain:

1. Reserve your domain name: you can purchase one in the Azure portal, which is the easiest way to set it up.
2. Create DNS records to map the domain to the web app: A and CNAME records.
   • A record will map the domain to an IP address.
   • CNAME record will map the domain to another domain.
3. Enable the custom domain: use the Azure portal to validate the domain and add to your web app.
   • Note: always test the domain before publishing