Skip to content

Compute

Computing Solutions

Azure supports a wide range of computing solutions for development and testing, running applications and extending your datacenter.

  • Azure Virtual Machines : Reserve a configuration of CPU, memory, disk and GPUs and decide what OS to run.
  • Azure Batch : Apply this managed service to run large-scale parallel and HPC applications.
  • Containers Instances & AKS : Azure compute resources that you can use to deploy and manage containers.
  • Azure App Service : A PaaS to quickly build, deploy and scale enterprise-grade web, mobile and API apps running on any platform.
  • Azure Functions : Event-driven serverless functions. Your function is called when events happen : HTTP, Queues, Timers...
  • Azure Logic Apps : Configure this cloud-based platform to create and run automated workflows similar to capabilities in Azure Functions.

Azure Virtual Machines

Azure Virtual Machines is the basis of the Azure Infrastructure-as-a-Service (IaaS) model. Virtual Machines can be used for developing, testing and deploying applications in the cloud or to extend your datacenter.

You can group VMs together to provide high availability, scalability and redundancy.
No matter what your uptime requirements are, Azure has several features that can meet them.

These features include:

Azure Bastion

Azure bastion, a fully platform-managed PaaS service, provides secure and seamless RDP/SSH connectivity to your VMS directly over SSL.
When you connect via Azure Bastion, your virtual machines don't need a public IP address.

Azure Virtual Machine Extensions

Azure virtual machine extensions are small applications that provide post-deployment configuration and automation tasks for Azure VMs.
VM extensions can be bundled with a new virtual machine deployment or run against any existing system.

There are different virtual machine extensions for Windows and Linux machines.
You can choose from a large set of first and third-party virtual machine extensions.

  • Custom Script Extensions can be used to automatically launch and execute virtual machine customization tasks after initial machine configuration.
    • Custom Script Extensions only have 90 minutes to execute. If your deployment takes longer than 90 minutes, the task is marked as a timeout.

Scalability - Availability

VM Scale Sets are an Azure compute resource that you can use to deploy and manage a set of identical VMs.
With all VMs configured the same, VM Scale Sets are designed to support true autoscale.

  • All VM instances are created from the same base operating system image and configuration.
  • VM Scale Sets support the use of Load Balancer for layer-4 traffic distribution and Application Gatway for layer-7 traffic distribution and SSL termination.
  • VM Scale Sets support 1,000 VM instances. If you create and upload your own custom virtual machine images, the limit is 600 virtual machine instances.

Things to consider when using autoscaling

  • Automatic adjusted capacity : Create autoscaling rules to define the acceptable performance for a positive customer experience.
  • Scale out : If the increased load is consistent rather than a brief demand, you can increase the number of VM instances.
  • Scheduled events : Implement autoscaling and schedule events to increase or decrease the capacity at fixed times.
  • Scale in : On an evening or weekend, the application demand might decrease. If the decreased load is consistent over a period of time, you can configure autoscale rules to decrease the capacity.

An Availability Set is a logical feature you can use to ensure a group of related virtual machines are deployed together.
The grouping helps to prevent a single point of failure from affecting all of your machines.

  • Azure ensures that VMs in an availability set run across multiple physical servers, compute racks, storage unit and network switches.
    • If a hardware or Azure software failure occurs, only a subset of the virtual machines in the availability set are affected.
  • Virtual machine and an availability can be set at the same time.
    • A VM can only be added to an availability set when the vm is created.
    • To change the availability set for a virtual machine, you need to delete and then recreate the virtual machine.
  • All VMs in an availability set should perform the identical set of functionalities.
  • All VMs in an availability set should have the same software installed.

Things to consider when using availability sets

  • Load balancing : For HA and network performance, create a load-balanced availability set by using Azure Load Balancer.
  • Separation of application tiers : Each application tier should be located in a separate availability set.
  • Redundancy : To achieve redundancy, place multiple virtual machines in an availability set.

Update/Fault Domains

Azure Virtual Machine Availability Sets implements two node concepts to help Azure maintain high availability and fault tolerance when deploying and upgrading applications: update domains and fault domains.

An update domain is a group of nodes that are upgraded together during the process of a service upgrade.
It allows Azure to perform incremental or rolling upgrades across a deployment.

