Dan Rey

Cloud Consultant
Technical Trainer | MCT
#AzureArch @stilldrey
Design Compute Infrastructure (20-25%)
• Design solutions using virtual machines
• Design VM deployments by leveraging availability sets, fault domains, and update domains in Azure; use web
app for containers; design VM Scale Sets; design for compute-intensive tasks using Azure Batch; define a
migration strategy from cloud services; recommend use of Azure Backup and Azure Site Recovery
• Design solutions for serverless computing
• Use Azure Functions to implement event-driven actions; design for serverless computing using Azure Container
Instances; design application solutions by using Azure Logic Apps, Azure Functions, or both; determine when to
use API management service
• Design microservices-based solutions
• Determine when a container-based solution is appropriate; determine when container-orchestration is
appropriate; determine when Azure Service Fabric (ASF) is appropriate; determine when Azure Functions is
appropriate; determine when to use API management service; determine when Web API is appropriate;
determine which platform is appropriate for container orchestration; consider migrating existing assets versus
cloud native deployment; design lifecycle management strategies
• Design web applications
• Design Azure App Service Web Apps; design custom web API; secure Web API; design Web Apps for scalability
and performance; design for high availability using Azure Web Apps in multiple regions; determine which App
service plan to use; design Web Apps for business continuity; determine when to use Azure App Service
Environment (ASE); design for API apps; determine when to use API management service; determine when to
use Web Apps on Linux; determine when to use a CDN; determine when to use a cache, including Azure Redis
cache
• Create compute-intensive application
• Design high-performance computing (HPC) and other compute-intensive applications using Azure Services;
determine when to use Azure Batch; design stateless components to accommodate scale; design lifecycle
strategy for Azure Batch

#AzureArch @stilldrey
 http://azureplatform.azurewebsites.net/
Azure Platform

* Preview Services
#AzureArch @stilldrey
The Mall

#AzureArch @stilldrey
Azure

Overview &
Basics

Storage

Compute
Security &
Management

Networking
Data &
Analytics

#AzureArch @stilldrey
An area within the mall

Compute

#AzureArch @stilldrey
Azure Resource Manager (ARM)

All services offered as ARM resources

• Consistent model for creating/managing
Azure resources
• Based on declarative templates

Resources are managed in resource groups

• Deployed together
• Managed together
• Provides RBAC support

#AzureArch @stilldrey
Azure Resource Manager Terminology

• Resource
• A manageable unit of Azure infrastructure
• Examples: virtual machine, load balancer, storage account

• Resource provider
• A service that allows for creation and management of
resources
• Examples: Compute Resource Provider, Storage Resource
Provider
• Resource manager template
• A declarative template for describing a resource group

#AzureArch @stilldrey
Reusable ARM templates

• A declarative template for describing a

resource group
• Community offered or Build your own

• Learn about template here:

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

#AzureArch @stilldrey
Compute
Virtual Machines Container Service Service Fabric App Service Functions

More Control Focus on the App

Customer-managed Platform-managed Code-only

(IaaS) (PaaS) (serverless)
 Azure Azure
IaaS VM Scale Service Cloud App Logic
Container Batch Container Functions
VMs Sets Fabric Services Service Apps
Service Instances

SERVERS! SERVERLESS
!
Virtual Machines

Ubuntu, Red Hat, Windows, SUSE, CoreOS

DevOps Extensions with Chef and Puppet
Multiple sizes
Hundreds of items in marketplace
#AzureArch @stilldrey
Introducing the Latest Azure VM Line Up

#AzureArch @stilldrey
Azure VM Sizes

A D Dv2 G Av2

Lowest Price SSD Storage New generation High memory and New A-Series
Fast CPUs of D family VMs Large SSDs

F N N H L SAP
C V

Compute NVIDIA GPUs NVIDIA GPUs Fastest CPU Large SSDs SAP Large
Intensive K80 Compute M60 Visualization IB Connectivity Instances

ND NCv2 Dv3 Ev3

