Azure Compute

Azure supports both Linux and Windows VMs with a large gallery to choose the desired system images from.


Azure Virtual Machine are divided into a number of categories, at the time of writing A, D, DS, G, and GS. Each category offers VMs optimised for different use cases:

  • A for general purpose, higher end A-series VMs provide more powerful CPU
  • D(S) for more powerful CPU, D(S)v2 for most powerful CPU
  • G(S) for maximum memory
  • DS and GS series for high I/O

Detailed, up to date specifications can be located on the Azure website here.

Each VM image is associated with one or more VHD files belonging to:

  • OS drive
  • Data drive(s)

Host-caching can be set to ‘None’, ‘Read Only’ or ‘Read Write’ for each data drive where the application is sensitive to I/O. Striped drives are recommended for optimising I/O performance. The temporary drive is transient and not part of the VM image.

Azure VM images can be sourced from 3 locations:

  • VM Gallery – Microsoft and partner images
  • VM Depot – Open-source community for Linux and FreeBSD images
  • Custom Images – your own captured images
    • Generalized using sysprep to remove computer / user specific settings
    • Specialized to retain all settings, i.e. a snapshot of the source system

Virtual Machine State Management  can be achieved using some of the following techniques:

  • Virtual extensions allow first and third party services e.g. Antivirus to be applied to the VM via the VM agent.
  • Custom script extensions allow Azure PowerShell and Linux Shell scripts to be run from Azure Blob storage.
  • PowerShell Desired State Configuration (DSC) can be used to describe the desired end state of a VM to ensure appropriate configuration is applied.
  • State Management solutions such as Chef and Puppet can be used to define and distribute configuration using cookbooks.
  • Azure Automation can be used to trigger PowerShell Work-flows in response to events, defined in runbooks.



Azure Resource Templates are defined in JSON files that capture ‘Infrastructure as Code’.

Infrastructure as code can be thought of as:

  • Explicit, executable instructions for infrastructure requirements
  • Consistently applied code not subject to human interpretation

Using Azure Resource Templates an application stack can be defined and deployed with all its dependencies into a Resource Group.

Containers provide agility for application deployment and execution by decoupling compute and resource and allowing much greater compute density to be achieved by sharing system core resources on a single or clustered set of physical or virtual servers.


With public cloud scaling out rather than scaling up applications is the preferred approach. VMs added to an Availability Set can also be configured to autoscale. To support scale out of applications Azure offers both external (public facing) and internal load balancers (ILB). Azure Load Balancers also support custom health probes using TCP or HTTP as the communication protocol.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s