A fault domain is a group of nodes that represent a physical unit of failure. Think of a fault domain as nodes that belong to the same physical rack.

Each virtual machine in an availability set is placed in one update domain and one fault domain.

  • Availability Sets : are designed for applications that require a fixed number of VMs to be distributed across multiple fault and update domains.
    They ensure that the VMs are distributed in a way that maximizes their availability in the face of hardware failures or planned maintenance.

  • Scale Sets : are designed for applications that can automatically scale based on demand. They also distribute VMs across fault and update domains, but the primary focus is on the ability to dynamically add or remove VMs based on load or other factors.

Scale sets provide high availability through redundancy and auto-scaling, while availability sets provide high availability through redundancy and fault/update domain distribution.

Availability zones are a high-availability offering that protects your applications and data from datacenter failures.
An availability zone in an Azure region is a combination of a fault domain and an update domain.

Things to know about availability zones

  • Availability zones are unique physical locations within an Azure region.
  • Each zone is made up of one or more datacenters that are equipped with independent power, cooling, and networking.

  • To ensure resiliency, there's a minimum of three separate zones in all enabled regions.

  • The physical separation of availability zones within a region protects applications and data from datacenter failures.

  • Zone-redundant services replicate your applications and data across availability zones to protect against single-points-of-failure.

Azure Batch

Azure Batch enables large-scale parallel and HPC batch jobs with the ability to scale to tens, hundreds or thousands of VMs.
When you're ready to run a job, Batch does the following :

  • Starts a pool of compute VMs for you.
  • Installs applications and staging data.
  • Runs jobs with as many tasks as you have.
  • Identifies failures.
  • Requeues work.
  • Scales down the pool as work completes.

Containers

Azure Container Instances

Container Instances offers the fastest and simplest way to run a container in Azure without having to manage any virtual machines or adopt any additional services.

Azure Container Instances(ACI) enables fast startup. You can launch containers in seconds for immediate access to applications.

  • ACI implements per second billing. You incur costs only while your container is running.
  • Custom sizes : You can specify exact values for CPU cores and memory and avoid costs for unused resources.
  • Persistent storage : Azure Files shares can be mounted directly to a container to retrieve and persist state.
  • Cross platforms : ACI can schedule both Windows and Linux containers... It schedules both Windows and Linux containers using the same API.
  • Coscheduled groups : ACI supports scheduling of multi-container groups that share host machine resources.
  • VNet deployment : Container Instances can be deployed into an Azure virtual network.
  • Public IP connectivity and DNS names. Containers can be directly exposed to the internet with an IP address and FQDN.

Container Group

The top-level resource in Azure Container Instances is the container group.
A container group is a collection of containers that get scheduled on the same host machine.
The containers in a container group share a lifecycle, resources, local network and storage volumes.

Things to know about container groups

  • A container group is similar to a pod in Kubernetes. The containers in a multi-container pod can share related resources.
  • ACI allocates resources to a multi-container group by adding together the resource requests of all containers in the group.
  • There are two common ways to deploy a multi-container group : ARM template and YAML file.
  • Container groups can share an external-facing IP address, one or more ports on the IP address and a DNS/FQDN.
    • Deleted groups : When a container group is deleted, its IP address and FQDN are released.
    • Port mapping : Isn't supported because containers in a group share a port namespace.
    • External client access : You must expose the port on the IP address and from the container.

Azure Kubernetes Service

Azure Kubernetes Service manages your hosted Kubernetes environment and makes it simple to deploy and manage containerized applications in Azure.
AKS environment is enabled with many features, such as automated updates, self-healing, Azure AD integration, integrated VNet connectivity and easy scaling.

AKS cluster is divided into two components : Azure-managed nodes and customer-managed nodes.

  • Azure-managed nodes provide the core Kubernetes services and orchestration of application workloads in your AKS cluster.
  • Customer-managed nodes run your application workloads in your AKS cluster and you only pay for these nodes.

Rapid Burst Scaling

If your application needs to scale rapidly, the HPA might schedule more pods than can be provided by the existing compute resources in the node pool.
As a result, the cluster autoscaler is triggered to deploy more nodes in the node pool. But it can take a few minutes for the nodes to successfully provision.

To resolve this situation, you can rapidly scale your Azure Kubernetes Service cluster by integrating with Azure Container Instances.