Deep Learning New gen of NCNew generation ofHigh memory

NVIDIA P40s NVIDIA P100s D family

#AzureArch @stilldrey
VM Sizes

Type Sizes Description

General purpose B (Preview), Dsv3, Dv3, DSv2, Dv2, DS, Balanced CPU-to-memory ratio. Ideal for
D, Av2, A0-7 testing and development, small to
medium databases, and low to medium
traffic web servers.

Compute optimized Fs, F High CPU-to-memory ratio. Good for

medium traffic web servers, network
appliances, batch processes, and
application servers.

Memory optimized Esv3, Ev3, M, GS, G, DSv2, DS, Dv2, D High memory-to-CPU ratio. Great for
relational database servers, medium to
large caches, and in-memory analytics.

Storage optimized Ls High disk throughput and IO. Ideal for

Big Data, SQL, and NoSQL databases.

GPU NV, NC Specialized virtual machines targeted for

heavy graphic rendering and video
editing. Available with single or multiple
GPUs.

High performance compute H, A8-11 Our fastest and most powerful CPU
virtual machines with optional high-
throughput network interfaces (RDMA).

#AzureArch @stilldrey
VM Azure Compute Unit (ACU)
SKU Family ACU \ vCPU
• Provide a way of comparing compute (CPU) A0 50

performance across Azure SKUs A1-A4 100

A5-A7 100

A1_v2-A8_v2 100

• Not all Azure Cores are created equal A2m_v2-A8m_v2 100

A8-A11 225*
• A1 Core != F1 Core
D1-D14 160

D1_v2-D15_v2 210 - 250*

• Compare compute (CPU) performance across SKUs. DS1-DS14 160

DS1_v2-DS15_v2 210-250*

D_v3 160-190* **

Ds_v3 160-190* **

E_v3 160-190* **

Es_v3 160-190* **

F1-F16 210-250*

F1s-F16s 210-250*

G1-G5 180 - 240*

GS1-GS5 180 - 240*

H 290 - 300*

L4s-L32s 180 - 240*

M 160-180**

#AzureArch @stilldrey
The Fundamental Element of Azure
The Fundamental Element of Azure

St
VM Disks

• OS Disk (attached via • Separate storage cost

SATA)
• VHD based • Current Max Data Disk Size:
• Persists 4095GB
• Separate storage cost

• Temporary Disk
• Doesn’t persist - SSD
• No Separate storage cost

• Data Disk (SCSI)

• VHD based
• Persists

#AzureArch @stilldrey
Premium vs Standard (SSD vs HDD) Comparision

Azure Premium Disk Azure Standard Disk

Disk Type Solid State Drives (SSD) Hard Disk Drives (HDD)
Overview SSD-based high-performance, low- HDD-based cost effective disk
latency disk support for VMs support for Dev/Test VM scenarios
running IO-intensive workloads

Scenario Production and performance Dev/Test, non-critical,

sensitive workloads Infrequent access
Disk Size P4: 32 GB (Managed Disks only) Unmanaged Disks: 1 GB – 4 TB
P6: 64 GB (Managed Disks only) (4095 GB)
P10: 128 GB Managed Disks:
P20: 512 GB S4: 32 GB
P30: 1024 GB S6: 64 GB
P40: 2048 GB S10: 128 GB
P50: 4095 GB S20: 512 GB
S30: 1024 GB
S40: 2048 GB
S50: 4095 GB
Max Throughput per Disk 250 MB/s 60 MB/s
Max IOPS per Disk 7500 IOPS 500 IOPS

#AzureArch @stilldrey
VM Recommendations

Premium Storage for Production Workloads (Storage SLAs)

Choose a VM Size that works with premium storage for production
Use Managed Disks over Unmanaged Disks
Scaling Up/Down is just resizing the VM
Scaling In/Out – the VMs should be in an availability set
Use VM reboot logs to determine if VM was rebooted by planned
maintenance
Use snapshots to prevent accidental data loss
Enable VM diagnostics for production (includes boot diagnostics)
Stopped VMs are still charged for use. VMs need to be deallocated to stop
charges. Stopping through OS does not deallocate! Stop with portal or
CLI.