Things to know about rapid burst scaling

  • ACI lets you quickly deploy your container instance without extra infrastructure overhead.
    • The container instance becomes a secured, logical extension of your AKS cluster.
  • The Virtual Kubelet component is installed in your AKS cluster. The component presents your container instance as a virtual Kubernetes node.
  • Virtual nodes are deployed to another subnet in the same VNet as your AKS cluster.
  • K8S schedules pods to run as container instances through virtual nodes, rather than pods on VM nodes directly.
  • Your application requires no modification to use virtual nodes.
  • Deployments can scale across AKS and Container Instances. There's no delay when the cluster autoscaler deploys new nodes.

Azure Service Fabric

Azure Service Fabric is a distributed systems platform that makes it easy to package, deploy and manage scalable and reliable microservices and containers.

A key differentiator of Service Fabric is its strong focus on building stateful services.

It works for Any OS, any cloud : You can create clusters for Service Fabric in many environments, including Azure, other public clouds or on premises, on Windows Server or Linux.
Unlike ACI, Service Fabric provides a prescriptive guidance on how application should be written.

App Services

Azure App Service is an HTTP-based service that lets you build and host web apps, background jobs, mobile backends and RESTful APIs.

App Service supports Windows and Linux and enables automated deployments from OneDrive, Dropbox, GitHub, Azure DevOps or any Git repo to support a continuous deployment model. It offers automatic scaling and high availability.

With App Service, you can host most common app service styles like : Web apps, API apps, WebJobs, Mobile apps.
Use the Mobile Apps feature of App Service to quickly build a backend for iOS and Android apps. With just a few clicks in the Azure portal, you can:

  • Store mobile app data in a cloud-based SQL database.
  • Authenticate customers against common social providers, such as MSA, Google, Twitter and Facebook.
  • Send push notifications.
  • Execute custom back-end logic in C# or Node.js.

App Service Plans

In Azure App Service, an application runs in an Azure App Service plan. An App Service plan defines a set of compute resources for a web application to run.

Each App Service plan defines three settings :

  • Region : The region or the App Service plan such as West US, North Europe and so on.
  • Number of VM instances : The number of VM instances to allocate for the plan.
  • Size of VM instances : The size of the VM instances in the plan.

You can continue to add new applications to an existing plan as long as the plan has enough resources to handle the increasing load.

Things to know about App Service plan pricing tiers

Feature Basic Standard Premium Isolated
Web/App Unlimited Unlimited Unlimited Unlimited
Disk space 10 GB 50 GB 250 GB 1 TB
Auto scale n/a Supported Supported Supported
Deployment slots n/a 5 20 20
Max instances Up to 3 Up to 10 Up to 30 Up to 100

With Basic, Standard, Premium or Isolated tier :

  • Applications run on all VM instances configured in the App Service plan.
  • Multiple applications in the same plan share the same VM instances.
  • If you have multiple deployment slots for an application, all deployment slots run on the same VM instances.
  • If you enable diagnostic logs, perform backups or run WebJobs, these tasks use CPU cycles and memory on the same VM instances.

Create an app with App Service

Some of the basic configuration settings you need to create an app with App Service :

  • Name : The name for your app must be unique because it's used to identify and locate your app in Azure.

    • An example name is $myApp.azurewebsites.net. You can map a custom domain name, if you prefer to use that option instead.

  • Publish : App Service hosts (publishes) your app as code or as a Docker Container.

  • Runtime Stack : App Service uses a software stack to run your app, including the language and SDK versions.

    • Your choices for the stack include .NET Core, .NET Framework, Node.js, PHP, Python, and Ruby.

  • Operating System : The OS for your app runtime stack can be Linux or Windows.

  • Region : The location.
  • App Service Plan : Your app needs to be associated with an Azure App Service plan.

Continuous Deployment

When you create your web app with App Service, you can choose automated or manual deployment.

  • Automated deployment (continuous integration) : Azure supports automated deployment directly from several sources :

    • Azure DevOps : Push your code to Azure DevOps, build it, run the tests, generate a release from the code and finally, push it to an Azure web app.
    • GitHub : Azure supports automated deployment directly from GitHub. When you connect your GitHub repository, any changes you push to your production branch are automatically deployed.
    • Bitbucket : With its similarities to GitHub, you can configure an automated deployment with Bitbucket.

  • Manual deployment enables you to manually push your code to Azure. There are several options for manually pushing your code :

    • Git : The App Service Web Apps feature offers a Git URL that you can add as a remote repository. Pushing to the remote repository deploys your app.
      • Git deployment cannot occur when the web app is stopped. Unable to access '[siteURL]': Failed to connect to [scmAddress]
    • CLI : The webapp up command is a feature of the CLI that packages your app and deploys it.
    • Compressed package files : Can only use ZIP files to directly deploy from a package. TAR and GZIP formats are not supported.
    • FTP/S : FTP/S is a traditional way of pushing your code to many hosting environments, including App Service. It supports both Active and Passive modes.

Deployment Slots

When you deploy an app to Azure App Service, you can use a separate deployment slot instead of the default production slot.

  • Deployment slots are live apps that have their own hostnames.
  • App content and configuration elements can be swapped between two deployment slots, including the production slot.

There are several advantages to using deployment slots with your App Service app.

  • Validation : Validate changes to your app in a staging deployment slot before swapping the app changes with the content in the production slot.
  • Reductions in downtime : Deploying an app to a slot first and swapping it into production ensures that all instances of the slot are warmed up before being swapped into production.
    • This option eliminates downtime when you deploy your app. The traffic redirection is seamless and no requests are dropped because of swap operations.
    • The entire workflow can be automated by configuring Auto swap when pre-swap validation isn't needed.
  • Auto swap : Streamlines Azure DevOps scenarios where you want to deploy your app continuously with zero cold starts and zero downtime for app customers.
    • Auto swap isn't currently supported for Web Apps on Linux.

Backup & Restore

The Backup and Restore feature in Azure App Service lets you easily create backups manually or on a schedule.
You can configure the backups to be retained for a specific or indefinite amount of time.

You can restore your app or site to a snapshot of a previous state by overwriting the existing content or restoring to another app or site.

  • To use the Backup and Restore feature, you need the Standard or Premium tier App Service plan.
  • You can configure backups manually or on a schedule.

  • Full backups are the default. Partial backups are supported. You can specify files and folders to exclude from a backup.

  • You restore partial backups of your app or site the same way you restore a regular backup.

  • Backups can hold up to 10 GB of app and database content.

  • In your storage account, each backup consists of a Zip file and XML file :

    • The Zip file contains the back-up data for your app or site.
    • The XML file contains a manifest of the Zip file contents.

Security with App Service

The authentication and authorization security module in Azure App Service runs in the same environment as your application code, yet separately.
The security module is configured by using app settings. No SDKs, specific languages, or changes to your application code are required.

  • When you enable the security module, every incoming HTTP request passes through the module before it's handled by your application code.
  • The security module handles several tasks for your app :
  • Authenticate users with the specified provider
  • Validate, store, and refresh tokens
  • Manage the authenticated session
  • Inject identity information into request headers

Functions & Logic Apps

Azure has two implementations of serverless compute : Azure Functions and Azure Logic Apps

Azure Functions

Azure Functions : Functions can execute code in almost any modern language.
Functions are Stateless (but Durable Functions provide state), Code-first(imperative), can run locally or in the cloud, execute code.

The timeout duration for functions in a function app is defined by the functionTimeout.
For the Consumption plan default/Max value are: 5/10 minutes and 30 minutes/unlimited for any other plan.

HTTP triggered function Timeout

Regardless of the function app timeout setting, 230 seconds is the maximum amount of time that an HTTP triggered function can take to respond to a request.
For longer processing times , consider using the Durable Functions async pattern or defer the actual work and return an immediate response.

Azure Logic Apps

Azure Logic Apps is another type of serverless compute solution that offers a cloud-based platform for creating and running automated workflows.

Logic Apps are Stateful, Designer-first (declarative), run only in the Cloud, execute workflows that are designed to automate business scenarios and are built from predefined logic blocks.

Logic App helps you schedule, automate and orchestrate taks, business processes and workflows... when you need to integrate apps, data, systems and services across enterprises and organizations.

Design Apps

Message-Driven Solutions

Azure offers two message-based solutions, Azure Queue Storage and Azure Service Bus. Queue Storage stores large numbers of messages in Azure Storage. Service Bus is a message broker that decouples applications and services.