#AzureArch @stilldrey
High Availability
High Availability & Disaster Recovery
in Azure

• High Availability
• Availability within a single Azure region or datacenter*
• Expectation is little or no downtime (99.x % uptime)

• Disaster Recovery
• Recover into a secondary datacenter if outage in primary
datacenter
• Acceptable downtime has a greater range
• Quantified by Recovery Time Objective & Recovery Point
Objective

#AzureArch @stilldrey
Defining Disaster Recovery
within Azure

• Disaster recovery is being able to recover your

application into another Azure datacenter
• Keywords:
• RTO: Recovery Time Objective
• RPO: Recovery Point Objective

• Options range from:

• Complete active/active deployment in multiple datacenters
• Active/Passive deployment in multiple datacenters
• Active deployment in one datacenter, with backups stored
in 2nd datacenter

#AzureArch @stilldrey
Understanding Azure VM Availability
Single VM

Azure SLA guarantees no data loss, 99.9% uptime SLA*

• Subject to un-planned maintenance events due to physical failures
• If VM becomes unavailable, Azure migrates VM and restarts in another host
• ~10-15 minutes to complete this process

#AzureArch @stilldrey
Understanding Azure VM Availability
Single VM

Azure SLA guarantees no data loss, 99.9% uptime SLA*

• Subject to un-planned maintenance events due to physical failures
• If VM becomes unavailable, Azure migrates VM and restarts in another host
• ~10-15 minutes to complete this process
• Subject to planned maintenance events due to host OS servicing
• All VMs on host are shut down.
• Host OS is serviced and rebooted
• All VMs on host are restarted
• ~10-15 minutes to complete this process
• Subject to in-memory planned maintenance events
• All VMs on host are paused, Host patched, VMs un-paused. 30 seconds
downtime

#AzureArch @stilldrey
Defining High Availability
2 or more Azure VMs

• Multiple VMs can be configured in an “availability set”

• Workload is load balanced across the VMs

• Azure SLA: 2 (or more) VMs in Availability Set:

• 99.95% (<22 min downtime p/month)
• Includes
• Planned downtime due to host OS servicing
• Unplanned downtime due to physical failures
• Doesn’t include servicing of guest OS
or software inside (e.g. SQL)

#AzureArch @stilldrey
Availability Sets
• Availability Sets are for Unplanned & Planned
Maintenance
• Fault Domains (2 default, some regions allow 3)
• Upgrade Domains (5 default, 1-20 allowed)

• Front with Load Balancer, App Gateway

#AzureArch @stilldrey
Availability Sets
• Do NOT put a single VM in an Availability Set

• Example - for an application,

• Place front-end virtual

machines in the same
availability set

AND

• Data-tier virtual machines in

their own availability set

#AzureArch @stilldrey
Availability Sets: How Do We Do It?
Fault and Update Domains
•
•
•
•

•
•
•
•
•
•

#AzureArch @stilldrey
Virtual Machine Availability Sets
Update Domains are honored by host OS updates

#AzureArch @stilldrey
VM Scale Sets

High performance provisioning of 1000+ VMs

Auto-configuration at scale
Auto-scale based on schedule and resource metrics
Easy updates at scale
Simple Portal Integration

#AzureArch @stilldrey
Why VM Scale Sets?

• Manually scale with ‘capacity’ property

• Autoscale with host metrics (MDM pipeline) or
diagnostic extensions​
• Small buy-in: Deploy/manage sets of 0->100
identically configured VMs ​
• Guest OS patching: Patching primitives allow
manually triggered rolling upgrades​​
• High-availability – implicit availability set with 5
FDs/5 UDs​

#AzureArch @stilldrey
Autoscale with VM Scale Sets

• Define Max – Min VMs

• Define trigger and action rules
• Standard audit / email
notifications
• Define webhooks for custom
notifications and actions (e.g.
runbooks)