Queues

Azure Service Bus is a fully managed enterprise integration message broker. Service Bus can decouple applications and services.
The advanced features:

  • Message sessions : To create a first-in - first-out (FIFO) guarantee in Service Bus, use sessions.
  • Autoforwarding : The autoforwarding feature chains a queue or subscription to another queue or topic that is in the same namespace.
  • Dead-letter queue : Service Bus supports a dead-letter queue. It holds messages that can't be delivered to any receiver.
  • Scheduled delivery : You can submit messages to a queue or topic for delayed processing. You can schedule a job to become available for processing by a system at a certain time.
  • Batching : Client-side batching enables a queue or topic client to delay sending a message for a certain period of time.
  • Dupplicate detection : Duplicate detection enables the sender to resend the same message or for the queue or topic to discard any duplicate copies.
  • Transactions : A transaction groups two or more operations together into an execution scope.
  • Autodelete on idle : Autodelete on idle enables you to specify an idle interval after which a queue is automatically deleted. ** The minimum duration is 5 minutes**.
  • Filtering and actions : Subscribers can define which messages they want to receive from a topic.
  • Message deferral, Security protocols, Geo-disaster recovery, Security.

Service Bus queues receives messages in two different modes : Receive and delete (If the app can tolerate not processing a message if a failure occurs) or Peek lock.

You should consider using Service Bus queues when

  • Your solution needs to receive messages without having to poll the queue. With Service Bus, you can achieve it by using a long-polling receive operation using the TCP-based protocols that Service Bus supports.
  • Your solution requires the queue to provide a guaranteed first-in-first-out (FIFO) ordered delivery.
  • Your solution needs to support automatic duplicate detection.
  • You want your application to process messages as parallel long-running streams.
  • Your solution requires transactional behavior and atomicity when sending or receiving multiple messages from a queue.
  • Your application handles messages that can exceed 64 KB but won't likely approach the 256-KB limit(Premium limit is 100-MB).

Azure Queue Storage is a service for storing large numbers of messages. You access messages from anywhere in the world via authenticated calls using HTTP or HTTPS.
A queue may contain millions of messages, up to the total capacity limit of a storage account. Queues are commonly used to create a backlog of work to process asynchronously.

You should consider using Storage queues when

  • You need an audit trail of all messages that pass through the queue.
  • Your application must store over 80 gigabytes of messages in a queue.
  • Your application wants to track progress for processing a message in the queue.
  • You require server side logs of all of the transactions executed against your queues.

Event-Driven Solutions

You can also use Azure Event Hubs as event ingestion service.
Event Hubs implements a pull model that differentiates it from other messaging services like Azure Service Bus queues.

  • Event Hubs holds each message in its cache and allows it to be read.
  • When a message is read from Event Hubs, it's not deleted. The message remains for other consumers.
  • Scales to support millions of events per second at sub-second latency.
  • Supports AMQP protocol, Apache Kafka and many other Azure services.

You can also use Azure Event Grid to build an event-driven architecture that enables you to connect to the core applications without needing to modify the existing code.
Azure Event Grid distributes events from different sources to different handlers.

  • Azure Event Grid is a fully managed event routing service that runs on Azure Service Fabric.
  • Azure Event Grid aggregates all your events and provides routing from any source to any destination.
  • Event Grid distributes events from sources like Azure Blob Storage accounts and Azure Media Services.
  • Events are distributed to handlers like Azure Functions and Azure DevOps Webhooks.
  • The service manages the routing and delivery of events from many sources and subscribers which helps to minimize cost and latency by eliminating the need for polling.

Azure AD App Proxy

Overview of SSO to on-premises apps via Azure AD App Proxy, to provide access to On-promises applications.

  • SSO - Web API/Apps.
  • IWA Web Apps : Supports Web apps using Integrated Windows Authentification.
  • Remote Desktop Gateway : Supports apps hosted behind Remote Desktop Gatewway.
  • MSAL Intgrated Apps : Supports apps integrated with MS authentification Library(MSAL).

Key Components

  • On-Premises Application : The application to be published for external acccess via My Apps portal.
  • Azure AD App Registration : The application must be registred within Azure AD.
  • Connector : Two or more connectors are required.