#AzureArch @stilldrey
VM scale set app deployment models

Model When to use

Marketplace Off the shelf solutions.
VM Extensions Full control over app lifecycle management.
Custom Install custom app independently of external network.
data/unattend
Configuration Centrally managed app installation, credentials & maintenance.
manager
Containerized Abstract app management from infrastructure. Cloud/DC agnostic.
Custom image Small self-contained apps. Fast deploy. Immutable build, test,
deploy pipelines.

#AzureArch @stilldrey
Azure Batch

Compute pools for job processing

Automatic scaling and regional coverage
Linux and Windows
Automatically recover failed tasks
Input/Output handling
Low-Priority (discounted) option

#AzureArch @stilldrey
Design microservices-based solutions

#AzureArch @stilldrey
Application Hosting (today)

Virtual Machines Containers

Customer-managed
(IaaS)

#AzureArch @stilldrey
• What is a Container?

#AzureArch @stilldrey
VM VM VM VM

App A App B App C

Guest Guest Guest

OS OS OS

Hypervisor Hypervisor

Host OS Host OS

Server Server

#AzureArch @stilldrey
VM VM VM VM

App A App B App C

Guest Guest Guest

OS OS OS

Hypervisor Hypervisor

Host OS Host OS

Server Server

#AzureArch @stilldrey
VM VM VM VM

Container
App A App B App C

App A
Guest Guest Guest Bins/Libs
OS OS OS

Hypervisor Hypervisor

Host OS Host OS

Server Server

#AzureArch @stilldrey
VM VM VM VM

Container Container Container

App A App A App B

App C
App B
App A
Guest Guest Guest Bins/Libs Bins/Libs Bins/Libs
OS OS OS

Hypervisor Hypervisor

Host OS Host OS

Server Server

#AzureArch @stilldrey
• Why?

#AzureArch @stilldrey
• Lightweight

#AzureArch @stilldrey
• Portable

#AzureArch @stilldrey
#AzureArch @stilldrey
#AzureArch @stilldrey
#AzureArch @stilldrey
 VM VM

Container Container Container Container Container Container

Container Orchestrator

App C
App B
App C
App B

App A
App A

Bins/Lib Bins/Lib Bins/Libs

Bins/Libs Bins/Libs Bins/Libs
s s

Hypervisor Hypervisor

Host OS Host OS

Server Server

#AzureArch @stilldrey
 VM VM VM

Container Container Container Container Container Container

Container Orchestrator

App C
App B
App C
App B

App A
App A

Bins/Lib Bins/Lib Bins/Libs

Bins/Libs Bins/Libs Bins/Libs
s s

Guest
OS

Hypervisor Hypervisor Hypervisor

Host OS Host OS Host OS

Server Server Server

#AzureArch @stilldrey
#AzureArch @stilldrey
Microservices 101

#AzureArch @stilldrey
Azure Container
Service

Azure Container Service

Kubern DC/O Swar

etes S m

#AzureArch @stilldrey
Azure Container Instances
(Preview)
Simplest and easiest way to run individual containers in the cloud
No VM management
Per-second billing with customized resource requests
Linux and Windows Server containers

#AzureArch @stilldrey
Application Hosting (today)

Virtual Machines Containers Service Fabric

Customer-managed Platform-managed
(IaaS) (mIaaS/PaaS)

#AzureArch @stilldrey
Microsoft Azure Service Fabric
A platform for reliable, hyperscale, microservice-based applications

Microservices
High
Availability
Hybrid
Operations
Data Partitioning
Service Fabric Health
Monitoring
Container
Orchestration & Self-healing
Simple Rolling Low Latency lifecycle management
High Density Placement Replication &
programming Upgrades Fast startup & Load balancing
Stateful services Constraints Failover
models Hyper-Scale Automated Rollback shutdown

Windows Windows
Linux Linux
Server Server

Azure Hosted Clouds

Windows
Linux
Server

Private Clouds

#AzureArch @stilldrey